Governance of Open Source

First published:

Last Edited:

Number of edits:

When open source 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[ @eghbal2020 Working in public: the making and maintenance of open source software ] with different problems each.

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 Python .

One possible solution is what Nadia Eghbal calls a one way mirror , 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.

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. Breaking the notion of open-source as a collective effort is a concept I haven't explored earlier.


Backlinks

These are the other notes that link to this one.

Comment

Share your thoughts on this note
Aquiles Carattino
Aquiles Carattino
This note you are reading is part of my digital garden. Follow the links to learn more, and remember that these notes evolve over time. After all, this website is not a blog.
© 2021 Aquiles Carattino
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Privacy Policy