I am not really a big fan of lengthy flame-wars in mailing lists, but I have to recognize that sometimes they can be really having a positive effect in making things move. This conviction was born in me quite recently after I followed the "Specification Process" mega-thread on dev@openoffice.org. This thread was born out of a (quite legitimate, I must say) complaint about one community contribution to OpenOffice.org, then it went into some kind of criticism/defence of the current specification process and now it is heading to the core of all problems - developer community building. And that is exactly the issue that I would like to give some thoughts about in this blog.
The question is how!
The first thing that one should realize is that the question is not now whether we should or not build a developer community. The current state of 93% of all contributions done by Sun is not an optimal state and does not profit anybody. If this figure does not change in favour of community contribution, quite frankly, the fact to open-source the whole monster will mean a net loss for Sun. Since it is most likely that the 7% of community contributions simply create more than that amount of overhead in the work amount of Sun engineers/QA/UserEx/administration. So, what is the solution? Close it again and release time to time a free (as beer) version of StarOffice? I do not think so! The only option that is having any sense is to build the developer community beyond the critical mass that brings a net win. Only then we can profit fully from the advantages of open-source model.
Hunting without target?
Almost everybody will agree that it is quite unlikely (although statistically possible) to kill a rabbit, a deer or a pheasant by shooting into a forest and hoping that the target will find the bullet. It is somehow similar with community building. We have to be proactive in this task. Determine what can attract developers and do exactly that; determine what can hinder community participation and try to eliminate it as much as it is reasonably possible.
I pointed out some of the issues in my OOoCon2006 talk in Lyon. Quite frankly, I do not really believe that giving ODF talks in different conferences (although important from the marketing point of view) will bring any developer community to life. It is still in the line of what I would call marketing of the product as opposed to the marketing of the project. Maybe it is a time to have a developer speak to potential developers. Being able to understand one's target audience is not only an advantage, but a vital necessity for this task.
Waste their time, lose them
The miracle about the FOSS contributors is that they are really ready to spend their time giving out free work as long as they see that they make a difference and they satisfy their thirst of intellectual challenges. But if these intellectual challenges are hindered by a big stone laid on their chest, they are likely to go somewhere else where they will have more impact and feel more like they matter. Yes, it will require some extra work to lower the barriers for external contributors, but the discounted benefit for sure overweights the cost.
A frustrated employee might voice her frustration but will eventually STFU because her family needs the money. A frustrated FOSS contributor will voice her frustration (if the project is lucky) and eventually exit. Because the time spent fighting with the dragon means less time spent with those whom she loves and who love her. It is as simple as that.
Agile, XP vs. "Big Design Up Front"?
It has to be encoded somewhere in the human genes that when something is not giving optimal solution, a complete negation of that approach is considered as the miraculous way out. This specification discussion shows is also in a clear way. I do not really think that the two approaches are mutually exclusive and fundamentally incompatible. The truth is somewhere in the middle. A project of the size of the OpenOffice.org cannot live without any up front design. On the other hand, transposing Hamburg workflow into a normative specification process looks kind of sick too. Nobody ever can defend an idea that saving 10 minutes of his time is worth adding hours to the time wasted by others. Maybe it is now the time to gather all stakeholders and sit together as community and come up with a process that is satisfying all parts. If we are more inspired by agile principles (I speak about principles, not rules and fit-all methods), the overall quality of the product will benefit and - it is very likely, that in middle term - the developers, QA and UserEx will be less overworked too.
