The number of developers using the Rust programming language has tripled in 24 months to 2.2 million. With an open source software security plan presented to the White House in May and backed by some of industry's leading CISOs explicitly urging industry to begin moving from C and C++ to memory-safe languages like Rust, the wind is clearly in the "Rustacean" community’s sails. Enterprise uptake is also growing: Rust is used in production by Canonical, Chef, Cloudflare, Deliveroo and many others -- plumbing just the shallow end of the alphabet.
Languages, like C and C++ -- born in 1972 and 1983 respectively -- are ubiquitous as the building blocks of much modern software, but also prone to memory safety issues that cause severe security vulnerabilities downstream. Rust, by contrast, handles memory management and other security-sensitive tasks safely by default. (In Rust, the compiler plays a gatekeeper role by refusing to compile code with such bugs, including concurrency bugs. Those interested in more detail can explore how Rust ensures memory safety and handles concurrent programming, where different parts of a programme execute independently, in "The Rust Programming Language").
This is not some esoteric concern of developers keen to write clean code for the sake of aesthetics. Analysis last month by Google's Project Zero threat hunting team found that 67% of the 58 zero days it spotted being exploited in the wild in 2021 were memory corruption vulnerabilities. Memory safety issues cause bad cybersecurity. It is not hard to find further examples of this. About 70% of all CVEs at Microsoft are memory safety issues. Two-thirds of Linux kernel vulnerabilities come from memory safety issues; the list goes on.
Rust, crudely, is not prone to these issues and "has formed a very strong community of developers who care about performance, memory safety, and security" as SlashData's May survey of 20,000 developers put it.
With great popularity, comes great responsibility…
Rust, born in 2006 as a personal side project of Graydon Hoare at Mozilla and run as an open source project with an autonomous collective of maintainers largely working as volunteers, has operated autonomously since the launch of Rust 1.0 in 2015 -- a release that had 53 contributors, dominated by the efforts of Brian Anderson and Patrick Walton alongside Hoare (who explained his decision to step away from what had amounted to a technical lead role at Rust in 2013 here.)
It only gained a discrete formal organisation to own its governance in 2020 with the establishment of the Rust Foundation – a move that came in the wake of sweeping job cuts at primary sponsor the Mozilla Foundation that had raised serious concerns among many in the community about Rust’s future – and the language’s success has also put a spotlight on the challenges of supporting an often stretched community of maintainers. (Rust has had 6621 individuals contributors in total; with ~300 people on average contributing to most recent releases.)
The Rust Foundation itself is far from large. A non-profit with a team of four, it is led by CEO Dr Rebecca Rumbul, an experienced NGO director who has also served as a council member at the Advertising Standards Authority, as a Trustee at the Hansard Society and as the UK representative claimant at the Privacy Collective.
She was appointed in November 2021 and describes her job to The Stack as to “build a team that can do, quite frankly, all the boring stuff, all of the legal, accounting, finance, trademarking, licencing, things that people do not want to volunteer their Sunday afternoon for, and to provide as much infrastructure and support as possible so that [the maintainer community] can [avoid] worrying too much about project management.”
In a blog earlier this year she spelled out quite how much recent work this has entailed, from ensuring Rust is trademarked outside of the US through to the legal, financial and administrative work to create, administer and organise programmes of support for the community funded by the Rust Foundation’s sponsors.
“There remains a huge amount of work we need to do on legal, security and compliance issues” she noted in that blog and in conversation with The Stack adds: “Rust was spun out of Mozilla which wasn’t really planning on stewarding it in the long term. So we’ve had to do basic things like trademarking, through to super technical, very niche legal things; we provide infrastructure for the project to happen, we are therefore ultimately responsible for observing the law where the project is taking place. We're [also] looking at where access has historically been available to people, for instance, and trying to shore up the processes that we have in place, both inside the foundation, and in partnership with the project community. That might include even small things like [making sure that] there’s a process in place for when people exit one of the working groups; that there's proper infrastructure support around the clock; that we're aware of our vulnerabilities and if someone's on holiday, we have the right people in place to do that [push fixes] quickly; or stewarding things like our cloud compute programme, which is going to be providing more free compute power for maintainers, etc.”
See also: The Top 10 Apache projects by activity in 2021
That’s on top of managing some complex relationships as well. Minutes from April's Rust Foundation meeting note, for example, that it had "received feedback from other Silver [sponsor] member companies that there was a perception that certain contributors within the Rust community were acting to influence Rust development on behalf of their employers, the larger companies represented on the Foundation’s board".
Such armchair critics could, of course, simply pony up to support more maintainers themselves and few we spoke with recognised this complaint; one sponsor even arguing that that it was too hard for member companies to influence Rust's development; a fiercely independent and faintly anarchic open source community rendered it nigh impossible they suggested, somewhat forlornly. The growing Rust maintainer community meanwhile continues to power forwards with developing Rust – the language, library, and compiler teams each for example recently publishing their own roadmap; the Rust language team targeting 2024, the compiler team 2022, and the library team not specifying a specific timeline. (Dip into the library roadmap for a sense of the complex challenges involved. One example: “There are also cases when adding a new API can subtly break existing Rust code, even when not changing any existing API. This can happen, for example, when a type gets a new method that was already available through a popular trait, such as itertools::Itertools or num::Integer. Adding a method to the standard library can result in an existing method call resolving differently, potentially breaking code. This is usually considered 'acceptable' breakage, but as Rust usage grows, the impact of such breakage increases, often making such breakage unacceptable in practice” the roadmap emphasises.)
As with many open source projects, many key contributors are volunteers and despite the Rust Foundation boasting "platinum" sponsors like Google, Huawei, Meta, Microsoft and Mozilla, Big Tech appears yet to have allocated really Big Money through the foundation to supporting maintainers. A Rust Foundation Community Grants Program launched in 2022 does, however, have a budget of $625,000 and is offering four types of grant.
- Rust Foundation Fellowships: A one-year award (20 available) worth $1,000/month
- Project Grants: Single awards for discrete pieces of work from $1,000 to $20,000
- Event Support Grants: Single awards ranging from $100 to $500 to support events
- Hardship Award Grants: Single awards ranging from $500 to $1,500
With corporate interest in the language continuing to grow, The Stack asked Mara Bos, team lead of the Rust Library team, how Rust's corporate sponsors and the Foundation could best support the growth of Rust.
How to support the Rust community
She told us: “Rust relies on many many volunteers doing what they personally like to work on, doing what they personally think is best for the project. Companies should do everything to keep enabling that, and be very careful not to only focus on their own immediate goals for Rust.
"There's many companies that would pay lots of money for specific shiny new features that they need, but there's very few that would sponsor me without a specific assignment. This means lots of the work like organising, reviewing, exploration, general maintenance, refactoring and cleaning up, documentation, contributor guidelines, and so on, remain mostly unpaid/unsponsored, even when there's lots of money companies want to invest in Rust…”
Pointing to a recent article by Go maintainer Filippo Valsorda, who notes “to successfully fund an Open Source project, a company needs to pay the maintainers, not people external to the project [and] pay them real money: in the order of what they could make as senior engineers” she added: “This type of work is incredibly important for the project, arguably more than shiny new features. And this is the type of work that keeps burning folks out. This is the type of work that does not result in exciting weekly updates that can be reported up some management chain, but is the foundational work necessary to keep the project healthy.”
“For me, no-strings-attached sponsorship works best to enable me to do what's best for the project.”
With regard to the concern about corporate sponsors working too aggressively to try and influence the language’s direction for their own benefit, she says “it's not something I'm concerned about right now.
“Every contributor to Rust has their very own personal goals, so the project has always dealt with many potentially conflicting goals. It becomes a problem if at some point everyone involved in decision making would work for the same company, and that company starts to manage and plan for the project as if it's a part of that company, instead of an independent project they are simply contributing to. Everyone involved in Rust's leadership cares very much about the independence of the project, and would no doubt speak up if their employer tried to push them to do something that's not in the best interest of the Rust project. It's true though that money makes things complicated. One might feel a lot more pressure when their next bonus or promotion depends on the Rust project accepting their new feature, which can lead to more pressure in the teams making the decisions. (This is why I prefer to not work for a single employer, but instead be sponsored by many different companies.) It's important to note, by the way, that Rust makes decisions by consensus, not by majority vote.
"Having a majority of a team agree with some big change is not enough to make it happen. No member of the decision making team must have any objections for a permanent change for it to be accepted. So it's not easy to influence decisions away from what's best for the project” she added by email.
Outside of the Foundation others are ploughing their own furrow. The DevX initiative, for example, set up to “bridge the gap between enterprises benefiting from (F)OSS tooling and the under-served communities that build and maintain them” and led by Ernest Kissiedu and Beni Issembert with initial backing from Concordium (this ended June 1) has co-founded the Rust Cryptography Interest Group, supported the Rust Formal Verification Interest Group, and sponsored five maintainers from the Rust Project for seven months.
Josh Triplett, co-lead of the Rust language team (and an advisor on DevX sponsorships) is happy to see a variety of efforts here: "There's no reason sponsorship has to flow through any particular organization or entity" he tells us.
"Many companies have been leading the way in sponsoring Rust developers for a long time: Embark Studios, Ockam, Discord, and many others. DevX is trying to coordinate multiple companies to join forces to be able to do larger-scale sponsorships. The Rust Foundation started their own sponsorship effort, and that's incredibly important as well. Rustaceans whose work is supported partly or fully through sponsorships typically want a few different sources."
Triplett added to The Stack: “I'm thrilled with where we're taking Rust; we're making Rust more usable, we're bringing tools to the broader community that we previously reserved for internal use, and we're helping Rust's community scale and work with each other. We've been thinking about what Rust would need to look like in order to scale not just to twice as many users, but to a hundred times as many users, all with their own use cases and goals and backgrounds. I think the 2024 roadmaps are a start in that direction. Rust walks a careful line; we want people to be able to say ‘I feel supported by Rust, because it listens to my use cases and supports them’, and we *also* want people to be able to say ‘I feel supported by Rust, because it's stable and I can count on it to not break’”.
Asked if there is anything he’d like to see the community doing more of, he tells The Stack: “There's a continuous cycle between experimentation and unification: we experiment with ways of solving a class of problems, and over time we unify around common solutions as a base for future work.
Post continues below
“Right now, I'm looking forward to the pendulum swinging towards unification; for instance, I'm excited about the work to standardize async traits in the standard library, which will allow people to write async code without worrying about which framework they should use. The next round of experimentation I'm most excited about is capability-based systems, such as the I/O Safety work, the rustix library, and WASI and its module linking. I would also love to see a new "safe ABI" for interoperability between safe languages; if two languages that both understand safe types (strings and arrays that know their lengths, Option, Result, other "sum type" enums) want to talk to each other, they shouldn't have to drop down to an unsafe C ABI to do so…”
Back in the Rust Foundation, meanwhile, one thing that keeps coming up is questions around licensing. "Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses" its main source code repository says.
Few contributors recognised this as in any way a challenge -- Mara Bos told us: "Rust (and virtually the entire Rust ecosystem) uses a very permissive license... The ways in which open source and capitalism are incompatible are not solved by a license, but require a larger cultural change. I don't think Rust's license will change, even if it wasn't incredibly hard to make such a change to the combined work of thousands of people. Perhaps we just need some clarification around licensing, making it clearer which terms exactly apply to what parts" -- but the Rust Foundation says it fields a lot of calls from enterprise users seeking clarity.
As Rebecca Rumbul told The Stack: "My priority is actually just doing a full kind of audit at the moment. We recognise [the lack of clarity] is an issue, because a couple of times a week, we get an email saying, 'can you tell me if it's OK to do X if we're using Y?' We're very lucky, we have good counsel. So we're able to answer individual questions. But those questions are only going to increase if the popularity of Rust continues to grow at the same pace. Pretty soon, if that growth continues, it will be unmanageable, asking, answering individual questions like this. So we recognise that we need to do a substantial piece of work on that. One of the things I actually want to do is involve a lot of the maintainer community in a kind of working group, where they can actually bring all of their expertise to the table as well, because there are scenarios where I don't even know what might happen. I think it would be prudent of us to do as much work on that as possible now... "
"[But] the Rust Foundation has no control over the maintaining community, it's up to them to take care of the ideological direction of the project and beyond" she adds. "We exist to try and steward the language, and make sure it is sustainable and successful. But we do also have to make sure that we're aligning that with the needs of the community and what they want, and how they want to do it. Some open source [projects] get a little bit mired down, because open source communities have their own ideas, and they have their own [individual/competing] power structures. If I was going to be trying to force people to do stuff I'd be working for corporate, right?"
New Rustaceans can ask for help in the friendly new members Zulip stream.
