Community building
In my last post I wrote about open approaches for Earth Observation. Open (science/source/whatever) means community. I am in the middle of the reading of "The Art of Community" and it is very inspiring. In some ways, it reminds me of very much of Chapter 4 "Social and Political Infrastructure" of Karl Fogel's "Producing Open Source Software - How to Run a Successful Free Software Project", although Bacon's book is more general.
Anyway, both books give very good insight on the issues and tricks involved in a community-based project and even the particular case of projects which are created and managed by companies.
This is an interesting point, since one could think that a project nfunded by a company has more chances to succeed than a pure volunteer-based one, but many real examples show that this is not the case. The main pitfalls of a corporate open source project are related to decision making and communication. For a project to succeed, the community has to be respected and open discussions and meritocracy are the 2 pillars of community.
Examples of this are the fact that all decisions involving the development have to be explained and discussed in a way that all developers are involved. Examples of closed discussions at the company level leaving out the volunteer contributors are given.
Another interesting example is the one given by Fogel about meritocracy: any developer should earn the write access to the source repository by proving his value. Usually, in corporate environments, developers have commit access from the first day, while external contributors, which usually are much more capable, have to wait long time before that.
An important player in any open source project is the Benevolent Dictator (BD). I will cite Fogel verbatim here:
"It is common for the benevolent dictator to be a founder of the project, but this is more a correlation than a cause. The sorts of qualities that make one able to successfully start a project—technical competence, ability to persuade other people to join, etc.—are exactly the qualities any BD would need. And of course, founders start out with a sort of automatic seniority, which can often be enough to make benevolent dictatorship appear the path of least resistance for all concerned.
Remember that the potential to fork goes both ways. A BD can fork a project just as easily as anyone else, and some have occasionally done so, when they felt that the direction they wanted to take the project was different from where the majority of other developers wanted to go. Because of forkability, it does not matter whether the benevolent dictator has root (system administrator privileges) on the project's main servers or not. People sometimes talk of server control as though it were the ultimate source of power in a project, but in fact it is irrelevant. The ability to add or remove people's commit passwords on one particular server affects only the copy of the project that resides on that server. Prolonged abuse of that power, whether by the BD or someone else, would simply lead to development moving to a different server.
Whether your project should have a benevolent dictator, or would run better with some less centralized system, largely depends on who is available to fill the role. As a general rule, if it's simply obvious to everyone who should be the BD, then that's the way to go. But if no candidate for BD is immediately obvious, then the project should probably use a decentralized decision-making process …"
And I will end this post by using the opening quote of Bacon's chapter 9:
"The people to fear are not those who disagree with you, but those who disagree with you and are too cowardly to let you know." —Napoléon Bonaparte
Food for thought.
