@inthehands I linked to an article from tidelift in that post, as part of a discussion that money is at best part of the solution, and would just exacerbate the problems in isolation.

That link now redirects to sonar source, because they bought tidelift. I think rereading that section with that context really accentuates the point

@inthehands @jenniferplusplus

I think the problem is that the right governance structure changes based on maturity and scale of projects.

I maintain a couple of libraries where I wrote most of the code and they’re both more or less ‘finished’. I haven’t written any of the new code in them for a while (requirements never completely finish changing but they change very slowly in some cases), so my role is code review and checking that other contributors don’t do anything silly. In one, other people often jump in with code review so my main task is hitting the merge button. In both, a couple of people have sufficient access that, if I disappeared, the project could survive. I guess that fits the BDFL model, but there isn’t really anything that needs dictating, it’s more Unpaid Caretaker For Life. And that’s fine because the total amount of effort across all contributors is maybe two weeks per year, and my share of that is small. Any bigger structure of governance would take far more than the total effort that these projects have or need.

I’m also running a slightly larger project where I probably wrote a bit under half the code and that proportion is constantly shrinking. Several people are paid to work on it and a few companies are using it. There, I have made sure that there are two other people who have ‘owner’ roles on the infrastructure. This highlights one of the limitations with existing infrastructure though: anyone with owner permission is omnipotent. They can do anything, including adding more owners and removing owner role from the others. What I really want is to make certain actions require explicit consent from a quorum and others to happen automatically with an option for other owners to undo them within 24 hours. But even without that, two other people with their fingers on the emergency stop button is enough oversight for now.

I’ve also been on the FreeBSD Core Team for two terms. FreeBSD had around 300 active contributors back then, I think it’s more now. It has a lot of downstream users, ranging from individuals to large companies. It has a non-profit Foundation that employs some people to work full time and some contractors for specific tasks. There’s a lot of consensus building required for big changes and the governance structures need to reflect the scale. It’s not perfect but it’s one of the better models I’ve seen for big projects. But if I tried to adopt it for one of my small libraries, I’d have to run elections where only one or two people were eligible to vote (you must have made a commit to one of the FreeBSD repos [including docs] in the last year to vote in Core elections).

I suspect a lot of the problems come from changing scale. First, you have to notice that you’ve outgrown the existing structures. Then you have to do something about it.

For some people, giving up control is hard. My personal goal with any open source project I create is to minimise my effort. This is why I put effort into code review and engaging with bug reports, because if I can get one other person to have decent taste and actively contribute, that doubles my productivity. And when I’m in a position of going to code reviews and seeing the comments I would have written, I know it’s safe to step back. This is probably related to your point: if you focus on the code and not the people, you won’t train people who can replace you and so you feel you have to remain in control.

I had a similar discussion with quite a few people about the GSoC. A lot of people wanted successful projects to come out of GSoC and measured them as whether functional code lands. For me, the deliverable from a GSoC project is a contributor. If, after the project ends, the student understands the codebase, engages with the community, and wants to keep participating, that’s a success, even if no code from the summer lands.