Open source projects like Go get flak for being closed to outside contributors, but this may have less to do with Google and more to do with best practices.
Why a closed open source project
Why a closed open source project
We throw the word “community” around so much in open source that we’re at risk of believing all sorts of bizarre things about how open source works. Like, for example, that open source is a pure meritocracy or, just as erroneous, that it’s a democracy. Both errors find their way into Chris Siebenmann’s crtitique of Go Language. As he writes, “Go is Google’s language, not the community’s.”
This doesn’t mean others can’t contribute to Go—they can—but it’s a one-way contribution relationship. As he continued, “Google is the gatekeeper for these community contributions; it alone decides what is and isn’t accepted into Go.”
The question is whether that matters.
Open is as open does
Chef co-founder and former CTO Adam Jacob certainly thinks so. While careful not to assert a moral judgment, Jacob stresses in a series of tweets that, though open source, Go is anything but open in terms of community involvement:
Nobody who wants the level of influence afforded a core member can get it. The result is that, while the decisions may be good, it isn’t a community resource. It’s the Go core team’s, at the most charitable. Google’s, at the least. But with no mechanisms for allowing others to participate, the[y] close off equality of opportunity.
It’s great that the language itself is open source – the community could always fork if their leadership turns yucky. But that’s precisely the point – all the power in the brand, in Google, is totally inaccessible to the community at large. That doesn’t make it wrong, but it does mean that the Go core team is an unjust body – those with power will keep it. Those without it will receive their largesse. Nobody who wants to work within that institution will get the chance, without that Google badge.
The problem with this line of thinking is that it doesn’t give sufficient weight to the cardinal virtue in open source: The right to fork. Nothing stops a rival from forking Go and creating their own Go. Go Language is trademarked by Google, but that doesn’t stop someone from forking Go and creating OpenGo. So, yes, Siebenmann is right to argue that “Go has community contributions but it is not a community project. It is Google’s project.” But he doesn’t explain why this is necessarily a problem.
After all, what he says of Go is true of nearly all successful open source projects: “[T]here is a common feeling that Go has done well by having a small core team with good taste and a consistent vision for the language, a team that is not swayed by outside voices and is slow moving and biased to not making changes.” Yep.
SEE: Open source vs. proprietary software: A look at the pros and cons (Tech Pro Research)
Or, as Googler Ian Lance Taylor has noted,
All successful languages have a small set of people who make the final decisions. Many people will provide input to this decision, but no successful language—indeed, no successful free software project of any sort—is a democracy. Successful languages pay attention to what people want, but to change the language according to what most people want is, I believe, a recipe for chaos and incoherence. I believe that every successful language must have a coherent vision that is shared by a relatively small group of people.
Perhaps Go is different because the core committers all work for Google. But whether that core team is sponsored by a company or is comprised of people from a variety of companies, open source is never a free-wheeling democracy. As Simon MacDonald has written, “Preventing scope creep in any open source project is a key to its success.” This is more easily managed by a small team, in part because they know what’s at stake if they are too promiscuous in what they accept, according to Paul Ramsey: “Core teams are not taking new features willy-nilly, precisely because they know they’ll be stuck maintaining them for ever after.”
Democracy, in short, is not the open source way. Meritocracy, unfortunately, also isn’t (as much as we’d like it to be otherwise), given how hard (or impossible, in Jacobs’ view) it can be to break into a project’s core committer team.
So is community a sham?
No. “Community” doesn’t mean (or shouldn’t mean) an unfettered right to have pull requests accepted. It doesn’t even require open source. What community means will differ by project (or product), and will include a healthy mix of users, contributors, and committers. That people can’t get their pull requests accepted doesn’t necessarily mean it’s a closed community. Sometimes, the very best thing a community can do for its health is to keep contributions tightly vetted by a small group.