Open Source Projects as Persistent Democracy Cooperatives

A new way to support open source work that fluidly allows any kind of community governance.

published: April 16, 2023 - last updated: April 17, 2023

The open source funding problem is well-known (opens new window) and important (opens new window). I've been working on the concept of Persistent Democracy (opens new window), and it offers a possible solution to the open source funding problem in the form of Persistent Democracy Cooperatives.

Before you make assumptions: this idea has nothing inherently to do with DAOs or blockchains. A DAO could choose to structure itself as a Persistent Democracy Cooperative, but a Persistent Democracy Cooperative doesn't at all need to be a DAO or use a blockchain. I don't think blockchains will solve many social problems. (opens new window)

Open source software derives most of its value from being open, since its value usually relies on network effects and anti-rivalry (opens new window). Putting the project behind a paywall destroys the very value of the project. However this creates a free rider problem (opens new window), since no individual has an incentive to financially contribute if something of value isn't being withheld from them.

The key insight of using Persistent Democracy Cooperatives to help fund open source projects is that using a project is very different from controlling it. By making an open source project a Persistent Democracy Cooperative it becomes possible to reward financial contributors and other approved code contributors voting rights to govern the project. This makes it possible to preserve the open anti-rivalry of the project while still withholding something important from those who don't contribute.

§ Persistent Democracy Cooperatives

In a Persistent Democracy Cooperative, voting rights are given in the form "democratic weights" members can "move around" at any time to vote for different things. Since votes can change at any time, elections are stabilized using a system of "stabilization buckets" (opens new window):

persistent democracy stabilization buckets

Most importantly these weights can be used to vote directly for the constitution of the project (opens new window), meaning every aspect of project governance can be evolved and democratically decided by the voting members of the cooperative. The constitution can decide who the maintainers are or whether they're elected in some way, the community standards or moderators, how members can use their voting weights to prioritize different features such as is done in democratic Shape Up, or anything else the community can come up with and democratically agree to.

Constitutions by their nature define a list of elections. If the voting members find it useful then some of the defined elections can be for other "nested" constitutions, creating a "constitution tree":

persistent democracy constitution splitting

persistent democracy constitution tree

§ Founder to community transition

Most early stage projects make most sense as "benevolent dictatorships" driven almost entirely by the vision of the founders. But as the project matures it becomes more and more valuable to increase community control. Many projects have found it tricky to decide exactly when and how quickly that transition should happen. Often the transition happens completely arbitrarily at the whims of the founders (or never).

Since Persistent Democracy is inherently based on resource voting (opens new window), it's possible to design the transition from the beginning to be smooth and transparent. We do this by designing the founding root constitution to:

  • Give the founders some form of extra voting weight that gives them essentially complete power over the project...
  • which "wanes" as the collective voting weight of the community members increases.

This could be done many different ways, but the most straightforward seems to be by giving the founders some large fixed amount of voting weight that can only be outweighed by a community with a large amount of collective voting weight. The large fixed amount would likely be best as a multiple of the amount of support necessary to make the project financially self-sustaining.

§ Would contributor voting rights be enough?

It would be easy to add additional sponsor benefits on top of voting rights, as long as they wouldn't distract from the core work of the project. For example Filippo Valsorda's "retained expert" model (opens new window) would be a way to make this voting rights model legible to large corporations, and benefits like access to a private community server (opens new window) would be similar for individuals.

It might be possible all these benefits would be a powerful enough community incentive to allow project maintainers to thrive. This is obviously an unproven idea, but I think it's promising enough to be experimented with. If you want to try this model please reach out to me so we can talk about how you could do so in the near future.

But we might need more incentives on top of that, especially for projects that are still developing and haven't demonstrated their value yet. In a companion post I talk about the more complex ideas of threshold conditional licensing and constitutional buyouts, ideas I'm more leery about that nonetheless could be extremely powerful.

Want to hear from me in the future?

Usual fine print, I won't spam you or sell your info.
Thank you! Come again.