A Sustainable Commons for Open Source Software
bytecommons.comHi Leandro, I've been reading and thinking a lot about OSS sustainability recently, so this sounds interesting to me. I have several questions:
1. Have you seen StackAid https://www.stackaid.us? it seems like a similar distribution model, although for donations and not for access as I understand your proposal would be.
2. How would you enforce paying for the subscription to get access to the software?
- e.g. would people have to publish exclusively in your platform instead of e.g. GitHub?
- would the source be available for non subscriptors?
- would some sort of license hack be involved?
is the assumption that most OSS devs would already be paying their low rate subscription?
wouldn't it make sense for the rate to be somehow proportional to the benefit the company gets from the software? e.g. you'd want Amazon to pay more than 2k a year if they are selling a product around some OSS project.
5. Have you done the math for this, e.g. how much money would be available if most companies payed for this subscription and how much would maintainers receive?
Hi Facundo! Glad to hear :) we need more people thinking about this.
1. Yup! I love stackaid.us but donations mostly pray on social dynamics – eg. if i see you have a lot, i won't donate, if i see you don't get a lot, i might donate.
2. Initially we don't host sources themselves, so people can continue using Github to develop their software. For many licenses, the sources need to be available anyways.
So instead, it'd be package registries that we host. Think of it like doing `npm install express` – you most likely hit the npmjs.org package registry to download a specific published version of express.
This also means that usage for users stays almost the same – just need to configure your package manager to point to our registry.
3. I'd love to consider other subscription models. For ex. free for working on more OSS, or even free for non-commercial purposes. The main idea is to put the burden of paying upfront on the Companies.
To be honest, we should probably go harder on companies with pay-per-use models or revenue-tied fees, like they do in the gaming industry. But we'll have to iterate here.
4. As i mentioned before, we'd act only as a distribution network for packages, so your sources would live in Github or Gitlab or wherever they already are. We're not making the situation better, but at least its not made worse either.
5. Let's do some napkin math under the assumption that 90% of the revenue is split equally by package installs on a single programming ecosystem. (the final heuristic we'll use will be more complex than this).
Take Koa (js web framework) with ~6M installs/mo. It's depended on by 6,870 other npm packages, and used by 338,000 github repos. It's made 3,241 USD since 2016 in OpenCollective. That's not a lot of money for a rather impactful package!
If 1 company paid 2,000 USD / yr, and all that yearly installs would've gone to Koa, Koa would get 1,800 USD that year. Assuming 90% revshare.
If you throw another package into the mix, like Zod (with ~20M installs/mo), then the revshare for both goes like:
Total Rev: 2,000 USD
Shareable Rev: 1,800 USD
Total Installs: 312M
Koa share: 72M install -> ~23% -> 414 USD / yr
Zod share: 240M install -> ~77% -> 1386 USD / yr
If you grow to 10 companies, then the numbers grow 10x:
Koa share: 4140 USD / yr.
Zod share: 13860 USD / yr.
In practice given npm has 1M packages, and the dep graphs are deep, it won't be as easy as "10x in 10x out!" but it should give you an intuition of what we're trying to do here.
ByteCommons only makes money when everyone else makes money.
hi folks, OP here – happy to answer any questions!