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.

Thoughts on F/OSS (5/10): hosting your project

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

Hosting your projet is important. You can do it yourself, but joining an existing community might be better, especially as you can leverage existing infrastructure for SCM, mailing-lists, issue tracking and so on.

General-purpose hosting at forges like BerliOS or Sourceforge is generally fine for most projects. The delay to get in is short, and almost all projects should be happy there.

Lighter self-service solutions exist as well: Github, BitBucket or Google Code to name a few. You are not starting an opensource project that will succeed everyday, so in most cases those services might be just what you really need. Ice on the cake: they are often more attractive from a toolset / workflow point of view that the general purpose forges

Finally, your project could join selective communities and consortium such as the Apache Software Foundation, Codehaus or OW2. They all provide great visibility and infrastructure for your project. Getting in is however hard.

I suggest that you think small in the first place. For example don't bother launching a big infrastructure with 4 mailing-lists (dev, users, announcements, scm) until you actually build a community. Also, do not knock at the door of selective communities until your project is solid and has a real community to support it.

You may have a brilliant idea, but only time will tell if you were right. You don't need a big infrastructure to get started. Growing slowly on the tooling side will also make the communication with your community easier in the long run. Avoid bureaucracy at all costs!

Of course infrastructure is important, but don't forget that it neither writes code for your nor builds a community!

Thoughts on F/OSS (4/10): steps of your project

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

Starting a project is easy. You will most probably start doing the initial code alone, and enjoying the excitment of creation.

What most people don't realize is that your project is likely to never get past that point. There is a high chance that you will loose enthusiasm on your project before others eventually start using it.

You can thus consider yourself a happy person as some people actually download and use your project. This first step is by itself already a non-trivial milestone in your project hazardous life.

The next hard step is to get some patches from people who took time to look at the source code, made modifications and cared enough to send you fixes and improvements. Again, the F/OSS theologists will tell you that people are naturally inclined to hack your code and send patches. This is all bullshit. How often do you checkout a project source code and hack it? Not that often I'm sure...

If this keep on going well, you may actually reach the next steps: having a community where:

• some people are commiters to your project
• some people send patches (contributors)
• people ask and answer questions on your mailing-lists, and you don't even have to answer yourself all the time.

From there, and with a little time, you get a mature project. Again, this step is very hard to reach, and few projects get there.

Your very own work changes too (compared to when you started the project). Some project founders may leave and pass the leadership to another developer, or you may still be there, but now in a manager type of work, ensuring that the project keeps going forward by coordinating people, planning releases, and more generally, by being the benevolent dictator for life .