I’ve been reading this article about Django’s governance and a proposal that is on the table to remove Django core, in favour of “Mergers” and “Releasers”. Quite interesting.
It’s still very early days for Grin, but reading the underlying motivation I can see us in a similar situation at some point down the road:
Being a Django committer (“core developer”, “Django core”, or whatever you choose to call it) is still seen as a high-prestige title, and committers are given a lot of deference by the wider community. Given that the actual day-to-day governance rarely relies on the committers having any sort of special powers or prestige, this is a problem, especially because it seems to create an impression among potential contributors that they’re not “good enough” to match up to those awe-inspiring titanic beings (please note sarcasm: I am not anything close to awe-inspiring).
…
Removing the distinction between godlike “committers” and plebeian ordinary contributors will, I hope, help to make the project feel more open to contributions from anyone, especially by making the act of committing code to Django into a bureaucratic task, and making all voices equal on the django-developers mailing list. By itself this won’t solve the issue of recruiting enough new contributors, or the lack of diversity among them, but I think it will put us on much better footing to tackle those problems.
In any case, just a curious development. I think we have a lot to learn from the experiences of other open source software development projects.
I think there will be some time before Grin stumbles across the issues they are trying to solve with this proposal, if at all. Certainly, I am not sure this approach is the right one for them, moreso for Grin but nevertheless it’s interesting and yes we should be paying attention to solutions to these types of problems in the space. Tragedy of the commons is commonplace in open source projects.
The way I understand it, is that they feel they don’t have enough contributors, and that the “elite” status of a special few committers makes it harder get contributions from a wider group. Couldn’t it be argued that Grin already suffers from this problem today? How many of merged pull requests that touch code in any meaningful way today come from people that are not committers?
I think Django’s case is very different from Grin’s even though the end result looks the same at the moment: not many external contributions. We should not be conflating the two cases though, each project has its own reasons for being here:
Django is a mature project that started 13 years ago and has been through all phases an open-source project can have. Excerpt from the blogpost:
the types of easy bugfixes and small features that often are the path to growing new committers have mostly been done already in Django
Also, another problem brought up is many committers are inactive:
and many committers (there are around 40) are inactive.
Last, its current governance structure looks quite complex and I am not convinced figuring out how commit access is established is going to simplify it, although I do agree with caveats that it’s worth improving, especially when you are left with many inactive contributors.
From there, a lot of bureaucracy has to occur to make this happen:
The Django core team has to vote on the proposal. Changes to the organization and governance of Django the open-source project require a four-fifths majority to pass.
The Django technical board — which has absolute veto power over changes to organization and governance — has to consider the proposal and not veto it.
The Django Software Foundation has to consider the proposal, and its Board of Directors has to vote to accept the DSF‘s role in the new governance structure and to provide any necessary resources.
Grin is a young, experimental project and has yet to prove itself to the public (can’t really happen before mainnet). We cannot really expect a boom of new contributions at this stage, but we can set the groundwork to appeal to new contributors and I think our simple governance structure* and being transparent about how decisions are made both in development and governance (public weekly meetings at gitter) helps in that direction. We can definitely do a better job at marketing ourselves (better website design, wrap up mission statement, conferences, blogposts, etc.) Also, from a new contributor pov, Rust is certainly making it harder to ramp up vs Python but from a long-term project maintainance pov, Rust is a better choice than most alternatives (I would only compare it to Golang).
All in all, I don’t think commit access and (the lack of many) external contributions is (yet) a problem for Grin.
*not saying that it’s perfect or it cannot improve
The god-king founder problem is real. Not only does it suppress innovation and engagement from the community, but it ties the core contributors to a certain role which takes up time and limits energy to focus on other things (like innovation or other projects). It’s also a central point of failure that doesn’t scale, and frankly… it’s just kind of weird when there’s an “in” group and an “out” group. I’ve actually been thinking about this a lot in relation to Grin because I’m seeing a lot of great ideas submitted here in the forum, but I have no clue how those ideas get translated into real action, or even how community sentiment is gauged to make decisions.
Also, while I don’t know much about the Django community, I’ve been blown away by the awesomeness and organization of the Rustcommunity. There’s docs and books for everything! as well as infrastructure so that people can easily make their own. There’s also a clear process for creating external libraries and making them available to the community. The whole thing just feels very well designed and collaborative, and rightly so, because that was the intention. From what I can tell this minimizes the amount of governance needed while also opening up the community because people who want to hack on something have a clear way to do it.
clear goals (direction)
clear reasons why they’re doing this and not doing that (a decision process)
clear progress following through on creating the tools and resources that make it all possible (infrastructure and community building).
Of course nothing is perfect, but this seems to reduce confusion and conflict so people can engage and focus on building. It’s also nice for someone new to the community to be able to see all that in the open rather than some projects where there’s definitely a barrier with an “in” group making decisions and an “out” group who just sees the results.
I’ve been following the project on and off for a few months now, and have read through all of the docs as well as most of the forum conversations. I can state, clearly and honestly, that I have no idea how real decisions get made other than that there’s a few guys who have been working on this for a while and they’re generally friendly and seem to have agreed to work together to build some cool stuff. Here’s some ideas to improve the process:
in the Governance category pin a post that explains how this process works, where you can find the agendas and decisions from past meetings/processes, and how you can contribute to governance.
in the Contributing section add the same information so people know how to contribute to governance.
in the Governance section of the website create an archive of all past meetings, decisions, and milestones. This includes what was proposed, why a decision was made instead of others, and what the direction is moving forward. It would be great if this aggregated stuff from the mailing lists, forum, and gitter all in one place.
The whole point of open community driven projects is that they’re open. Talk is cheap but I think that clearly showing that it’s a priority will go a long way inspiring and incentivizing people to engage and contribute. I think this will also allow people who often don’t have a voice (real live users, cough*) to participate and take ownership of the project. Code can be forked, but communities are what make these things valuable
