Emmanuel spreads the news: dark clouds have been gathering in the past few months over OpenDS, the Sun-sponsored attempt at building a Java based Directory server. It’s a sad story of a core team being laid off, fights over project governance, and quite a few undercover talks about who owns and controls what. I don’t want to take sides in the developing story, as I’m sure the full picture isn’t available and most likely will never be, but I’m definitely going to see what happens. And you should as well, if you care about what Open Source really is.
What kinda strikes is how both parties can be right. On one hand, we have developers who complain about a corporate sponsor forcing its way to ensure his ultimate say on project governance and directions, while on the other we have a BigCo which doesn’t quite seem to understand what all this fuss is about, as it seems natural for the core contributor to ensure control and leadership over his assets. This really sounds like a semantic issue to me, as different parties clearly have different perceptions of what Open Source is, especially when it comes to interaction with communities.
The first step in effective communication is making sure there is a shared understanding of underlying concepts (a glossary, if you like). The problem with problem with the term "Open Source", as defined by the OSI, is that it doesn’t take the development process into account: the Open Source definition is, really, just about usage and distribution terms for source code. This would absolutely be fair enough, as providing a clearly defined normative framework for distribution it has been extremely useful in attaining quite a few notable goals. The real issue is how the OSI actually claims they actually are all about the development process, as you can read in the very first sentence of www.opensource.org which defines Open Source as follows:
"Open source is a development method for software that harnesses the power of distributed peer review and transparency of process."
If someone hibernated in 1998 woke up today and surfed to the OSI site, by reading their first sentence he’d be fully entitled to think that Open Source is about how software is developed rather than how it gets distributed. Problem is, the front page wording is little more than marketing fluff: what really matters is the Open Source definition, which is the normative bit and the one and only authoritative source to define what Open Source really is. Let me run a small challenge through you: how many times to you think the word "development" (or any variation of that) appears in the formal definition of Open Source? If you guessed zero, you were right. Zilch. Nada. Try to look for "process". Or "transparent", "neutral", "meritocratic". Or anything that vaguely recalls software development. If you can find anything of that sort, you’ll make me a very happy guy, a reborn OSI diehard and someone who will run head-first to a few English classes. I’m afraid Berlitz will have to wait some more for my money, though.
Having said that, I’m not surprised at seeing clashes and misunderstandings when conversations shift towards the community aspect of Open Source: as there is no formal definition and no clear semantics, everyone is entitled to his own opinion. Which is why some would argue that Open Source doesn’t need a community to thrive, while others will strive to achieve collaborative environments driven by neutral processes and meritocratic policies. Once you understand that those parties are actually talking about different things and just happen to lack a set of shared terms and labels, you realize why I’m pushing so hard to come up with a definition of open development processes: I’m not after drawing a line between a right and a wrong way of doing Open Source, as we have excellent examples in both camps, I just want to ensure a common understanding of different approaches in how software is built and evolved. A clear definition of Open Development would allow all of us to define how Open Source projects are run and managed, avoiding misunderstandings, providing upfront rules of engagement, and setting correct reciprocal expectations.
And at a very least, we’d know what we’d be talking about.