What-if: crates.io paid subscription for commercial use

community
1

In @nikomatsakis' 2020 blog post, he calls for a shift in focus "from adoption to investment.

(...) for Rust to really thrive, we need to see more people paid for their work on Rust teams.

I wanna accept that call-to-action and propose one such opportunity for investment.

tl;dr: The online service Crates.io could start charging commercial users a nominal fee, collected purely through opt-in payment; no paywalls or licensing changes.

How crates.io could turn a profit without hurtin' anybody

What I'm about to propose is in large part inspired by the talk called "Money, Money, Money - Writing software, in a rich (wo)man's world" by Russell Keith-Magee @freakboy3742.

Free software advocates talk about two types of "Free": Free as in freedom, and Free as in beer. While Free (as in freedom) software is unquestionably better for users and developers alike, Free (as in beer) software doesn't pay the bills.

Talk to any prominent open source developer, and amongst the success stories, you'll also hear some consistent troubles - that they've got great ideas and grand plans, but no time to execute; that they're about to burn out due to the pressues of maintaining their project; or that they've had yet another mailing list discussion with someone who doesn't understand they're a volunteer. All of these problems stem from a fundamental disconnect: the discrepancy between the clear demand for a software product, and the ability to convert that demand into time needed to service that demand - and that means money.

The talk holds up incredibly well, and I recommend any Rust enthusiast interested in the sustainability of programming languages & infrastructure to watch it.

In this topic I wanna continue jamming on the idea that is presented towards the end of the talk at 23:07, namely how one could turn a profit on package management infrastructure without making things awkward (i.e. without corrupt incentives and such).

Imagining what crates.io pricing could look like

Start :thought_balloon:

There's a top-level /pricing page to crates.io. It describes some very simple payment terms of this online service:

  • :free: Non-commercial user? Use Crates for free!
    Price: $0/month

  • :dollar: Commercial user? Pay for developer seats.
    Price: $150/month for every developer who spends 60 hours or more per month on Rust development.

End :thought_balloon:

The goal would be to resemble the pricing conventions of a SAAS product, which companies are very used to and can quite easily get to expense.

Paying for the developer seats would be self-enforced only. Companies that can't afford to pay $150/month (which is of course subject to change) per active Rust developers could simply opt not to pay. But in the best case scenario, non-payers would still get in touch with the Crates/Rust team to discuss what a paid subscription that'd work for them might look like.

Paying could be further incentivized by letting companies opt-in to be shown on a "Paying Subscribers" list; essentially serving the same function as a list of sponsors.

Professional Rust developers could also help drive adoption by favoring companies that pay the "Crates Subscription".

The Numbers

Just 40 companies paying for one developer seat each would amount to a whole developer’s salary (most places in the world): $6000/month.

Personally I think the price should probably be set higher, but it'd be best to start on the lower end and move carefully upwards through discussion with the paying subscribers.

I welcome thoughts & feedback from anyone, though I'm especially eager to hear from the would-be commercial users.

1 Like
2

The core flaw I see with that business plan is that if I were to start a business atm and use Rust for it, I'd want to host my own proprietary software.

Since custom registries are already a thing IIRC, why would a commercial entity pay for a service like that instead of self-hosting?

TL;DR: Commercially competing with something that is free-as-in-beer is always tricky and ultimately a losing battle.

2 Likes
3

There's an inherent problem with paying for one thing (development of Rust) by charging for a different thing (crates.io) because those two groups don't necessarily align. If crates.io is going to start charging it should be a nominal fee to pay for the infrastructure and development of crates.io itself, and no more. People who have already contributed to crates.io (including by publishing crates) have done so under the expectation that their contributions will freely benefit everyone, so paying for something else by piggybacking off their work is unsettling.

There's a second problem which is that one of the main values of crates.io is as a central repository for crates. Charging significant fees for companies to use it seems like a very effective way to split the ecosystem and devalue the very resource you're charging for.

Finally, if the charge is optional then why would anyone pay? Is the goal to shame companies who don't pay? Or are companies who don't pay breaking the legal terms of use, and you're just expecting companies which can't afford it to be OK with breaking those terms?

5 Likes
4

Yeah. It'd probably be both better and more likely to succeed to just tell companies that crates.io is looking for sponsors, who would get a badge (ie. tasteful locally-hosted static-image ad) in the site template for as long as they remain sponsors.

9 Likes
5

