Open Development: diversity matters

Kaj Arnö, of Mysql fame, has been commenting my now quite old Open Development rant, providing some insightful comments and interesting food for thought. Given where Kaj comes from, I’m not surprised he doesn’t quite like my arguments about community development needing neutrality to thrive, and he does have a few points when he provides an alternate and articulate proposal for “Participatory Open Source”.

I’m happy to see Kaj agrees that Open Source should be about community as well, and I applaud to what MySQL has been doing to get external developers involved. Still, I have to stomp my feet somewhat and insist on neutrality as a main component of Open Development (or whatchamacallit, for that matter). The keyword here is diversity, as I mentioned before. Sustainable Open Source, built upon the classical advantages of multiple eyeballs, absence of vendor lock-in, distributed innovation and cooperation among developers needs a community of technical interests, with participation being driven by diverse objectives who happen to share a common goal. A diverse community drives innovation, acts on technical merits rather than business objectives, and protects from orphaned/abandoned code or from whatever might happen to a single company backing a project. Diversity is good. Diversity matters.

A diverse environment is hard to build if neutrality isn’t part of the picture. Not impossible, but highly unlikely. For one, it’s hard for people to give free lunches away on a continuous basis: casual contribution are fine, and there is no problem in sharing a bugfix a developer cares about, but there is little evidence of communities with a thriving developer base from different backgrounds helping out actively the average commercial Open Source project on a structured basis (partner companies need not apply, thanks). Think of it as “no taxation without representation”: where is the motivation to contribute if there is no way to have a significant say in the project governance and roadmap? Why should I bother contributing ideas and code when there will be a business scrutiny getting precedence over technical merit? A neutral and meritocratic environment which encourages participation is the single most important feature individuals and companies should look for when deciding to contribute precious time and resources.

Kaj, if you need any further proof, look no further than your post when you question the notion of non-discriminatory access to the code:

The interesting middle ground is whether it’s OK to say “no” or “maybe later” to technically sound contributions that don’t fit with the business interest of the owner of the main code base. I would argue that such “discrimination” is OK, as the “Participatory Open Source” requirements would otherwise impose so severe purity limitations, as not to be interesting for companies with a commercial agenda, like MySQL AB.

As you can see, this is a chasm which is not easy to cross. MySQL AB, ultimately, wants the final word when it comes to a business agenda clashing with a technical proposition: as much as your position is understandable, I trust you acknowledge the little motivation third parties will have in contributing. Saying that contributions are welcome as long as they fit your business is OK from a corporate perspective, but let’s call a spade a spade and consider how your position from a community perspective is less than inviting.

You just can’t have your cake and eat it too: you’re not going to get any structured contribution without giving some control away, and you’ll have to be content with what you get from a community built upon a few that happen to share your business goals and a number of “useloper”, if you allow me to forge a new term that tries to describe users that might contribute something from time to time. If you happen to be as widespread as MySQL is, that’s no small stuff, yet you can count on a Simpson’s hand how many commercial Open Source companies are so lucky. The other ones either will have to deal with a few casual contribution here and there, and fully carry the burden of internal development. Or just drink the Open Development Kool-Aid, adjust a little their business model, and enjoy participation from a diverse, neutral, community which will provide the foundation to their business solution.