Is Rust the road to salvation or the road to perdition for the Linux ecosystem?

Are Rust and Go leading the way to more secure and robust software or are the popular programming languages trojan horses for less freedom?

Rust and Go are becoming firmly established and widely adopted programming languages for the next generation of developers due to their compelling benefits. Those benefits have a cost that creates risks for the Open Source and Linux ecosystem. Rust and Go communities are part of a wave of policies from various Open Source communities that are changing the direction of the Linux ecosystem. What are the implications?

Rust is an exciting, modern programming language with a vibrant community. The Rust Language is evolving rapidly and gaining new, powerful features. In many ways the advanced features of Rust are reminiscent of Ada or Haskell -- sort of Haskell-lite -- with many of the powerful features and security capabilities available in a more easily accessible manner. The community has a lot of momentum despite growing pains as it adapts to a more formal structure and as large companies apply it in critical, production environments that require long-term maintenance and support. There is a tension between rapid innovation and a stable language on which to build commercial products requiring commercial support. Some also worry that the language is losing coherence around its core design principles as elements from others languages are slotted into the Rust syntax.

One of the primary benefits of Rust is its focus on Memory Safety. The definition of the language and its "borrow checker" feature explicitly track the lifetime and ownership of heap memory. The language prevents common programming errors with respect to heap memory through annotations that describe the ownership and lifetime that are enforced at compile time. Go addresses the same class of problem through garbage collection, but garbage collection has inherent challenges with respect to pauses and performance hiccups, despite tremendous improvements in the field of garbage collection. While Go is a tremendously successful programming language for the Cloud, Rust ensures that programmers targeting a traditional, non-garbage collected language cannot accidentally inject errors with respect to memory safety.

The design point of Rust and its flexibility to explicitly escape to "unsafe" behavior, and direct access to memory and memory layout, allows Rust to address systems programming tasks that are not well suited to languages such as Go or Java. The design approach also permits Rust applications to achieve near bare metal performance similar to languages like C. The combination of features allows Rust to provide a programming environment that is competitive with respect to the performance and energy efficiency of applications that simultaneously permit fine-grained control by programmers. All with a nice, modern aesthetic, design and syntax, and with a fantastic, comprehensive package system.

The Cargo / Crate environment of Rust provide a modern packaging system for ease of building, testing, and distributing applications, and tracking dependencies. It provide a huge advantage for Rust. One of the byproducts of the build system and its defaults is that packages normally are statically linking for most of their dependencies to ensure that Rust applications are self-contained and can be copied with minimal concern for dependencies. This design point applies nicely to container environments by cleanly avoiding complicated or conflicting dependencies. Related to the static linking design philosophy is a recommendation in the Rust community to eschew the GPL license and GPL dependencies to avoid license implications for the entire package.

The memory safety benefits of Rust not only are encouraging the use of Rust for new projects, but also motivating developers to rebuild existing ecosystems with Rust. Prossimo / memorysafety.org is sponsoring the rewrite of critical infrastructure in Rust, including TLS, NTP, Curl, DNS, and su/sudo. Other developers are working to rewrite GNU coreutils and other foundational components of the GNU/Linux ecosystem in Rust[1]. This greenfield combined with memory safety benefits is attracting motivated developers.

The name GNU/Linux has elicited a lot of rancor and controversy because, from the earliest days, a complete and functioning Unix replacement was created by combining the tools and components from the GNU Project with the Linux kernel. The Linux kernel, Linux distributions, and the current Linux ecosystem would not exist without the environment that the GNU Project had created. The GNU Project tools all use the GNU General Public License (GPL). A conversion and rewrite of the ecosystem to Rust conveniently replaces those tools with non-GPL equivalents, and wipes GNU from the history of Linux[2]. As mentioned in other essays, the current generation of developers mostly is oblivious to licenses and the impact of licenses[3]. Additionally, a portion of the Open Source community seems to relish the opportunity to extract Linux from its connection to the GNU Project. What are the implications?

For Profit companies and Venture Capital investors care about licenses. The explosion of software startups has developers dreaming of unicorns and wealth. These software startups and the VCs that fund them want the control and unfettered ability to commercialize and monetize their products. The products are overwhelmingly based on Open Source software and are themselves Open Source to benefit from the creation of a platform and ecosystem.

The companies leverage the work of the Open Source projects and combine it with proprietary features. If the company can dominate the project through control of the maintainers and governance, it can control the design and development so that changes are compatible with its business plans and don't introduce major conflicts with its proprietary features. To retain the greatest freedom of action, startups prefer non-GPL licenses. A wide range of developer and academics also have gravitated towards non-GPL licenses, either because they are optimistic for financial success or because they are following the license pattern that they see adopted by their peers.

Combined with language preferences and financial motivations, software supply chain security is a growing issue. The attention to Open Source and bills of material for software supply chains (SBOM[4]) gives the outward appearance of openness and transparency while retaining the opportunity to hide proprietary changes. SBOMs are a crucial step to address the challenge of discovering, tracking and fixing software built from antiquated packages with known vulnerabilities. SLSA[5] and S2C2F[6] provenance create important policies and practices for the safe creation and consumption of Open Source packages, but those policies can create a false sense of security. One knows the names of the components and that they were combined safely, but one does not always have the right to see the ingredients. Software with permissive Open Source licenses could be modified by the groups that provide assured builds. It's like knowing that a building was built from particular shipments of rebar and concrete, but not being allowed to know the test results for the materials themselves nor the permission to take samples for one's own testing. It allows big, respected tech brands to say "Trust Us" and "We're complying with all of the best practices to provide you with safe software."

