So the day before yesterday, Aaron Seigo wrote up a brilliant piece on running a community-driven project. Since I stole^H^H^H^H^Hborrowed his post, I want to contribute back my own experiences. The justCheckers project is currently in a semi-active state at the moment. But in its heyday, we had a group of 5 active developers. But overtime the momentum dropped off until only I remained on the project.

A major reason for this is my own inexperience in managing a project. Over the years, I learned about and tried out different project management techniques. Unfortunately by the time I could implement those in justCheckers, people had moved on to greater things. And I even thought of closing down the project, until recently I revived it again for a different purpose…

Some of the lessons I learned along the way are:

1. Manage Expectations. This is a real killer. It is fun and easy to overhype your own project and your involvement in it. But it doesn’t help the project in the long run especially once people realise that their initial expectations differ wildly from reality. Myself I promised the moon, and didn’t deliver.
2. Be Prepared to Spend the Time. As a lead developer, you will end up doing most of the work. Open source projects begin as ordinary projects, and only in the later stages do submissions and community efforts come into play. So before you begin, be prepared to do a lot of pushing until the project can maintain itself. Being a university student and running an open source project can be difficult if you are still developing your time management skills.
3. Code is King. This I believe is one of Matt Asay’s favourite sayings. Source code contributions are what make open source work. Later on other kinds of contributions come into play. But source code should come first. I spent an inordinate amount of time on documentation and planning. Instead I should of thrown up a quick sketch and just concentrated on coding.
4. Establish Good Lines of Communication. Without good, honest and open communication your project goes quickly astray. Facilitating that communication is not a trivial task. My greatest success was via individual e-mails and forums. But things went downhill when I lost the forums. Bringing them back ended up in fighting spam. Same thing with a wide open wiki. A wiki is good for knowledge discovery but not for discussions so much. I tried setting up an IRC channel on Freenode.net but my request never went through. This is one issue I never figured out how to resolve.
5. Be Flexible. I tried applying conventional project management techniques and that doesn’t work for a volunteer open source project. In time I learned about the importance of voluntary involvement and persuasion as the best tool for moving forward. But that is another matter altogether.
6. More Warm Bodies Don’t Mean Faster Coding. I learned that open sourcing a program doesn’t suddenly mean that a bunch of people will suddenly appear and work on your ideas. No, again you need to be the primary mover until others decide to help out to use the program to their advantage.

We did do somethings well:

1. Delegate Tasks by Components. This gave everyone ownership of some part of code. This also prevented people from setting on each others work.
2. Market Help Needed. This helped a lot in bringing together the core team. In fact the project would of never got off the ground without Sourceforge‘s ask for help functionality.
3. Build to Last. We tried to build everything in a generic enough manner to allow for future functionality. It takes more time to build this way, but it ensures better design and future-proofs the end result.

Now, the justCheckers project is heading in a different direction. And so a different approach is needed.