I've been thinking about this for a while now, and I'm thinking that the ecosystem of crates in Rust is very fragile. At any moment, an important crate can be abandoned by its creator, and block all the projects on which they depend. (ex: serde_yaml)
We end up with several scenarios :
Deprecated crate
Fork and name change, which also means :
maintenance by unknown persons
security risk
quality degradation
Very slow development, if the owner decides one day to validate pull requests
I think the Rust universe needs foundations dedicated to managing popular crates, like Java's Apache Software Foundation.
In this case, if a crate maintainer wants to abandon his project, he can cede governance to this foundation so that it can continue its work.
Every developer has a life, has constraints, doesn't live forever, and above all it's difficult to work on a project without remuneration.
I think it's time to act, because the crates are like a house of cards: as soon as the base cards fall, everything collapses.
Can the Rust Foundation take care of this? Or do we need to create a separate foundation for this task?
I think it's time to act, because the crates are like a house of cards: as soon as the base cards fall, everything collapses.
Only in so much as the world chooses to rely on random people's hobby projects with no financial backing in the first place. You get what you pay for.
And you cannot force crate owners to hand over their crates. So even if such a foundation existed it would only lessen the problem in so far as owners are actually willing and capable to participate in the scheme. If someone gets hit by a bus they won't be handing over their crates either.
In the end you will still need a way to coordinate the fork-and-migrate approach anyway. So imo it would be better to make it easier to follow that approach.
E.g. ways to advertise forks (X promises to be a drop-in-replacement for Y), a way to diff between old and new crates and things like that.
And I think it would be nicer if we could pay and support the original maintainers of important crates and keep them happy rather than waiting for them to burn out and only then do something about it.
(Which isn't to say it's not worth talking about, etc.)
From my outside vantage, it doesn't really seem like a Rust Foundation concern to me in the general case. (There may be niche cases where the teams take a project under the rust org because it's a compiler dep or such.)
Rust foundation is an associate member of OpenSSF, the same as python software foundation.
I believe a previous effort of this sort of thing was the rust nursery.
I'd like to see something more substantial with backing, strategy, vision, commitment and an announcement from rust foundation. It would be an exciting project to work on, real legacy building kind of stuff
It's not something to rush into though, you'd want to think it through and avoid burning out existing maintainers. And the community needs to want it and feel part of it, that kind of buy-in doesn't happen overnight, it takes time to build trust and demonstrate value.
It's also worth noting that it took a long time for the ASF to become the major backer of Java projects. The ASF formed to be the financial backer of the Apache web server (which is where it gets its name from), and it became the place for Java projects to find long-term maintenance with the rise of Java Servlets.
In that respect, the Rust Foundation is already in place, and I hope that if a maintainer of a key crate approached the Foundation and said "this is maintainable, but I cannot afford the time to maintain it", they'd work with the maintainer to resolve the problems - e.g. by paying the current maintainer so that they can afford the time to maintain it.
I feel obligated to point out that the serde_yaml deprecation did not block anything. The crate is still just as usable as it was the day before its deprecation, and it will remain just as usable unless and until someone discovers a security vulnerability in it, at which point we're likely to see one or more forks popping up to fix the vulnerability.
This then gets you into messy questions; what if the original author is maintaining them, but not to the satisfaction of some users? What if they've turned maintenance over to someone else, and now people are unhappy - do we snatch the maintainership away (see also Jia Tan being given maintenance of xz)?
Having somewhere that the author can hand the crate over to and say "I'm done with this, but people depend on it, so please keep them happy" is one thing; forcing people out of crates they're maintaining because "the community" is unhappy with the amount of free labour they get from the maintainer is another.
I mentioned the ASF as being the only way that I could see "keep these popular crates maintained even if the original developer leaves" working, not that I thought it was particularly plausible to happen again nowadays now things like GitHub cover much of the same purpose.
What if some company with a big webapplication in C# ASP.NET and 50 customers all over the country decides to switch to Rust because of its incredible performance and needs some crates because they are really good.
How to handle this? Is it even an option? How does this work in the world? I don't know.
I maintained a long time ago an old Delphi application. And only if I had all source-code, which I could easily recompile, I used 3d party (free) libraries. Or otherwise bought ones. And even then: the one guy who maintained some report lib died. Then the game was over.
This would likely be legally dubious at best, as well, due to the copyrights¹ that the author automatically has. Not to mention that that could easily cross the borders of countries, which would just complicate matters further.
¹This is relevant because AFAIK with FOSS software, owning the copyrights, as well as any trademarks that might have been registered is, legally speaking at least, as close as one can come to owning a project. But if the author(s) own the copyrights of a project, on what legal basis could some nonprofit even take ownership away?
Exactly the same as in C# and every other language, I would assume? You use whatever is public, based on the history of maintenance, and fork if there's a change or fix you need, and (if you can convince the PM) send a PR back up if it's maintained and that makes sense, or publish your fork if not.
I've worked at companies with exactly this class of problem (depending on open source code that we couldn't easily replace). We dealt with it in two ways:
Pay someone (sometimes even the original maintainer) to maintain it for us, on a contract basis. Because we had a contract, with actual money changing hands, we now have something we can lean upon to get the maintainer to do something we need - this is, in many ways, better than the state of play with (say) Windows Server, since we could stop paying if our maintainer didn't bother.
Bring maintenance in-house; we'd do it ourselves, and (sometimes) publish our fixes.
There are a lot of current problems that I perceive with crates.io as 4-6 out of 10 competent rust programmer. As a long time on and off programmer looking into it can be a bit intimidating looking at the site deciding what is really useful and good. Sure there are articles out there that discuss it. What is junk, what is not, what is maintained and what is posted more as a pet project.
I am sure there is a lot more.
However this is going to take some volunteers maybe including myself. Thick skins required.
Informal committee.
Beginning of organizational rust process which the Rust organization has
Beginning of requirements
How come? Cargo devs for example constantly consider how package managers like npm and pip are designed when they are discussing possible new features.
Not familiar with C++, what exactly is C++ burst? Couldn't find a satisfying page when I searched the web
Looks like a good comparison to me. Rust packaging is inspired by the likes of NPM and others and does its best to incorporate the best features. Meanwhile as a C++ user (will not since discovering Rust four years ago) I have never heard of Burst.
Did you perhaps mean "Boost"? That is certainly not comparable to Rust's crates or crates.io.
My apologies. I meant Boost. It was late when I responded.
In many ways I don’t want to compare to C++ but others have with the strength of the rust library set being a question.
In the mid term I’m am trying to understand how crates.io is managed as I am lacking that knowledge.
As an aside I was scrolling through data structures on the site and came across either. Tried to look through it and understand the use of it. Number one question, what problem are they trying to solve?
There are a lot of crates available that are useful but sorely lacking in documentation and examples.
