Last week we announced that we were seeking help with Keystone, our reproducible, capability-based infrastructure for builds and deployments. The project is admittedly not in the shape we wanted for such an announcement - our original timeline was shooting for a fully working MVP in June or July, but the rapid implosion of the NixOS project has forced our hand. It has also forced us to accelerate our development plans, since we were originally using Nix as a temporary content store until we developed our own, but now we will need to build a basic content store for the MVP. Thankfully, the community response has been enormously positive, and we are already working with several nix users to write a proper, up-to-date technical specification for the project.

However, some have raised concerns about what our governance model is going to be, given that Nix is currently imploding precisely because of a massive governance failure. Our initial plan had always been to create something akin to the Linux Foundation to steward the Keystone project itself, which would be separate from whatever commercial applications Fundament Software builds on top of it. This ensures all development funded by Fundament Software would go through the same transparent sponsorship channels as any other company. However, it seems that Nix itself has a very similar governance structure, which is alarming, because it clearly did not work. This suggests that we should do something different, but we are not satisfied with "different", we want a governance structure that's better.

This is particularly difficult because "governance problems" have plagued open-source software for decades. Few projects have any meaningful leadership structure in place beyond someone who acts as the de-facto benevolent dictator, the major contributors, and maybe some moderators. Other projects, like Rust, have multiple organizations with a complex relationship that is ill-defined, resulting in things like the entire mod team resigning. Official ISO standards bodies for languages like C++ and C are often just as dysfunctional, but hide that dysfunction behind a dizzying array of rules, as Jean-Hyde discusses here. Attempts to control a for-profit subsidiary have almost universally failed, as the for-profit subsidiary inevitably consumes its parent corporation almost every time, as seen first with Mozilla, and most recently with OpenAI. You can't simply say your company motto is "Don't Be Evil" and expect this to stop Wall Street from sucking the life out of your products if you are obligated to maximize profits.

One common mistake in new governance structures is that they usually use first-past-the-post voting. This is poor choice because it is vulnerable to the spoiler effect, which can be addressed via Ranked Choice Voting. Quadratic Voting is also an option for things like RFCs, where people need to express priority in addition to preference. Sadly, it is very hard to find any governance models like this in active use, let alone ones actually running into Arrow's Impossibility Theorem.

Unfortunately, most people choosing what governance system to use have never heard of Arrow's Impossibility Theorem, which is very problematic when our society clearly needs to develop better systems of cooperation. Fundament Software is extremely invested in building better ways to collaborate and reach consensus, which is why the company is a Social Purpose Corporation. We do not have a fiscal obligation to maximize profit, only for us to pursue a social or environmental goal. Then again, we can say whatever we want and it doesn't mean a better result will actually happen.

So, what would a better governance structure actually be? What concrete actions can we take in the early stages of this project to ensure it serves the community and doesn't get captured by other interests? This is a difficult question, because the inability for a non-profit to control its for-profit subsidiary is one reason we were initially planning to have a wholly independent foundation, but NixOS has proven that even this level of separation is insufficient. Foundations with elected leadership positions invariably run into the Keys To Power problem, where we want community leaders to be democratically elected (increasing the number of keys to power), but we don't want people who aren't invested in the project to have voting power (decreasing the number of keys to power). Elected leaders are incentivized to minimize the number of voters, and any mechanism used to minimize bad actors could instead be used to minimize voters instead.

We can see this conflict of interest arise in some worker cooperatives, like WinCo Foods. While WinCo is technically a "worker cooperative", the actual voting power that controls the company is concentrated in the managers, which leads to many workers complaining that it feels "clique-ish" and "like a social club". This is obviously not what we wanted out of a worker cooperative, but instead of blaming greed or human nature, we can instead try to design a system that makes it harder to fall into these kinds of power spirals. For example, giving people multiple votes based on company tenure, and then using a quadratic voting system instead. This can still create an incentive to eject people out of the company before they gather too many votes, but this can be partially countered by requiring a supermajority of your own team to eject you, which can only be overridden by a supermajority of the entire company, or something to that effect.

Trying to apply this to an open-source project is harder because the difficulty of any particular change is not reflected in any externally observable metric - lines of code don't matter, and even if we had a good metric, Goodhart's law ensures it would cease being a good metric once it became a target. So we don't have a good way of "forcing" people to be granted votes, and if we create a system that has to "approve" contributors to be given voting status, it will be incentivized to let as few people as possible vote. We could try to force this by requiring X number of voters, but then leaders would be incentivized to reward loyalty instead of competence. Without a good way of measuring competence, most systems collapse into rewarding loyalty instead.

Of course, this doesn't make building a better system impossible, just difficult. It is certainly possible for us to build a system that it at least better than most current open-source governance structures, even if it isn't ideal. A separate non-profit entity seems like the most straightforward option, but it might not even be necessary, since there are low-income subsidiary options as well. Perhaps trying to maintain a separate non-profit entity could be used to mask the involvement of our for-profit company, which was a major problem with NixOS and Eelco's Detsys company. With this in mind, we invite the community to leave suggestions on what governance system they would like to see managing Keystone, but keep in mind that we don't need to make any decisions until we release an MVP and begin accepting donations.