Nobody pays for open source. We can force them to
14 points by giacomo_cavalieri
14 points by giacomo_cavalieri
I'm bored on a plane so I'm going to do the Lord's Work for you:
First, the registries meter corporate use and charge for it. They already meter it. npm, PyPI, Docker Hub and Maven Central all have rate limits, authentication and enterprise tiers, and the mirror vendors that sit in front of them bill by the seat.
Second, a fixed slice of that revenue is a royalty, and it goes to the packages.
Third, the people who do this are the people who own the domains. There are about a dozen registries that matter. Every maintainer already has an account on the one they care about, with a name attached and a way to get paid either present or one form field away.
The article is long and this part is about 2/3 of the way through, but it does justify why this the model that it proposes.
Isaac Schlueter, who created npm, has argued that we should stop charging for support and start charging for access: if you're a for-profit company, you don't get the code without paying. I agree with the shape of that, but I'd move the toll booth, because if you put it in the license you get forked, and if you put it at the registry you get JFrog's revenue.
So here's the rule I'd like us to have: the people who run the meter pay the people who make the thing worth metering.
I do think this is a pragmatic solution. Value is being captured by the big players, and the registry owners/maintainers have a really big lever that they could pull.
Usage metering is sort of backwards. The largest and most successful corporate users have internal mirrors for performance, auditability, privacy, cooldowns, etc. They often have lower use than small users who do naive things like re-fetch all dependencies every CI run. Usage is at best uncorrelated with the business value delivered.
There are also significant tax and financial regulatory problems with the approach described. But I've also been thinking about a solution structured along these lines.
You weight by presence in paying customers' dependency trees rather than raw downloads…
Thanks, I missed that and got the wrong idea from the paragraph about "First, the registries meter corporate use and charge for it."
Understandable! The whole thing is a bit long-winded and that in particular was misleading. But I think it’s a crucial point that distinguishes this from the Spotify model, enabled because, unlike music, we actually write down our “samples” and “influences” in machine-readable form so the pro-rata payout doesn’t have to be just a top-level popularity contest. Imagine if the Winstons automatically got a share of every song using the Amen Break…
On the flip side, I am running devops at a small tech company and I have to run an internal mirror for all the reasons you provided, and I would love to not have to run it myself.
Our docker containers rebuild a lot of stuff from scratch for reproducibility and auditing purposes, and Ubuntu's public mirrors suck. JFrog and Atlassian don't do very well and are very expensive, and I love the small-time vibe of Proget but it also has the small-time vibe of randomly breaking a little once every six months 'cause people don't heavily use the features we use. I'd love it if I could realistically buy a service that did all this for me, complete with being able to run our own copy on-prem for local use and in AWS for CI builds. Instead, every few months I search for a new public mirror that hasn't rate-limited us yet. We could definitely justify paying 5,000 USD/yr for something like this, or maybe twice that -- as long as it let us use our own storage instead of gouging the shit out of you for it like JFrog has started to.
I said it multiple times : it’s not about paying people. It would even make it worse. It’s a about exploitation of the commons. And for that, the answer is so simple : use a copyleft license.
I feel like this falls into a lot of the traps that every "pay maintainers" effort seemingly inevitably falls into.
First and most importantly, this would contribute to maintainer burnout, not help it, because it's yet another scheme premised on requiring every open-source project to also become a de facto business. Even if most projects never register a formal entity, the increased overhead and burden of being paid for the software you provide is very real. "Congratulations, we've made your life easier by adding more tax forms to it!" is not a sentence that should ever be said out loud, but is implied by this and many other "pay maintainers" schemes. Oh, and forget about exemptions from laws that apply to commercial software, because once you go down this road you become impossible for the law to meaningfully distinguish from commercial software. This is a big part of why many previous schemes to collect fees on behalf of maintainers have been so absolutely detested by many of the maintainers the fees were allegedly meant to benefit.
Second is that this does not solve the biggest issue actually facing open-source maintainers, which is the burden of dealing with low-quality and anti-social interactions in their issue trackers and repositories. This has gotten significantly worse for many maintainers in the age of LLMs, since the cost (to the flinger) of flinging tons of slop at a remote repository is now astonishingly low. The handful of large companies targeted by this new "pay maintainers" suggestion are, aside from LLM vendors, largely not responsible for or involved in doing that, and forwarding a few dollars a month from those large companies will not meaningfully help a maintainer with a PR queue full of diffs that delete the CI config to try to get it to pass (a real thing I've really seen LLMs do), nor would it have meaningfully helped with the pre-LLM era of angry entitled users getting feisty in the issue tracker.
Third and finally, this is just "source available" commercial software by another name and with extra steps. If you want to encourage people to move toward that model, you can do so, but you really really really need to stop calling it "open source" and start being honest about the fact that what you really want is to get rid of and replace "open source". Trying to co-opt the popular and well-known branding of "open source" for something that isn't actually open source needs to go away.
I used to think supply chain security would be solved by insurance, and even got Mark Shuttleworth interested:
https://blog.majid.info/supply-chain-vetting/
This is not solving quite the same problem, but it’s a viable solution to the maintainer burnout crisis, and that’s great.
This all falls kinda flat if I don't want to be paid for it. Or at least not in the way most projects are being run.
But it's ok, I'll just move back to my quiet burnt out corner.
The otherwise coherent take is somewhat ruined when it states that mirrors, implying registries in general, are trivial to run. They are very much not. At least when you are serving not just friends and neighbors. And it gets expensive pretty fast, costwise.