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:
