tl;dr the following post has some factual corrections littered with a couple of additional concerns to think about. I think the big takeaway is to please read at least this open source governance survey.. My most important objection is that we need a (better?) mechanism to make forward progress than majority voting.
There are many, many open source governance models, the most successful of which have had something like a BDFL position. You opted out of all governance very early on in the SGB and TWG formation which must be very frustrating now, but we’ve done a ton of research and discussion on open source governance. Here is the bibliography of sources I read when thinking carefully and discussing the original TWG director position internally to the SGB:
- Eric Raymond’s The Cathedral and the Bazaar
- Christopher Alexander’s “The Timeless Way of Building”
- Producing Open Source Software
- open source governance survey PEP 8002 – Open Source Governance Survey | peps.python.org
- the new python model selected after the survey PEP 8016 – The Steering Council Model | peps.python.org
- What it feels like to be an open-source maintainer | Read the Tea Leaves
- Nadia Egbhal’s Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure
- Rust’s RFC process and Proposal for a staged RFC process · baby steps
- Rust 2019 and beyond: limits to (some) growth. graydon2 | Rust 2019 and beyond: limits to (some) growth.
- Rust Organizational Debt Organizational Debt (memorable quote: “Open source is the unpaid internship of tech.”)
I particularly recommend the Python project’s open source governance survey - they summarize quite a few governance models.
Let me take this opportunity to reiterate that the tech lead meeting I held used the IETF rough consensus technique (I am pretty sure I linked it to you last week, albeit a blog post about it and not the wikipedia page), so I mentioned that we came to rough consensus as a group on what was in that document. That doesn’t mean the roadmap was set in stone - in fact, it’s still up for discussion, though I’m hoping we’re getting close to something we can mostly all agree on. I think I could have done a better job communicating that distinction, but given that you are still characterizing that meeting and my future intentions incorrectly after our conversations about this, it seems like that additional communication didn’t matter very much.
Anyway, I really want to make sure the Stan project can actually make decisions because I want to ensure our forward progress and not just sit back on our laurels to slowly maintain code until no one is using it anymore. I’d need to see your proposed ad-hoc modifications to the Apache system fleshed out more to really think about whether it could solve deadlocks. But either way, I think an executive is attractive because that is the branch typically associated with actually executing. Usually votes are used within things like the legislative and judicial branches, which are designed to act as a conservational check and balance against the executive, to slow it down. See also design by committee.
I aimed to create the same “feature to-do list that everyone roughly agreed on,” but by actually getting those people in a room to discuss what should go on it and what we were actually going to work on . My hope there is that we’d have significantly more alignment and buy-in towards what we actually agreed upon. I’m not sure in what sense you think either roadmap is or was “binding?”
Paying the position was Breck’s idea, not mine, but I have to say I wouldn’t have taken the job without it - it’s a particularly shitty version of a normally fairly shitty job. I think we should pay positions that are 1) important to do well and 2) unlikely to receive volunteers that will be capable of doing them well (both in terms of technical and managerial skill as well as time commitment). So perhaps what I would try to do this time is 1) redesign the structure and then 2) have the SGB ask for applications. If they seem suboptimal and there are folks who would be better for the position, ask them how much it would take for them to take it and consider just paying that amount. (I’m not going to apply for any new paid positions).
That was me. I don’t actually think we should get rid of CTO the idea, but we can definitely change the name and make it clear that this position exists to break ties or deadlocks. And instead of “making major technology choices and technical decisions” we can just say that they will design or approve internal Stan APIs and, together with the TWGD, decide what the TWGD’s contractors work on. This would mean working together to co-write up essentially a list of tasks or focus areas with priorities attached. This is the most concrete part of technical vision setting and is perhaps enough in a project like this.
Bob, does that sound better?