paint-brush
Funding the Next Million Public Software Contributorsby@rndhouse
122 reads

Funding the Next Million Public Software Contributors

by rndhouseDecember 22nd, 2021
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Inspired by the recent wave of realizations that the vast majority of open source contributors are unpaid, I’ve been working on OpenFare: https://github.com/openfare/openfare

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Funding the Next Million Public Software Contributors
rndhouse HackerNoon profile picture



Inspired by the recent wave of realizations that the vast majority of open source contributors are unpaid, I’ve been working on OpenFare:


https://github.com/openfare/openfare


OpenFare has two components: a license and a tool. The license is a lot like the MIT License. In fact, it tries to be as permissible as possible. With one exception: when OpenFare licensed software is used commercially payment plans kick in.


But conventional payment plans are a hassle. For developers and for commercial users. No one really wants to deal with them. They are costly to produce, manage, and communicate to users. Most developers don’t want to care about them. And most companies won’t bother with them unless the software is really important.


And that’s where the tool component of OpenFare comes into play.

Payment Plans as Code

With OpenFare, payment plans are defined in code. For commercial users, this means that payment obligations can be programmatically managed across thousands of software dependencies. For developers, this means copy and paste setups.


Consider a software library that requires a company to pay $1 per year for its use. Now bury that library deep in a commercial project’s software dependency tree. OpenFare parses the entire tree and finds payment obligations. Then, micro-payments can be paid based on the applicable payment plans as defined in the library.


Imagine pricing an entire dependency tree. Imagine a pull request bot suggesting a payment plan change so that a contributor gets a cut.

Spectrum: MIT License to Copyleft

Let’s consider the costs of different licenses to commercial users. The MIT License is free.


Whereas, Copyleft licenses carry costs from the obligation to share modified source code. This intellectual property cost can be enormous. Perhaps a large fraction of a company’s value.


Let’s consider the benefits to software library developers (licensors). The MIT License does not enforce any compensation. Whereas, the Copyleft license makes potential code improvements accessible.


OpenFare exists between these two extremes. It offers a negotiable position. Library developers can specify their own payment plans which can be parametrized on a commercial user’s company metrics.


In this way, library developers and commercial users can reach a more equitable agreement.

Why now?

The technological landscape has experienced a seismic shift since the inception of most popular licenses. The MIT License is over 35 years old.


One domain that’s changed radically is money. We can now send and receive permissionless micropayments. Several services and digital currencies exist to serve this very purpose.


Further, the developer sponsorship experiment has fallen short of expectations. It fails because sponsorship reflects the attention game. Which does not correlate well with fundamental practical necessities. Three people sponsored the Log4j library.


OpenFare’s goal is to generate income for software maintainers who don’t capture attention but are critically important.

Moving Forward

We can start making this future a reality by using the OpenFare license and setting payment plans to $0. In which case the license would effectively be equivalent to the MIT License.


Using the OpenFare license in this way would slowly shift the status quo towards sanity and fairness.


Onwards!