A Day in the Life of an Open Source Project

Open source projects can be a challenge to manage. Why? Imagine this, you have a product you hold near and dear to your heart. You’ve poured blood, sweat, and tears into this thing and you have finally hit something you think is worthy. You ship it out to the world and say, “Here is my code: feed, digest, and enjoy.” Twp hours later you are bombarded with 40 emails telling you how horrible an idea using algorithm X, Y, Z was and how you should see that obviously W, X, Y is the preferred method. Then you see others that make note of your lacking skills in coding and that you should quit your day job. Next you see about 5 patches that need to be reviewed to fix bugs in your system. And lastly, you have requests to help enhance your product. This makes you want to pull your hair out- assuming you have any left at this point.
The picture I’ve tried to paint, I’m not an artist so forgive me, is not a very shiny or happy one. In fact, that is one of the things that turns people off from open sourcing products. Sure there are other reasons, but managing open source projects is very hard work. So, how do you make it easier. You should note that the community is not going to letup at all on the product providers. Everyone has an opinion and thinks it needs to be heard/read. So, without getting into the why’s or the benefits of open source, lets discuss how.

What things can be done to better control the flow of an open source project.

1. Patch Management- Bug fixes are going to come in, but to control those you could set up a bug management system. There are a number of bug management tools available; you just need to find them and use one. This will allow you to continue working on the things you need so that you can schedule 30 minutes at the end of a day or every other day to review any patches that came in and either include them or send them back. Not only will a bug system allow you to manage patches, it will provide a clear roadmap for your users and other developers. Thus, people wont step on each others toes. Two bug management systems that come to mind are Jira and Trac. Atlassian has a deal for open source projects as well, so take a look.
2. Enhancement Management- Branches. Branches. Branches. I’m not talking about the crap-tastic ones that SVN provides. I’m talking about real branches; DVCS branches. Go out and experiment a bit with Git, Bazaar-NG, and Mercurial. See which one tickles your fancy and pick it. You will have a far better time running your project with one of those rather than the alternative. And, if you don’t want to deal with hosting one of those you can use services such as Launchpad. What having one of these allows for you to do is create a branch that only the ehancers can push changes into, This effectively keeps the sources separate. But, when time comes to review the enhancements and push them back into the main branch, you can do this with a decent amount of ease.
3. Peer Review- You will never be able to break the flood of “you suck” commentary. However, you may be able to channel this behavior into positive, constructive criticism. Peer code reviews are great methods to keep you on your toes and make sure that you are always learning. My thoughts are that there is always someone more intelligent than you are out there. So listen. You can use some tools that provide a great way for people to write back on the code you are producing such that the comments go from “Why in the world would you use X?” to “Algorithm X is inefficient here because you loop over the data set twice. Use Y instead.” The commentary will become productive and useful. Tools do exist to aid in review; take a look at Crucible.
4. Ease of Contribution- Remember open source is about the community. You can’t half ass this. People have to be able to contribute in one way or another. And, they will know if you are just giving them the run-around. Therefore you need to allow for people to easily contribute. Many times people will be able to squeak 30 minutes in here or 2 hours there. And, if they have decided to spend that time on your project, you should be grateful. They could be doing something else. Thus, if you make it easy for them to help you, you’re likely to see better results from your open source-ness.

If you keep these tools in your toolbox for helping you to run an open source project then you are more likely to succeed with your project. Keeping the right attitude will also help. Be sure to take all criticism as good criticism. It can be hard since your code is generally close to your heart, but nobody is perfect and having a good attitude towards criticism will always be a benefit to yourself, whether in an open source project or not.

What approaches do you take when working on open source projects? How do you contribute? What are the steps you use to push your project to success?