Governance of Open Source

<p> When <a class="wikilink" href="/open_source/"> open source </a> grow in size, they also need to find ways to govern themselves. There is a spread idea that whatever happens on open-source must be publicly visible. But this opens the door to many different approaches[ <a class="litnote tooltip" href="/literature/@eghbal2020"> @eghbal2020 <span class="tooltiptext"> Working in public: the making and maintenance of open source software </span> </a> ] with different problems each. </p> <p> When projects grow in popularity, they will also attract users which are not necessarily contributors into the discussions. On the one hand this can give a plurality of views, which can add value to the code. On the other, it may end up draining the energy from the true maintainers. This, is what happened to Guido van Rossum in <a class="wikilink" href="/python/"> Python </a> . </p> <p> One possible solution is what <a class="wikilink" href="/nadia_eghbal/"> Nadia Eghbal </a> calls a <strong> one way mirror </strong> , in which everyone is free to watch, but few can actually participate. This keeps half the open nature of the projects, while protecting the maintainers from exhaustion. This is actually proposed by van Rossum and some projects are migrating into this direction. </p> <p> There is another approach, which is to never have a collective project overall. Some maintainers (the Lua creator, for instance) see pull requests as suggestions, but they never merge them into the code. <a class="wikilink" href="/breaking_the_notion_of_open-source_as_a_collective_effort/"> Breaking the notion of open-source as a collective effort </a> is a concept I haven't explored earlier. </p>