On the eve of tomorrow’s OSBC conference, it seems only appropriate that of the items in my queue, the first one out of the gate should be something open source related. And the topic of today’s discussion is governance. In other words, how are the logistics of a given open source project or community handled? If one includes the choice of license as a question of governance, as I would, then it’s probably true to state that that aspect is the most popular at least from a mainstream perspective.
But as we can increasingly see a world in which the open source licensing choices are better understood and consolidated, if not to the complete satisfaction of those concerned about potential proliferation issues, the really interesting questions might be the other aspects of project governance. Issues such as how is the project structured? Who’s responsible for direction? Where does that direction come from? Or on a more detailed level, who has commit priveleges? How many different code entry points are there for a given project?
Sun’s new open source head honcho Simon Phipps spoke about specifically about this issue at last week’s FROSUG, but I’ve had nearly a dozen similar conversations with open source folks recently. Licensing conversations are so 2004, I’ve been told. Broader open source governance, on the other hand, is one on everybody’s mind. Not just the projects getting off the ground; established, sizable projects are included on this list. From the GNOME folks trying to decide what the optimal board size is (here’s Mr. Waugh’s take) to the implications of potential governance structures on Open Solaris (here are Raible’s notes on Simon’s aforementioned talk), it’s clear that governance is on the minds of many within the open source community.
This is to some degree unsurprising, as human nature being what it is opinions on topics such as project direction tend to vary widely (and passionately) and further, some of the issues are quite complex and lack obvious answers. But what I have found surprising is the increasingly common citation of Apache as the model to follow. I’m not surprised due to any lack of respect for the Apache organization (I promise, Bruce ;), but rather because Apache does not necessarily share the philosophy of hugely popular open source projects like Linux – they’re not exactly GPL zealots, remember.
From the way that it handles developer hierarchies and commit rights to its ability to generate and sustain communities to its sheer momentum, Apache is held up by many as a model to learn from, if not replicate wholesale. I’ve had probably a dozen conversations in the past few weeks in which folks from open source communities large and small paid Apache its due – even communities dedicated and committed to reciprocal style licenses. This credit is, I’d argue, a validation not of Apache’s licensing preferences but rather their broader strengths in project governance and logistics.
So the advice that I’m likely to be imparting to the emerging open source projects I speak with, both here and otherwise, is not too dissimilar from Gatorade told kids in its Be Like campaign. Maybe you don’t want to – or can’t be – exactly like Mike, or Apache in this case, but you could sure pick a worse model to follow.
Update: This entry was modified in its original form against my wishes; either in the original posting or a subsequent typographical correction the bottom half of the entry was lost. If you read it this morning and were rather confused, that’s why. I’ve tried to recreate the original entry here – hence the update, but can’t promise that it’s the same as it was. If anyone using NetNewsWire happens to have a diff of the original entry, let me know as I’d like to be sure I didn’t forget any of the points I was trying to make. But just as an FYI to those that might believe I’m self-censoring, I’m instead directing the blame to the lack of good blog authoring tools 😉
