JPz'log Coin Coin and Plop da Plop

Thoughts on F/OSS (6/10): 4 tips for managing a project

This is part of a 10 blog posts series on F/OSS thoughts, extracted from a talk that I gave recently.

Be open: you must listen to what others say. This sounds quite basic, but some project creators see themselves as super gods that are always right, while others would be stupid ignorants that cannot understand how grand their vision is. Come on: others use your project, they hack it, and they may even dislike it (probably one of the best feedback by the way).

That being said... you have to learn to say no. Not everyone is right, and you need to maintain a certain vision to your project. If you try to please everyone you will end up with a software that checks emails, handles Maven repositories and prepares the coffee over an OSGi-compliant device that also respects the JSR 666. As DHH said, opiniated softwares are brilliant, half-assed products suck.

Along the way to say no, you may displease people. That's part of the game. Let people propose patches or even fork your project. Everything is possible in lengthy debates on a mailing-list, but what really speaks for itself is code. If it turns out that the people in front of you were right: stay humble and reckon that they indeed were right.

One easy tip for learning to say no: refuse patches for new features if there is no documentation update. A new undocumented feature is useless as nobody will use it. Accepting such patches is merely a convenience in terms of maintenance for the people who created it, and more bloat to your code.

Recruiting developers is also an essential part of your job as a project manager. However, do not make the mistake to give SCM commit permissions to anyone asking for it! You must be able to trust other developers, so that you know that they are likely to behave like you would. An easy way is to require people to first be external contributors who send you patches. This way you can carefuly look at how they code, how they argue for their proposals. You can also easily spot bad asses. After a few successful patches you can offer such guys to become developers for your project.

This is pretty much like running a business. Recruiting is essential for your growth. Consider the external contributor steps as a job interview (but in an informal fashion).

Finally, another basic tip is to spread the news. You must have a decent website, but that is clearly not enough. You must do quite a lot of marketing to announce releases and the very own existence of your project to other websites, speak at conferences, and so on. Your project must look attractive and active. People must feel that there is some energy behind it. Energy is always attractive.

Related posts:

1. Thoughts on F/OSS (4/10): steps of your project
2. Thoughts on F/OSS (5/10): hosting your project
3. Thoughts on F/OSS (10/10): governance
4. Thoughts on F/OSS (8/10): dealing with success
5. Thoughts on F/OSS (1/10): quick facts