Surviving in Open Source Communities

The decisions faced by a community (in this article I’ll only be referring to programming communities like Apache) can be handled in one of two ways. First, is lazy consensus. I like to think of it as “commit first, ask for forgiveness later.” In these situations, the developer simply makes the change and commits it. Sometimes he or she will be nice enough to announce the modification, though often it’s left up to other developers to monitor CVS notifications. Anyone who objects needs to bring the matter up on their own, otherwise, the changes stand. Such a situation gives the developers a lot of independence and decisions can be made rapidly.

The alternative is a decision which requires active approval of the community. Such approval is usually determined by a vote of some sort. Various communities have various voting procedures and standards. I’m not going to get into all the voting methods, but I should at least point out that not all votes are the same. Some decisions have more stringent requirements than others.

The important thing to remember here is that there needs to be a balance between the two types of decision making. A lone programmer mucking around in the source repository without respect for fellow developers can quickly start flame wars. A good idea burried under mounds of proposals, voting policies, and other bureaucracy not only kills the idea but also the motivation of well meaning developers. A healthy community resorts to policies and voting only when necessary and is flexible and forgiving enough to have someone muck around and break the build now and then without the world ending.

So suppose one day after you’ve finished reading <a href=”http://slashdot.org”>Slashdot and perusing insightful blogs on Planet Apache the muses inspire you with the solution to all your open issues in bugzilla. Now all you need to do is convince your open source cohorts to accept your radical vision of the future. Or perhaps you’re the programmer who hears about the latest radical plan and realizes it’s the same bad idea that was proposed a year ago and it’s still a bad idea now. How can you ease the process of gathering concensus? What can developers do to ensure respect of the community while giving freedom to experiment? Here are some of my suggestions:

Say it in code

Sometimes a code example is worth a thousand words. If you are proposing a code change, put together a working example that shows the fallacy of the old approach and the improvements you are suggesting. If you’re unsure of a proposal, make sure you carefully review any code examples provided or spell out your counter arguements in code.

Unit testing catches more than bugs

Good unit test coverage allows for more experimentation in the code. Developers can try out new ideas and immediately know if the latest implementation will break client applications. This helps ease the uncertainty surrounding changes. It can also immediately validate or invalidate a particular proposal.

Use your SCM

Proper use of your SCM (such as CVS or SVN) also eases the decision process. More drastic changes can be committed in a branch instead of in the main trunk, or better yet, a “sandbox” area can be created which allows individual developers to experiment while still allowing the community to be involved.

Have clear policies

The community is responsible for developing and maintaining a clear set of policies and procedures for decision making. Voting rules should be written down and in public view. Preferably guidelines for when lazy concensus is appropriate and when community approval is required should be established. The last thing a conflict over a code proposal needs is another conflict over community rules.

When in doubt, ask

If you’re uncertain a particular change you’re about to commit is a good idea or have any inkling that it might stir up contention, it’s often much better to simply ask than deal with the potentially hurtful results. This may require patience on the proposer’s part but it’s also part of the responsibility of being in a community. Communities require communication.

Don’t get in the way of those doing the work

While proposers of a change should have the decency to communicate ideas with the community, the community should have the decency to not unduly hamper sincere efforts. If a developer is moving ahead with the code base or volunteering to update the website, unless you have a very good reason otherwise it’s often better not to get in the way of progress. This is most applicable when the proposed changes affect code you are not intimately involved in. Another way to think of it is don’t let your rants on the email list outnumber your CVS commits. Those actually doing the work shouldn’t be unnecessarily stalled by politics.

There’s more than one way to do it

There’s always more than one way to solve a particular problem, especially programming problems. Recognize that the proposed solution isn’t the only solution and all parties should be interested in seeing other options. In some cases it may be best to just agree to disagree. When this happens an individual may decide to leave the community to persue his or her own unique idea and should feel free to do so. Likewise the community shouldn’t feel threatened when someone decides to leave and compete instead of cooperate.

Thinking before hitting ‘SEND’

A lot of community discussion happens on public email lists. Resist the urge to reply immediately to a controversial topic. Make it a point to re-read your emails before sending them off to be archived forever. Perhaps you might even want to leave them in your ‘Drafts’ mail box for a day. It’s a lot easier to send an email later than recover from one sent too early.

Remember: Release Early, Release Often

While patience in email replies is a virtue, it isn’t always one when it comes to releases. No release is going to be perfect. No proposal is going to fix every bug or anticipate every feature request. Overambitious proposals or votes often end up stalled in the details. Thus it is often better to focus on one small problem at a time and get the result out as soon as possible. Waiting until the proposal is perfected slows down the entire community. Remember to release early and release often.

It’s supposed to be fun

Open source projects thrive on volunteer effort and few want to volunteer for flame wars and extended voting battles. When the work isn’t fun anymore, take a break. Step away from the computer and the problem. If you do, you’ll be much happier when you return.

Of course there are no magic tricks for establishing a healthy community. It takes patience and work and effort just like everything else. Nevertheless there are certainly a number of things both the community in general and individuals specifically can do to make the process of decision making an easier one. The principles listed here are not cure-alls or even new, but it’s nice to be reminded now and then.