[Note: This is really two articles that I’ve smooshed together into one. At some point, I need to tease them apart and publish them separately to avoid muddling the ideas.]
If you hang around open source for more than a few minutes, you’ll hear someone talking about “giving back to the community,” as though it is some kind of moral obligation or repayment. And while contributing to open source purely out of a sense of altruism is great for philosophy students, the reality of open source contribution is very different.
Open source software is pragmatic. People contribute to it, primarily, for practical reasons. For example, most people contribute a change to an open source project in order to improve it for their own benefit, or the benefit of their company or customers. This has historically been called “scratching your own itch.” And you contribute that change to the project, rather than keeping it to yourself, not out of generosity, but so that you don’t have to maintain a separate version of the software with your change in it. It’s also to ensure the sustainability of a piece of software that you rely on. Making it better ensures that it will have happier users (or customers), and thus be more successful and last longer.
The other side of this misnomer is that one contributes changes “to the community.” Open source contribution, done properly, makes you part of the community. The contribution is to yourself, not to some other group of people that you’re not a part of. Contributing to the project is a step towards earning trust and gaining ownership of the project.
Projects which do not immediately attempt to capture contributors by welcoming them into the community are similarly misguided. This is often done for seemingly sensible reasons, but in the long run, it’s always a case of giving up the long-term health of the project for dubious short-term benefits.
The most common of these short term benefits is control. I, or my company, want to have more say in the direction of the project than any outsider. And the more control you strive to have, the greater chance that contributors will get frustrated and go away, or that users will choose an alternative where they have greater say in the project’s choices.
A lot of this has to do with a mistaken definition of “community.” A community is not a gleeful band of friends dancing around a campfire. A community is nothing more or less than a group of people with a common mission. If you are unsure what the mission is, then you’re not a member of the community. Similarly, a “community” which is unsure of their mission isn’t likely to last very long.
As it happens, friendship is often a side-effect of strong communities. This is simply because you’ve found your people – people who share your mission – and so friendships are easier to form. But friendship is not the goal of effective communities, just a happy outcome.
As always, I encourage everyone to read Charles Vogl’s book “The Art of Community.”
“Community > Code” doesn’t mean that the code is unimportant. Rather, it means that the code is a means to the end – the end being the mission of the community. The community (ie, the mission) is more important than the code, because it is the mission that drives the community. The code is a vehicle. The code serves the community (ie, the mission).
Open source projects should give a lot more thought to their mission. Not the function of the software, so much as what problem they are trying to solve. Communities that lose sight of their goal, or who never clearly understood it in the first place, tend to spend a lot of time casting about for things to do, because they’re not sure what they’re trying to accomplish.
The Apache Software Foundation’s mission isn’t “software for the public good” – that’s just a phrase for legal documents. The mission of the ASF is to provide a vendor-neutral place where important software can be developed without the threat of corporate capture. This is why the httpd project was created in 1995 – to ensure that the vendor capture that happened to the NCSA web server wouldn’t be likely again. And it’s why the ASF was formed – to ensure that one vendor didn’t get outsized influence in the projects.
All of our rules serve that goal. If a rule seems unmotivated by that goal, then perhaps it’s time to reconsider the rule. And losing track of that mission results in us being unsure how to enforce community mores that serve that mission. (Like single-vendor projects, for example, or too-high bars to inviting committers.)