The problem with distributing money by download count (alone) is, that it encourages people to release micro crates with a lot of dependencies on other micro-crates made by themselves in order to get a bigger share of the available money.
If dynamic pricing would be the goal, it'd need some sort of crate complexity analysis to determine the base value of a crate. For dependencies, it'd probably be necessary to analyze the exact dependencies on functions/methods, instead of the whole package, otherwise you could exploit the analysis tool by creating huge crates with lots of utility functions, but dependent crates only requiring a tiny subset of the crates features.
Even then, it's impossible to reliably determine the worth of a crate without a human inspecting the code (algorithms are a fitting example where code size does not equal worth). At that point, I doubt this is worth the cost and it's easier to just let crate owners set their own price. Users will have to subscribe to specific crates, instead of the whole page.
Micro crates would certainly be more attractive to publish with fixed prices, because the user may not see the worth of subscribing to packages with a lot of utility and a horrendous price, while only using, e.g. 10% of what the crate offers.
To be honest, I find this topic to be extremely difficult and if this idea is ever seriously considered, bringing experienced business people into this discussion would be a necessity.
Free market system, imo, would be fine. I mean it would be up to the authors/publishers to make their crate paid or free. Free should be as they are now and paid crates obviously should have a fee (fee charged to seller either on sale or fixed fee which can be worked out which is better).
Then it would be up to the suppliers (crate authors/publishers) and buyers (users) how much a crate is worth. I don't see it as something very complicated.
I think: most crates will probably stay free, some with dual licences, and few paid only.
It is highly unlikely we will be adding any sort of payment system to crates.io. For one, that would add a barrier for people without a credit card, which we don't want to do. For another, there is no legal entity with a bank account currently exists to accept the funds, and creating one is nontrivial.
Anyone wanting to build a crate registry that does charge money is free to do so.
There's another reason I'd be very wary of even offering a "pay to play" option: It could ruin the culture of the site going forward.
As observed in Uri Gneezy and Aldo Rustichini's study, documented in their paper A Fine Is A Price (summarized in this Toronto Star article and at 6:35 in Clay Shirky's TED Talk, How Cognitive Surplus Will Change The World), when you add money to the equation, people tend to see payment as a replacement for the good behaviours they were "paying with" before and, because they see it that way, the effect remains after the monetary option ends because you've taught them that their good behaviour isn't worth as much to you as they thought.
Yeah. The concept of micropayments ran into similar trouble with the whole "fixed mental cost per transaction" problem, but this is possibly worse because of the mental cost of keeping track of license compliance as opposed to just whether or not to pay for a product where licensing enforces rules analogous to a physical object.
There's an excellent article I read back around 2000 about it in the context of micropayments. Unfortunately, I forget what name I bookmarked it under and it now only exists in the Wayback Machine's archive of the O'Reilly site so Google can't pull it up.
Yeah, I had not considered the micro-payments angle. But I guess it amounts to the same thing.
Typically if someone works for a company and they need something to get their job done, then if there is any payment involved at all there is a huge problem. Could be a paper clip, a PC, a software license, whatever. They have to get approval to get that thing. The purchase has to be approved by someone. The order has to be made. A bookkeeper somewhere will be counting every cent in and out of the company. The bank takes its cut of the transaction.
The cost of all this is huge.
That's before we even think about the company lawyers pouring over the details of all the licences you want to use in a product you will ship to customers.
Half a decade later, there seems to be a lot more openness towards clearer delineations between commercial and non-commercial uses of public-good infrastructures now:
Beyond package registries, open source projects also rely on essential systems for building, testing, analyzing, deploying, and distributing software. These also include content delivery networks (CDNs) that offer global reach and performance at scale, along with donated (usually cloud) computing power and storage to support them.
And yet, for all their importance, most of these systems operate under a dangerously fragile premise: They are often maintained, operated, and funded in ways that rely on goodwill, rather than mechanisms that align responsibility with usage.
Despite serving billions (perhaps even trillions) of downloads each month (largely driven by commercial-scale consumption), many of these services are funded by a small group of benefactors. Sometimes they are supported by commercial vendors, such as Sonatype (Maven Central), GitHub (npm) or Microsoft (NuGet). At other times, they are supported by nonprofit foundations that rely on grants, donations, and sponsorships to cover their maintenance, operation, and staffing.
Regardless of the operating model, the pattern remains the same: a small number of organizations absorb the majority of infrastructure costs, while the overwhelming majority of large-scale users, including commercial entities that generate demand and extracteconomic value, consume these services without contributing to their sustainability
Since this discussion started there’s been another great talk on the subject of sustaining a programming language by the founder of Elm-lang:
Another year has passed, and the idea is still gaining traction.
Last year I wrote about the power differentials of open source.
Re-defining our boundaries
The reigning winners of open source are the megacorporations, and who can blame them. We seem to have collectively agreed (though I would argue by manufactured consent) that drawing clear boundaries around our digital software commons is the one thing we cannot do.
There’s never enough interest in grappling with this looming issue until the system breaks enough that people are being hurt in the form of critical system failure and vast personal expenses of both the psychological and financial kind.
Modern infrastructure initiatives like Vite+ are daring to make source-available code and I think this is a Very Good Thing. It facilitates a rethinking of the social as well as financial contract between open source maintainers and the corporations that to-date have been extracting vastly more value out than they're putting back in.
The top 10 biggest programming languages in the world are collectively responsible for trillions of dollars in generated value. How much of that value is cycling back into the maintenance of these languages and their ecosystems? 0.01% maybe, if even that?
Is it really that crazy to imagine a community-governed and institution-owned package management stack that's licensed such that corporations have to pay their fair share, to the tune of some tens of millions of dollar per year in revenue? Keep in mind that non-profits are welcome to make lots of revenue, it's the excess profits that's a probem.
The Rust-lang package utility crates.io and all of its accompanying infrastructure is licensed as permissively as possible with MIT and Apache v2. Why? Is anyone forking and remixing crates.io for personal use?
Package managers are centrally managed utilities by necessity; we just need the one (on average). No one is pulling in the crates.io package manager itself as a code dependency in their project, so the licensing of that package management code almost exlusively pertains to the usage of crates.io as a package management product, used by individuals and corporations alike.
Alike, but not equally. As the OpenSSF article above makes clear:
Commercial-scale use without commercial-scale support is unsustainable.
What the article doesn't get into is exactly how the corporations will be charged for services rendered. Presumably the utility endpoints themselves like crates.io will receive some much needed changes their Terms of Service as pertaining to corporations.
That'll be a great start, but I believe something more akin to the commercial tempering of Vite+ (specific license TBA) is necessary as an additional protection, otherwise the capital-holders will keep re-drawing the boundaries in their favor. [update: VoidZero/Vite+ got acquired by Cloudflare, so no more non-commercial license boundary.]
They did so because their state-sponsored funding was contingent on compromising their community's commitment to diversity. This is the kind of decision OSS orgs are faced with when they have to ask for money instead of being paid for services rendered. I wonder how many orgs have quietly taken this deal, insidiously eroding their culture of openness and cultural diversity in the process.
This week Laurie Voss dedicated a whole article to the notion of paid registries as a lever for OSS funding.
The registries should charge companies, and pay maintainers
So here's the proposal. There are three parts, none of them new; what's new is putting them in the same place.
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. Docker's rule is the right rule: individuals, small teams, students and open source projects pay nothing and notice nothing. A company above some size gets a subscription, priced the way a JFrog or Docker subscription is priced today, which is to say at a level procurement signs without scheduling a meeting. For most of these companies it isn't even a new cost, because they're already paying it; the invoice just gets a new line.
Second, a fixed slice of that revenue is a royalty, and it goes to the packages. Not to the registry, not to a foundation, not to a grants committee with an application form. Pro rata, to every package that shows up in the paying customer's dependency trees, weighted by how many paying customers depend on it, automatically, every month, with no ceremony and no thank-you email, because the whole point is that nobody has to do anything for the money to move. My 2022 notes have a line about this that I'll leave unedited: "The money has to go in one end and out the other. You don't have to use crypto to do this, that would be bad, just use a database." The payout half is not hard. thanks.dev does pro rata distribution over dependency trees today, and Flossbank did it in 2020. Nobody's ever connected it to the collection half.
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 billing side is finite: a few thousand large companies, most of whom are already customers of somebody in the supply chain. The two hardest problems in every previous attempt, finding the payers and finding the payees, are already solved, and they're solved by the same database.
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. GitHub owns both npm and GitHub Sponsors, has every piece of this in one building, and could turn it on for npm's enterprise customers this quarter. JFrog and Sonatype already bill companies for supply and could add the line item tomorrow. I ran npm for five years and I promise you the plumbing is not the hard part.
If crates.io had a paid subscription, I may have never started using it. Being "free" (beer) and "free" (liberty) are both very important to "me". In addition to the safety, (my c programs would often bork my computer after running for a while.) I became interested in rust because it was free.
I predictl having a "paid" for some and "free" for others would end up morphing into the "paid" getting more or better stuff, and the "free" would get what was less valuable or end up going through inconvenient hoops to get the stuff the "paid" gets.
When I uploaded my libraries to crates.io I put them under open source licenses, which allow any usage,
I expected people to be allowed to use my library however they want, including commercially, without any restrictions.
If crates.io charged money for using my libraries, even if only commercial, then they broke my trust and I would not want them to host my libraries anymore, and I would not want to use it.
This suggestion if implemented could genuinely destroy rust, or at least its ecosystem.
Also how does this work with licenses that disallow additionally restrictions (e.g. the GNU GPL)?
Nothing is created for free. All Linux maintainers are well paid developers. So who don't Rust? When the site becomes paid, maybe I will start using it. Who knows?
Copyleft licenses like the GPL and the CC-BY-SA don't prevent you from charging for things. They just make it difficult to make a business out of doing so by enshrining in law the right for every one of your customers to become a no-charge competitor to you.
(Hence why, historically, attempts to charge for binary builds of copylefted things like X-Chat have tended to prompt people to start up websites offering competing free builds out of spite.)
TBH, I think that crates.io should at least add friction to any crate without an OSI-approved license. At the very least, I think you should have to click-through a big warning about it before seeing it on the website -- maybe even when cargo adding it. If I have to worry about whether my credit card means I'm participating in interest-bearing lending to use something, I just don't want to see it in the first place.
(That could also lead further to other things like requiring payment for hosting of proprietary crates or similar.)
As an author of relatively large software projects I wouldn't mind about such change even if I don't have commercial intentions. For example, Steam charges $100 one-time fee per publishing. This is at least creates a minimal entry barrier while still being an affordable price for majority.
Furthermore, I think such marketplace probably should be separated from the main crates-io repository. I also not interested of my projects to be listed alongside with the OSI-licensed works.
The lack of such service is one of the reasons why I don't publish my Rust works anymore.
From my experience of "not software corporates"[1] this would be real killer to adoption.
If a team needs to make a budget request for "real money" before beginning to use rust, then they will have no chance to start.
Nobody wants to go through the formal rigmarole of trying to explain a business case showing reduced cloud bills & lower "risk of technical stuff which finance, compliance and C-Level think are just devs being unprofessional" outweighing initial licencing, increased "skills & change risk", etc to get sign off for a few-hundred/thousand dollars line item from a company which also needs a formal legal, cloud & risk assessment before they can be onboarded into the suppliers register and then struggle with working out how to get a purchase order and invoice...
Making a later case, to obtain "time is money" investment in porting legacy code to a language already in use in these few cases and shown to be good is a much better prospect[2].
Now that rust is a tier-1 language at MS we will hopefully, , see much more major "sponsorship" in all its forms from the kinds of companies that support linux, C/C++, etc...
Code in Java because it's easy to hire devs, "nobody ever got fired for buying IBM", etc... ↩︎
but doesn't directly generate income for rust-lang ↩︎
, see much more major "sponsorship" in all its forms from the kinds of companies that support linux, C/C++, etc...