Getting some funding for Rust is a good idea. Having a product for corporations is a relatively easy way of getting money from them (e.g. it's easier for employees to request purchase of a tool than to make the company donate money).

But doing this for just regular crates on crates-io may have negative side effects. Making it harder for companies to publish commercial crates will mean some crates won't be published there. They either won't be published at all, or will be dumped on GitHub. That's a loss for crates-io users.

npm Inc. sells private packages. That's something which doesn't impede growth of public packages.

7 Likes
6

Namespacing always comes up in discussions about squatting. It has some techincal issues, but ignoring these for a second, making namespacing as a paid-for feature can actually solve a few problems:

  • Companies could pay to reserve their brand name and make their crates "official".

  • The registration fee could pay for costs of moderating registrations, so crates-io could literally afford to have more restrictive policies about them.

  • If namespaces were a paid feature, then there would be financial disincentive for squatting, or at least squatting would support Rust development.

5 Likes
7

Creates a "us vs them" system. Administration would undoubtedly syphon a big chunk. Payers either would control direction of development or object and leave if irrelevant to them.

8

But this is de facto a licensing change. Even if you don't enforce the terms, legally they still apply.
Either that or this information on the pricing page is a lie and does not reflect the actual licensing terms.

In other words, you are creating an insecure/ambiguous legal situation for all commercial users that don't pay the fee which might hurt the commercial adoption of Rust in the long run.

3 Likes
9

A service that I could see businesses pay for is private crates that would participate in crater runs.

11 Likes
10

That seems to be the way it goes with node.js and it's npm package manager. The npm is registry is run by a private corporation which also has corporate sales: npm | Products

I have no idea if that is a good model for Rust.

Interestingly NPM INC is adopting Rust for it's services :slight_smile:

1 Like
11

I like the idea but not sure it'd work... But I really like the idea.

12

This has all the hallmarks of a winner, because it's a service with inherent value (repository hosting) that has an added feature competitors would inherently find difficult or impossible to offer.

6 Likes
13

This idea is, without having any plans for crate authors also receiving money, absolute trash. Let me make a funny (and sad) analogy with regards how Steam might work, if it operated like that.

Publisher: Hello Steam, I want to sell my $60.- game in your shop. What do you say?
Steam: Sorry, but you cannot choose the price yourself. We'll determine the value of your game dynamically though a math formula. We estimate it to be worth around $40. Our customers pay a monthly subscription and the worth of your game is: total monthly subscription income * monthly number of your games downloaded / monthly number of all games downloaded
Publisher: OK, that's fair, I guess. Let's just get to the more important point, then. If you estimate the game to be worth $40, how much would we get from that?
Steam: HAHAHAHAHAAHAHAHA
Publisher: What's so funny about that? ...
Steam: You seriously expect us to give you money for your work?
Publisher: Yes, of course. We put a lot of work into that game!
Steam: That's hilarious! You should be glad, that we even consider selling your game in our shop. Consider it a privilege! Where else would you sell your games at? We're the only ones doing that.

Publisher goes away speechless

Epic sees a big opportunity to make money and opens their own online game shop, where publishers get a better share of the sales (anything is more than nothing)

Almost all publishers start selling their games exclusively in the Epic game store

I hope you see the correlation between crate authors and game publishers, now. No crate author in their right mind would be okay with crates.io being a profit-oriented site, while they don't see anything of that money. The site wouldn't even exist, if there was no one publishing crates, i.e. it doesn't make sense for crate authors not to get a share of the money.

However, let me be clear about one important aspect of what I wrote: This is only true, if crates.io would be profit-oriented. If it was non-profit, this argument wouldn't hold, for obvious reasons. You would never see any companies, that would be willing to sell their crates, too, though. It'd be like Steam with only free-to-play games (without microtransactions).

If you want to make a profit, you must share it with the crate authors, regardless of how that may look like, because no crates = no money.

4 Likes
14

In opinion it is good idea, following topic I created related to this: Pro vs Open source and declaration of crates/libraries used

Of course, specific details can be worked like pricing and licensing issues, but for start it is very good idea.

1 Like
15

If it is a good idea then there is no problem.

If it is a good idea there will be software houses all around the world busy, as we speak, creating closed source, proprietary, libraries for Rust which they hope to sell to us under whatever licence terms they have in mind.

When this flood of proprietary Rust libraries hits the market then it might be time to think about how to integrate their offerings into the cargo/crates system. Perhaps one of the big fish, or a consortium, will build a "crate store" where their produce is offered for sale and download.

16

I don't see an issue for adding support for paid license option with a fee lets say 5% of sale price. If it is available, it will start to see growth and would become another source of revenue for Rust.

Chances are it may improve the Rust ecosystem.

  • Some Crates may see better support because developers can spend more time on it as this can be their source of income.
  • Increased development of Crates that makes more sense to be developed by commercial software houses. There might be projects which may not have much traction with open source developers, but better suited for commercial developers to work on it and make them available for sale.
1 Like
17

On a purely personal level, my biggest concern surrounding paid offerings is making sure that it's easy to filter by license and, preferrably, in a way that would make it easy for lib.rs to replicate so I can add a "search only OSI-compliant open-source" quick-search to my address bar.

(I much prefer lib.rs over the crates.io frontend for its UI design, color scheme, and reduced dependence on JavaScript.)

Forget proprietary packages. I already maintain my own private lists of useful dependencies so I can badge copyleft-licensed stuff to make it easy to skim through just the MIT/BSD/Apache-licensed stuff if copyleft is incompatible with a project's requirements. As far as paid dependencies go, I'm definitely not the target demographic just on "psychological burden of license compliance" grounds alone.

1 Like
18

$150/month for every developer its a lot from my point of view and small company may not want spend that amount. Rust is for me not big institution ready. I am working for government and its already difficult to move out of Java. Personally I move out from Scala due to it's ambiguity from open source part and products from Lightbend.
Rust is open source and it create a good ecosystem if commercial side need infrastructure and tools just do it and we will see.

19

$150 dollars a month would kill the whole idea of using Rust around here stone dead. A penniless new company on a speculative venture.

Also it would worry me that the money is distributed fairly. Widely used crates would get a large proportion of the reward. Even if others have put the same effort into their thing which is equally valuable but to a lesser user base.

2 Likes
20

Plus, it's at odds with point six of the open source definition (No Discrimination Against Fields of Endeavor) which means that the idea just leaves a bad taste in my mouth, period.

(A philosophical and practical concern which also pops up in the Debian Free Software Guidelines (No discrimination against fields of endeavor, like commercial use.) and, in less overt terms, as part of Stallman's Four Software Freedoms. The DFSG are my favourite because they go into the most detail and include a set of thought experiments for testing compatibility. Sure, those are about software licenses, but they embody a philosophical viewpoint that can be generalized, and which I agree with.)

Offering a service like paid hosting of private packages doesn't have that problem, because private vs. public hosting is sufficiently orthogonal to "field of endeavour".

While I haven't yet written something I consider ready to publish to crates.io, If such a discriminatory policy were to go into effect, I never would. I just wouldn't feel right in propping up such a system.

1 Like