Over the next month or two, some of you are going to hear a lot more about chemistry. Not in the ‘strange alchemic combinations of foul smelling salts and liquids’ sense of the word, but rather the other kind. The human kind. Baseball teams in the midst of pennant races will be dissected endlessly and relentlessly about their ‘chemistry’ – a kind of verbal shorthand for the culture that allows good teams to become great teams. The culture that allows a team to achieve what has never before been accomplished.
The very notion of ‘chemistry’ is abhorrent to some sabermetricians, implying as it does performance affecting variables that are entirely subjective and qualitative in nature – defying easy categorization and assessment. Personally, I’ve come around to the importance of chemistry since the magical October of two years ago, but irrespective of whether one believes that it has tangible impacts on the field, its existence cannot be denied. Chemistry – good and bad – is the inevitable product of a bunch of people from different backgrounds that are thrown into close quarters for extended periods of time and asked to perform at high levels. Virtually every group I’ve been a part of – sports team, development team, company – had some semblance of culture, of chemistry. It’s created and defined by the rules and relationships that both bind the group and give it definition.
The military, rigidly structured as it is, is famous for its chemistry and its culture. NPR just this afternoon ran a segment describing the unique culture associated with Scotland’s Black Watch regiment, and how recruiting was likely to be affected as this unit was enveloped within a larger whole for economic reasons. But why should this be the case? Why should chemistry be one of the defining elements of the military experience? Stephenson addresses precisely this question in Cryptonomicon, saying:
Having now experienced all the phases of military existence except for the terminal ones (violent death, court-martial, retirement), [Bobby Shaftoe] has come to understand the culture for what it is: a system of etiquette within which it becomes possible for groups of men to live together for years, travel to the ends of the earth, and do all kinds of incredibly weird shit without killing each other or completely losing their minds in the process. [1]
The chemistry then, the culture, can be seen as a mere veneer of accepted behaviors and command structure – much like civilization generally – that permits a group of individuals to interoperate together under often extreme conditions towards a common intent and purpose. The important question, of course, is who’s defining the behaviors and who’s giving the orders.
Which brings us – finally – back to the topic at hand: democracy as a means of project governance. In a true democracy, of course, the rules are simple. Everyone votes, majority rules. What became apparent over the millenia, however, is that while democracy sounds great on paper, it’s not the most efficient means of governing. Democracy, it could be said, doesn’t scale particularly well – for reasons similar to the N-squared problem. This has been apparent on governmental levels for quite some time; the solution in the United States, at least in theory, was to create a republic rather than a true democracy. In technical terms, a republic introduces a layer of abstraction between the voters and the command structure; voters elect officials who, again – in theory, will speak and act on their behalf.
What’s interesting is that open source projects are beginning to experience some of the scalability problems inherent in true democracy. One of my favorite project developers and maintainers, Gentoo’s Donnie Berkholz, had this to say of democracy’s impact on the Gentoo project:
We’ve become a drastically more democratic organization. But the question remains — Is this a good thing? When I think about where Gentoo was when we turned into a democracy years ago, and where Gentoo is now, I don’t see much of a difference on the large scale. We lack any global vision for where Gentoo is going, we can’t agree on who our audience is, and everyone’s just working on pretty much whatever they feel like.
Shortly thereafter, one of the Debian devs reacted to Donnie’s post, saying:
Opensource has some scalability limits. A recent blog post shows that e.g. Gentoo is suffering from similar effects as Debian.
I believe this is a matter of size, so I doubt that Ubuntu will be immune to this just by it’s Code of Conduct and similar things.
There is this well-known idiom: “too many cooks spoil the broth” – I think this applies to Opensource work, too.
Given that we all want “democratic” work, without having a cabal do the important decisions, I see only one way to resolve this.
Subprojects. Just like a distribution doesn’t inherit all the software package communities problems, we should try to avoid “aggregating” all the issues at a distribution level.
This problem – the problem of democracy – is certainly not unique to Gentoo, Debian or Linux distributions more generally. It is rather, I’d contend, a problem inherent to just about organization striving for true democracy. This is one of the advantages that commercial software organizations enjoy; there’s usually someone, somewhere up the chain of command that has command authority. Red Hat, for example, is not a democracy. Nor is SuSE. And before you jump in saying that they have disadvantages too, let me say that I agree. Go see my previous comments on Ubuntu, community and Red Hat if you don’t believe me.
But back to the problem at hand. If we can agree that democracy is in fact at the root of some if not all of the structural difficulties increasingly plaguing Gentoo and other projects, the logical question becomes how to fix it. No one would claim that democracy is perfect; as my colleague reminded the JavaOne audience a couple of years ago, even Churchill had his reservations, saying “Democracy is the worst form of government except all the others that have been tried.” Few if any of the projects I speak with would embrace a return to dictatorship models of governance p despite the fact that there are a number of successful project governed in just that fashion, so perhaps the republic model is an ideal compromise, as Michael Cummings suggests. Frankly, I’m not sure. In theory, it sounds like a nice compromise, but the electoral process can be problematic and committees are not known for being swift and decisive.
Ultimately, I think many open source projects are behaving just as governments have before them; vacillating between extremes. Debian and Gentoo were founded and run initially by individuals, and have transitioned in large part to democracies. As the projects grow, this model becomes less efficient and a return towards more autocratic styles of governance become more common. Frankly, I think we will see some projects return to the “benevolent dictator” model embraced by, among other things, Linux. What is clear is that just as there’s no single style of government that is perfect for every nation, there’s no governance model that will be universally successful. Each project will have to seek their own equilibrium on the ruling spectrum, and the process is likely to be painful.
In the meantime, the most important task for the individual projects is creating and fostering project cultures that allow groups of developers to work together for years, travel to the ends of the earth, and do all kinds of incredibly weird shit without killing each other or completely losing their minds in the process. Easier said than done, I know.
[1] I’ve been holding off on this post because I wanted to use that quote but left my copy of Cryptonomicon back in Denver, but this afternoon I happened to be searching for an audibook version of the novel for the drive back and ran across the Amazon Online Reader, which allows you to search through the book’s text. Excellent resource – thanks Amazon.
