Managing an Open Source Community

We saw that:

• an Open Source community is a community of producers (not consumers);
• members of such a community are mostly professionals (working for companies).

How to manage, to sustain such a community?
There is the traditional way (the subversion one), focusing on controlling it, by getting rid of poisonous people and cooptating dedicated committers.

But shouldn't this fall short? Is this sufficient? Are people so infinitely patient, that there are willing to invest their time and effort without any guarantee, of integrity or of delay? Some committer may or may not review your submission, she may or may not appreciate it, and merge it to the main line. Only after this will have happened will you be able to see you changes, and to discuss them with others, beyond the scope of a few co-workers. This will come in total discontinuity with the environment in which you initially tested your contribution.

Other projects, with other tools: git, bazaar, support user branches and pulling from those, so that the continuity is better supported (no missing link), even if the publication always happens via merges, and the actual communication is completely left beyond the scope of the tool support (who uses what, why? what problems did they meet, which pushed them to try this version? what else do they use? etc.)

This model is more flexible in that it encourages contributions from many more people, without requiring from them an exclusive dedication which is hard to keep compatible with their other, mostly professional, duties. Something remains from the committer role: contributions must be tracked to identifiable people. But the trust should better be placed in objective data about the use of the contribution, than in the ego of the contributor.

-- MarcGirod - 08 Oct 2007