The elimination of GPL from widespread use also allows companies to insert components into software with unknown effect (tracking, telemetry, restrictions, etc.) while complying with software supply chain reporting rules. Companies always could flout the requirements of the GPL, but that incurred legal risk. An Open Source ecosystem without the GPL allows companies to implement these policies with impunity.

Many leaders in the Linux ecosystem advocate that the Linux kernel and GNU C Library (GLIBC) should be portable and buildable by both GCC and Clang so that they don't depend on a single compiler. The advocates of the Rust language, including the major organizations deploying the Rust ecosystem in production, show tepid support for the ability of GCC to compile the Rust language and are completely satisfied with dependence on the single, LLVM-based rustc compiler. GCC remains a widely used production compiler that is at the core of the Linux ecosystem, so it seems a natural complement to promote the adoption of the Rust Language for very little additional investment. What are the implications of this prioritization?

A vocal opponent of this license dilution is the Free Software Foundation and the Software Freedom Conservancy. The GPL ensures the rights of developers and users to have full access to the source code from which their software was built, including the ability to modify it and redistribute it. However the strident and absolutist ideological advocacy of the FSF drives away many of its natural allies. The FSF is good at expanding the Overton window of conversation, but less effective at compromise and at building a big tent of supporters. A broad consensus in the Open Source community is concerned about freedom, but is repulsed by the behavior of the FSF supporters who demand uncompromising ideological purity. The vitriol drowns out the arguments for Free Software and encourages software developers to shun the GPL, in addition to the financial motivations.

The behavior of the FSF undermines its own goals and drives away potential partners. The perennial, passive-aggressive victim mode behavior grates on the broader FOSS community and spurs on the effort to remove GNU from the GNU/Linux system. The antagonistic rhetoric promotes a defensive, reactive, negative cycle. Competition and envy often can be stronger motivators than altruistic reasons.

Most of the Open Source community doesn't care or ignores the debate about GNU/Linux, GPL, and licenses. Among the people who try to participate in the conversation, the sanctimonious language of both sides creates a hostile, divisive environment. As with any religious war, anyone who deviates from dogma is considered an apostate to be attacked and hounded out of the community. Each side demonizes the other, and many developers adopt the attitude of their peers and their community higherarchy with little investigation, creating entrenched biases. It's the Saducees, Pharisees, and Zealots back for a reprise. How do we foster a reinvigorated dialogue around shared goals?

Amidst the financial incentives, security incentives, and the license rivalry, Free and Open Source Software is hurtling towards an existential crisis. Unix initially was released over 45 years ago. GCC initially was released over 35 years ago. The Linux kernel initially was released over 30 years ago. LLVM initially was released over 20 years ago. The generation of developers who created the base tools of the Linux system and ecosystem are nearing retirement[7]. Amidst these challenges, younger developers consider maintaining existing, critical, robust software as boring and not rewarding. They don't feel a sense of accomplishment from mastering existing technology, and maintaining robust, resilient software systems relied on by billions of people and systems worldwide.

Despite the coordinated or uncoordinated efforts of the Linux Foundation, Google, Microsoft, Meta and other deep-pocketed companies that support FOSS[8], the next generation of developers are not eager to be relegated to a career of maintaining the previous generation of technology. Some developers rationalize the opinion based on technological improvements and more modern techniques. But fundamentally, young adults are drawn to revolutionary ideas and wish to make their mark on the world. It is more exciting to create something new. Replacing or rewriting a critical component is considered a significant accomplishment and rewarded in technological communities and technology companies, e.g., promotion packages, compensation, job offers. The false dichotomy is that any technology either is vibrant and evolving, or it's a labor of love in a history museum. What are the implications?

One benefit of a rewrite of the critical parts of the Linux ecosystem in Rust is that it kicks the developer demographic crisis can down the road. Rewriting the Linux ecosystem in Rust probably extends the life of Linux by another 20-30 years through a transfer ownership of the foundational components to a new generation who now feel that they have a stake in the ecosystem. Rewriting the ecosystem gives the next generation a sense of accomplishment.

And what happens after another 20-30 years? Maybe AI can take over by then.

The Rust programming language has a lot of great attributes that contribute to it's growing adoption, but it's not a panacea. The risk to the Open Source software supply chain is gaining attention. The world is experiencing an inflection point in software development due to both technical and cultural forces: new software paradigms, new software tools, increased security risks, evolving financial motivations, new generations of developers, demographic changes. All of these elements are interacting and motivating changes in the software development ecosystem and developer behavior with complicated, unforseen consequences. The Open Source Software community must remain vigilent to protect the freedoms that it advocates in the midst of this rapid transition. The current Linux and Open Source ecosystem was built on the shoulders of giants and we should not squander their gifts without carefully considering the benefits of the rich legacy that we have been entrusted to protect. There are some very enthusiastic developers advocating for major, rapid changes to the Linux ecosystem, but are we going to enjoy the destination? What are the implications?

As so eloquently expressed in ancient mythology, one must incorporate the past and look to the future to be a good leader.

[1] https://github.com/uutils

[2] https://twitter.com/teej_dv/status/1686761462553800704

[3] https://www.baldurbjarnason.com/2023/the-floss-transition/

[4] https://www.cisa.gov/sbom

[5] https://slsa.dev/

[6] https://github.com/ossf/s2c2f

[7] https://xkcd.com/2347/

[8] https://github.com/ossf/wg-securing-critical-projects