Further Thoughts on the Fair Share Clause

This started as a short reply to Erlend S. Heggen's "The Fair Share Clause - A thought experiment for sustainable open source", and got long enough that I really did want to capture it in its own blog post. Heggen @erlend_sh is a Community Advocate at Discourse, the open source forum software. The description of Discourse's end of 2017 donations to open source projects they depend on is also a great read. Kyle Mitchell's writing and his License Zero project are name checked, and I have posted about them briefly recently, but consider this another reminder that you should look at them closely.

This is a great thought experiment to write up — thank you for sharing. This is definitely something we are digging into and trying to figure out as we work on low-level Ethereum infrastructure at .

I need to do a longer write up on our thinking, but just yesterday we came up with the idea that maybe there is a model that is like Carbon Credits. This would also mean that a company like Discourse might “equal out” because of the investment in producing open source software. But perhaps everyone committing to building giving back into their business model really is the best path.

There are the beginnings of some experiments such as Moloch in Ethereum that are related. It is more of a guild / membership structure, which is not really what you describe.

One thing not addressed by your Fair Share model is the “getting started” model. What is the equivalent of friends & family or investor funding to get a piece of infrastructure built?

Other labels we are considering are tithing, sponsorship, and patronage. We think of sponsorship as ongoing, and patronage being a one off grant that gets new projects or major features built. Your model is closest to tithing, with a better analogy than a religion :)

I think our biggest challenge is education: that tragedy of the commons is a real thing, and that we should attempt to fight against it. That all businesses benefit from open source infrastructure, and that with funding, more & better software gets built and maintained.

The other challenge is deciding what we’re selling. Deciding what to sell also means figuring out who your customers are, of course. In the Ethereum ecosystem especially, contributions to base infrastructure make an impact to the entire running public blockchain very directly.

We want to sell the past AND the future1, so how many sponsor/patron benefits do we need to include beyond a logo in order to make the sale? And how many of those benefits slide into something that actually looks like consulting? And, if we want to be akin to something like a private research institution, is consulting something we should consider?

More writing and thinking, and many more customer discovery calls in our future. I also look forward to digging into these topics during the Business Model Ring at the EthMagicians' Council of Prague.


The Special Projects & Decentralized Engineering Company is a Delaware Public Benefit Corporation dedicated to support individuals and small teams building sustainable open source projects. Our first project is FISSION, starting with FISSION Codes and FISSION Translate. They are both initially targeted at the Ethereum smart contract ecosystem, although the design is portable to any smart contract system.

  1. That's a reference to Kyle on Tidelift's model of selling software support for open source projects, aka "the future". Being able to monetize software you've already built is a stronger model than "just" maintenance. 

Originally published
Last modified at