nomadsoftware |
|
Fear of contributing to open source software
I’m currently considering contributing to an open source software project and while I feel I could make a worthwhile effort i’ve always had fears about doing so. In this article i’ll explain these fears perhaps because other developers may feel the same. Then later, i’ll try and come up with some solutions. So lets get started listing the main issues I have.
Not knowing project procedures
This is perhaps my biggest fear when joining a project, that once contributing i’m berated for not following established protocols for sharing information or for submitting work. It would be the same if a new member joined my team and started doing as they wished. Of course they would be immediately be corrected and furnished with a set of guidelines for interacting with the team. Although well intentioned this would be a blow to anybody’s initial good will. There’s also the issue of just not wanting to feel like a complete doofus when joining, as first impressions tend to last.
Becoming a distraction for others
When joining any development team there is a lot that you simply don’t know and have to ask someone for guidance. Continually pestering someone (or even a team) for information can be a huge distraction. Fred Brooks kind of touched on this subject in his 1975 book The Mythical Man Month. He wrote that when adding man power to a software development team the ensuing distraction while educating new members causes the entire project to be continually pushed back and delayed. I don’t want to be the guy that’s always asking what may seem like dumb questions from the team.
Revisiting old discussions
This would be another huge time waster for the team: forever explaining design or code decisions made in the mist of time to a newcomer. For example, say i’m browsing the source code of a particular project and I see a crude hack. I then proceed to ‘fix’ the code and submit it to the team. Immediately i’m informed that the decision to include this hack was one made two years ago after an incredibly intense flame fest and I should leave it well alone. I can’t possibly read all the discussions that have taken place over the years to catch up on where the project is today. So situations like this are sure to crop up.
Trying to do too much too soon
This is probably a combination of all the above issues, that if you are not fully aware of procedures, design decisions or even the way the team works, you are sure to get into hot water quickly (or so I imagine). I have some great ideas for one particular open source project but I don’t want to start wading in and making massive sweeping changes without first becoming familiar with everything. I guess I could fork off my own branch and go to town but that’s totally defeating the purpose of wanting to share my changes with the team. Perhaps different teams have different definitions of trying to do too much. Some might welcome large patches where others need justification for every line of code.
A lack of confidence
This is a fear of a lot of software developers, in that sometime in their development career they may feel they are not good enough to contribute to a team or that the contribution will be laughed at, etc. While I feel I have the necessary experience and background to contribute there is always that niggle in the back of my mind. After all to grow as a developer it’s necessary to push yourself out of your comfort zone.
Solutions to stop being ‘poisonous’
All (and more) of what I explain above was initially brought to my attention in the following Google tech talk given by Ben Collins-Sussman and Brian W. Fitzpatrick.
In this lecture they both talk about how well meaning developers can seriously disrupt or in some cases destroy a project. Some of the examples given are a little extreme and I personally think the two presenters display a little hubris in some of the things they say. But it’s a good eye opener of what problems there will be when joining an open source team.
Another good resource for learning more about open source projects before actually joining one is the 2005 book Producing Open Source Software by Karl Fogel. Not only is this book free to download from the website, it also contains virtually everything you will need to know to successfully run an open source project. More importantly, it describes how successful projects operate, the expectations of users and developers, and expands upon the culture of open source software.
I guess I will never know what is to be expected until I actually join a project but after reading through the information above I think i’ll dip my toe in carefully and try not to be too ‘poisonous’.