The Fair Share Clause
A thought experiment for sustainable open source.
Last year Discourse, the open source company I work for, for paid out $55’000 to open source projects that are business-critical to us, infrastructure chief among them. While we got some useful PR and good-will out of the donation, we were really just paying off our debt. Had it not been for these projects, Discourse could likely never have been built by 3 co-founders with modest seed funding.
Paying this money was entirely optional, but what if it wasn’t? What if that $55000 was the price tag put on the open source software which Discourse was built on top of. Ever since I read Nadia Eghbals “Roads and Bridges” I’ve been obsessing about sustainable open source¹. SAAS, open core or both work great for end-user products like Discourse, but infrastructure is sorely lacking some safe go-to business models.
To date, the two most promising solutions on my radar are Tidelift and License Zero. License Zero is easily the most controversial of the two, since it challenges the very definition and philosophy of open source. I wholeheartedly support what L0 is trying to do and I predict it’ll get its first foothold in the middleware stack². Tidelift on the other hand is already going strong, but just like L0 I’m more interested in helping developers sell their past rather than their future. As Kyle Mitchell aptly put it:
Tidelift is a start-up company trying to broker sideline service contracts between large corporate consumers of open source software and open source maintainers. In conversation, I’ve described them as a kind of “adapter pattern” bridge between the enterprise and maintainers. I’ve also generalized their approach as selling the future, or promises about work you will do, as opposed to the past, or the work you’ve already done. Dual licensing, and License Zero especially, help developers monetize their past. Which is why a single maintainer or project could conceivably take both approaches concurrently, as Tidelift themselves have pointed out.
What I have in mind is a softer alternative to the likes of the Parity license or the hotly debated Commons Clause; a way for existing projects, unable to change their license, to capture a fair share of the value they’re generating in the least intrusive way possible.
A Fairtrade Certification for OSS
The Fairtrade certification initiative was created to form a new method for economic trade. This method takes an ethical standpoint, and considers the producers first.
My intention is not for this to be a legal document, but rather a social contract. Similar to how the Fairtrade certification leaves it up to consumers to make informed decisions with their purchases, this clause would leave it up to open source maintainers to make an informed decision on which company they should invest their time in. For companies however, should they choose to honour it, the Fair Share Clause will function much like taxation.
The document
Alongside any open source license, open source maintainers would add a “Fair Share Clause” document that states something along these lines:
“If you use this software in a commercial venture, we ask that you pay your Fair Share Fee as per fairshareclause.org.”
fairshairclause.org would explain the fundamentals of the clause, the details of which are theorised below.
Fair Share Fee
How much:
Any company that pays its employees a salary of $100'000 or more a year is asked to pay the Fair Share Fee.
There’s a lot of different ways to determine this fee. So far the simplest way I can think of would be to pay up to 5% of a company’s entire budget for salaries. If your company pays $500’000 in salaries per year, your annual fair share fee would be $25’000.
Why 5%? Like any pricing it’s based on lots of intangibles. Open company budgets like that of Buffer are hard to come by but as far as I can tell, 5% is a very reasonable ask. It’s also in line with Matt Mullenweg’s Five for the Future:
I think a good rule of thumb that will scale with the community as it continues to grow is that organizations that want to grow the WordPress pie (and not just their piece of it) should dedicate 5% of their people to working on something to do with core — be it development, documentation, security, support forums, theme reviews, training, testing, translation or whatever it might be that helps move WordPress mission forward.
Who will do the work:
This is where I remind you that this is strictly a thought experiment, conceived primarily for the purpose of debate and fresh thinking. I do however believe that what I’m describing here is entirely doable with the tools we already have at our disposal.
The most established of these tools would be OpenCollective. On the more experimental end there’s the likes of Decred and oscoin.
When: Probably every quarter.
Why: That’s where the public ledger comes in.
The public ledger
As soon as your company pays its fee, it is added to a public ledger. This is key to the Fair Share Clause. There are no legal or direct economical ramifications for opting not to pay the fee. However, only those companies that pay their dues are added to this list. Should the list ever gain enough traction it would become an important impetus for compliance.
So let’s come back to the why of it all: Failing to pay the fee within 90 days of exceeding the minimum would result in a 1 year ban from The Ledger. However, the 5% fee should be “aspirational”. So long as a company pays at least 1% they get added to the list. The ledger would rank companies according to their fee/employees ratio, looking something like this:
+------------+-----------+-----------------+--------------+
| Company | Employees | Fair Share Fee | Per employee |
+------------+-----------+-----------------+--------------+
| Automaggic | 800 | 2'000'000 | $2500 |
| Blue Hat | 12'500 | 25'000'000 | $2000 |
| Flexible | 900 | 1'350'000 | $1500 |
| Crucial | 2500 | 2'500'000 | $1000 |
| SaltCRM | 430 | 215'000 | $500 |
+------------+-----------+-----------------+--------------+It’s a little bit like forming one major workers’ union for open source maintainers. As long as a critical mass of workers abide by the rules that they themselves have laid down, i.e. “do not work for a company that does not pay their Fair Share Fee”, then the industry has no choice but to play by those same rules.
More incentives could be added over time, e.g. a job board exclusively available to paying members. Lastly, we might consider putting a spotlight on particularly egregious companies, well known for being major beneficiaries of open source without paying their dues.
Voting and the Common Fund
Every company gets to earmark (not gonna go into particulars about this here) which organisations 50% of their monthly fee should go to. The remaining 50% goes into the “Common Fund”.
To be part of the Common Fund You gotta register. Two types of entities have the privilege of signing up for this registry, for different purposes.
1. A company that pays the fee.
As part of paying their Fair Share Fee, a company needs to state their dependencies. In addition to automation tools they may also manually add other dependencies that didn’t get picked up. Any dependency listed is effectively nominated to be a recipient of the Common Fund, as is the first layer of dependencies for that library.
Let’s say webpack used the Fair Share Clause. The imaginary company Automaggic uses webpack, so they would have to register to the Common Fund in order to start paying their Fair Share Fee. In doing so, they would also be listing their other dependencies. One of their dependencies listed, Express, has 30 dependencies. In total, one company registering for the Common Fund would quickly result in tens or even hundreds of packages listed as eligible recipients. This enables the Fair Share Clause to have an impact far beyond the handful of libraries that initially adopt it.
2. A maintainer of a fair share library or nominee
Any email address listed³ for a fair share library is eligible to register for the Common Fund⁴. Package maintainers will essentially act as gatekeepers for votes. Registration grants the ability to vote, and the option to claim a stake in the common fund on behalf of any package you’re listed as a maintainer for.
In order to stake a claim you’d have to register a recipient, which could be anything from a person to an organisation or even a company. I won’t go into detail about staking now, but it shouldn’t be much more complicated than saying “yes, I’d like to receive funding for this package” and “if I receive any funding, send the money here”.
Every single package maintainer gets 10 votes⁵, which they can use to vote on projects listed in the Common Fund. The idea is that the maintainers themselves get to budget the Common Fund.
To make your votes you would
- enter your email
2. confirm email and get access to voting interface
3. distribute the votes
The vote will be locked in and goes into effect once every quarter when companies pay their fees and funds are subsequently paid out to the packages with the most votes. (exact mechanics yet to be determined).
- You’re not allowed to vote on packages that you’ve been authenticated as a maintainer of.
- You have to spend all your votes, and you can only spend one vote per project.
- As soon as voting has closed, all voting data will be public, further mitigating any gaming of the system.
Imagine an interface where you search for “Babel” and “Babel on OpenCollective” shows up as the only available recipient that has staked a claim for Babel’s share of the Common Fund. By voting on Babel (and by extension, OpenCollective’s proxy-organisation for Babel), you’re effectively delegating a tiny portion of equity in the Common Fund to them.
Potential impact
Let’s say the top 20 open source companies in the COSSCI all commit⁶. Between them they have 30'000 employees. For super-simplicity’s sake we’ll move them all to Canada and pay them the industry average of $50’000.
That amounts to $75'000'000 owed in Fair Share Fees. Half of that is distributed by the companies themselves. The other half, $37'500'000, is under the jurisdiction of the maintainers.
If there are 10'000 voters with 10 votes each, every vote is worth $375.
If just 1000 of these voters delegate one of their 10 votes to Babel, that amounts to $375'000 going to Babel every year. This money should not be replacing any existing or future revenue streams Babel might have, e.g. any company set up around it. This is simply the money that the Babel maintainers are owed for making and sharing the Babel software under an open license.
Carte Blanche
This clause would not be additive. As long as you’re using at least one project with the clause, you’re already paying your dues for any subsequent projects that have adopted the Fair Share Clause. It’s an open buffet from here on. Meaning, if your company is already paying the fee you have a strong incentive to use as many OSS packages as possible to really get your money’s worth!
What it would take
I’m under no illusion that what I’m proposing can be done with a snap of the finger, so let’s have a look at the impressive sequence of events required to go from hypothetical to reality:
- At least one widespread infrastructure library would need to adopt the clause, e.g. webpack or Babel.
- The package manager of the early adopter library would also have to play ball, i.e. npm
- OpenCollective or similar would have to agree to act as the payment collector.
- A voting system would have to be built, probably by whoever accepts the money as they’d have the most incentive.
- A handful of companies would have to honour the clause to get a snowball effect going.
I have no specific plans to pursue this further for the time being, but I figured the best way to advance my thinking at this point was to invoke the power of the crowd. Virtual penny for your thoughts.
Footnotes:
(1) Kyle Mitchell prefers the term gainful open source. It’s an illuminating distinction, but personally I don’t think of “sustainability” as limited to “just getting by”. Oftentimes making a handsome profit is the only sustainable outcome.
(2) Shared source is on the rise in game development. See Unity3D, Unreal Engine or CryEngine for example.
(3) Problem: soft skill contributors would have near zero representation with the package manager approach. However this could easily be remedied by simply trusting them and adding their email to the packages they help maintain.
(4) Authentication is a tricky topic. I’m aware of the possibility to game the system and fully acknowledge that I have not yet thought through every conceivable hack. Authentication protocols like the ERC-725 alliance might help with this. Though a far easier first iteration would simply be built on top of a centralised stack. All we need to get started is a sufficiently trustworthy leadership, which we will aim to gradually decentralize over time.
(5) Could also allow unlimited votes, which just dilutes their share. But that could also dilute a vote spread to the point that it’s meaningless, so it’s just easier to start with 10 and adjust as we go.
(6) I consider the COSSCI companies to be at the forefront of open source stewardship. Google, Amazon and the other Fortune 500s should be under much heavier pressure to pay their dues. Unfortunately it’s highly unlikely any of them would be a first-mover.
