Governance of open-source projects

One of my colleagues have tweeted about how open-source projects are individually unique and therefore individuals who seek to participate in such projects should focus on learning about their projects, as opposed to focusing on the “how to participate in open-source” kind of generic statement. It’s like the difference between knowing individuals vs a labeled stereotype like “Americans”.

That is very true in my own experience. After all, open-source is just a label that refers to the license, and it speaks nothing of how a project is run. Do they run by individuals or by companies? Do they accept patches or not? What are the expectations that new changes need to meet? Who calls the shot how? It’s all over the map. I’m gonna refer to these set of practices that together shape how a project is run as “governance”.

The thrust of his argument is about what individuals should do in the face of this reality, but I wanna look at the other side, which is what projects should do, given the real cost that this individuality creates.

I say that because too many people running open-source projects do not fully appreciate the friction that unclear and unique governance poses to potential contributors. I myself have been in these shoes before. This is in large part because for those people, the governance is so clear and obvious (after all they live & breath in it), it just slips their minds how much trivial but real overhead it adds to somebody new. Even a new contributor, who just went through the hurdle, tends to forget about that hardship pretty quickly. Even if they remember, unless somebody is asking “how can we make that more transparent and easy”, any retrospectives just tend to become “I took a bit of time but that’s OK and overall it was great”.

It’s like trying to cook in somebody else’s kitchen. It’s gonna be a struggle, and the result is probably not as good as you can do in your own kitchen. Imagine if your capabilities as an chef gets judged by it?

Every potential contrirbutor needs to go through this friction. They are numerous, not all of them come through, so the true cost of this is never visible from within the project. What a loss!

The easiest step 1 to improve transparency in the governance is to write CONTRIBUTING.md. Lots of info on the web how to write one, but here’s one example:

Personally, what taught me a real lesson in this is my experience contributing to somebody else’s open-source project and failing; I was fed up with the draconian bar that they placed on the new change. Back in the Jenkins project, we did some interviews with new contributors and learn their experiences. That was useful though you need to frame the conversation well because those people are usually very hesitant to say anything critical.

Projects under open-source foundations, such as Apache and Eclipse, sometimes have uniform governance, which increases the transparency. One of the values of joining a foundation. I’m writing this text in gedit, so I looked up its contributor guide and that was wonderful, thanks to Gnome foundation:

May clearer governance spreads in the world and may open-source flourish more.

Leave a Reply

Your email address will not be published. Required fields are marked *