Post

This is an interesting premise. Potentially the hard part might be in the checks and balances around the fraud aspect you mention. Potentially setting a bar for payout, for example tie it in with package security best practices, a min package age, min number of verified dependents.

I’ve jokingly said this to many people, much of the OSS I maintain is akin to a great Dev product and in any other time it would probably be a very profitable company. Even 0.001 per download would make a big revenue for a lot of these

The sad part is that npm won’t evolve to do this and the two sided network effect of a new registry won’t be feasible as long as they exist.

Coming from someone who has built a lot of products aimed at developers and eventually never published anything due to getting discouraged by AI. Most of my effort goes to OSS anyway and realising the profits coming forth from OSS comsumer is disheartening

I love a blog post where I can't find anything I disagree with. Nice job. That said I have questions: 1. Have you run any numbers to determine how viable this would be and how much it would actually impact maintainers'/contributors' income as opposed to those other streams?

2. What's the biggest incentive registries have for turning on this cash pipe?

3. Are the payout distributions appropriate in any existing "second half of your solution"? In a project with many contributors, is a maintainer worth more than a contributor? What about projects with much more complex governance?

They also get a cut, albeit hopefully a small one.

Only that the ballpark is "billions" as opposed to the ~100m currently on offer. It's at least an order of magnitude more money, but depends enormously how they price it.

"how they price it" can also impact the industry's choice of default (companies, like developers, do have the ability to ragequit and change vendors), so this is a delicate game to play. 🤔

Analysis is spot on! 🎯 But the exact choke-point to meter, and who does it at what price point, will remain a tight balancing act. I’m still amazed Docker managed to pull it off. And what the companies pay for (security, private packages, etc) will remain something else than what gets funded (code).

Open source maintenance fee: add a maintenance fee for corporations to pay for packages. opensourcemaintenancefee.org use an Open Source Project’s binary releases as part of revenue generating activities and meet the minimum annual revenue threshold (typically US$10,000) must pay the Fee.

How do you enforce this?

You don't do it in code. You rely on the legal framework. Source is free. Binaries/packages are licensed separately and require a maintenance fee. Companies are used to paying for inputs. They have whole departments dedicated to paying invoices and conforming to license agreements.

This looks like it would be something GitHub would implement and not a third party by way of EULA scanning. That doesn't work for the broader open source / free software ecosystem.

Seems like a great idea. I wonder if payout could be contingent on some added promises from the packages - signed publishing etc. That way companies are not just paying for access but also for some baseline security guarantees. Easier pill to swallow perhaps

Have you considered what perverse incentives this might create? One thing that comes to mind is devs would choose not to archive/deprecate a package, since that would reduce their income. "Don't use this package anymore, it's [bad/broken/whatever]" would not happen anymore

This already happens today, which isnt great in itself, but not *worse*

I suppose, but it would also foster competition for better forks and alternatives. Wouldn't hurt if the registry listed similar dependencies to avoid abandoned defaults.

It works for game modding registries like modrinth.com/legal/cmp-info. It's just that the revenue comes from ads and is split 75% for creators and 25% for the company.

Also interesting to point out, the fact that the default registry for games was curseforge who became greedy/stale was replaced by an open-source version modrinth. npmx could for example implement a reward program

This is an epic crack at the argument, well done. I think modeling a real example is next to making this How does a metering event modulate value to a package? Tons of variables here each with a chance to create a weird incentive And then from package to real hands, how might money be split? Etc.

The Spotify economy is the perfect citation, especially because it touches on AI, complicated rights per song, the motives of recommendation engines, metadata integrity, lookalikes, etc But also are we trying to reward Shakira or new artists

I appreciate you writing all of this. Especially the diagnosis at the beginning 🎯 I am lightly skeptical of the medicine you propose tho. Just on the practicality of “for profit company” being handwavy or reminiscent of unlikable ASCAP chasing down bars & restaurants for their background music.

It's the same with most free for personal use licenses? Corps could theoretically use a personal license for enterprise use. But they pay because they don't want to expose themselves to (much costlier) legal risk

I guess my reading of the piece is: complex/tiered licenses are not successful. Maybe software+license != service+tos ... but they seem analogous to me. I guess the "find out" is whether a tiered TOS would lead to package manager competition, where "we give it away...profit" is re-attempted.