In November 2015, rmcgibbo opened Twine Issue #153. Less than two months later, he closed it with no explanation. The motive behind this baffling move might have remained an unsolved Internet mystery if not for one crucial fact: someone asked and rmcgibbo was willing to talk:

thedrow on Dec 31, 2015

Contributor

Were you able to resolve the issue?

---

rmcgibbo on Dec 31, 2015

Author

No. I decided I don’t care.

We all had such moments, and this humorous exchange serves as a reminder that certain matters are not worth stressing about. Like Marcus Aurelius once said, ‘choose not to be harmed — and you won’t feel harmed.’ However, instead of discussing philosophy, I want to bring up some of my experiences to make a point about contributions to free software projects.

The two pull requests

Rather than London and Paris, this tale takes place on GitHub and linux-kernel mailing list. The two titular pull requests (PRs) are of my own making and contrast between them help discuss and critique Rust’s development process.

Matching OS strings in Rust

At the beginning of 2023, I started looking into adding features to Rust that would allow for basic parsing of OsStr values.¹ I eventually stumbled upon RFC 1309 and RFC 2295 which described exactly what I needed. The only problem was that they lacked an implementation. I set out to change that.

I submitted the OsStr pattern matching PR inspired by those RFCs in March 2023. Throughout April and May, I made various minor fixes to address Windows test failures, all while waiting for a reaction from the Rust project. I had no idea whether my approach was acceptable and I didn’t want to spend more time on a PR only for it to be rejected.

And waited I did. Nearly two years, until January 2025, when the Rust project finally responded. The code was accepted. A pity that I didn’t care any longer. I certainly didn’t care enough to resolve the numerous merge conflicts that had accumulated in the interim.

The PR was closed soon after and the feature remains unimplemented.

Allocating memory in Linux

In July 2010, I submitted the Contiguous Memory Allocator (CMA) to the linux-kernel. At the time, it was a relatively small patchset with only four commits. I didn’t know then that it was the beginning of quite an adventure. The code went through several revisions and required countless hours of additional work and discussions.

It was April 2012, nearly two years later, when version 24 of the patchset was eventually merged. By then, it had grown to 16 commits and included two other contributors.

On paper, both contributions took nearly two years from submission to conclusion. And yet, while I remain particularly fond of my CMA work, the Rust experience is an example of why I dislike contributing to Rust. The two years in the Linux world were filled with hours of discussion, revisions and rewarding collaboration, the two years in the Rust world were defined by silence.

Discussion

The linux-kernel is often described as a hostile environment. Linus Torvalds in particular has been criticised numerous times for his colourful outbursts. I don’t recall interacting with Linus directly, but I too have received dressing-downs; I remember the late David Brownell rightfully scolding me for my handling of USB product identifiers for example.

And yet, I would take that direct, if sometimes harsh, feedback over Rust’s silence every time.

From the perspective of a casual contributor, the Rust development process feels like a cabal of maintainers in clandestine meetings deciding which features are worth including and which are destined for the gutter. This is hyperbole, of course, but it’s born from experience. Patches are discussed in separate venues which don’t always include the author.

If the author receives a final rejection, is there a point in arguing? What arguments were made? Was their proposal misunderstood? Is there an alternative that could be proposed? Eventually, decided I don’t care.

Improvements

The improvements are obvious, though hardly easy: transparency and simplicity.

All substantive discussion about a PR should happen on that PR, with the author and other contributors included. A healthy free software project should not include ‘we discussed this in the libs-api meeting today, and decided X’ comments as a regular part of contribution process. It leaves the very person who did the work in the dark as to arguments that were made.

The contribution process should be simplified by reducing the bureaucracy. When are Request for Comment (RFCs) and API Change Proposals (ACP) needed exactly? What are the different GitHub labels? A casual contributor has little chance to understand that. In the handful of times my patches were merged, I still had no idea what process to follow.

RFC process in particular should die quick yet painful death. By design, it separates the discussion of a feature from its implementation. This leads to accepted RFCs that are never implemented (perhaps because the author lacked or lost the intention to carry it through) or implemented differently than originally documented (for example, when a superior approach is discovered during development). If someone has an idea worth discussing, let them send a patchset and discuss it on the PR. After all, ‘talk is cheep’.²

Rust’s perspective

Then again, I’m just one engineer with a handful of Rust contributions, and these are merely my experiences. Different projects have different needs, and the processes governing them have been established for a reason. Coordinating work on a sizable codebase is non-trivial, especially with a limited pool of largely volunteers, and necessitates some form of structure.

In large projects, it’s often infeasible to include everyone in all discussions. Linux has its version of ‘clandestine’ meetings in the form of invitation-only maintainer summits. However, their scope is much broader, and most low-level discussions on any particular feature happen in the open on the mailing list.

Similarly, the Rust project should, in my opinion, consider whether its current operational methods are limiting its pool of potential contributors. It’s easy to dismiss this post and my contributions, but that misses the point: For every person who complains, there are many who remain silent.³

Final Thoughts

This isn’t just a story about Rust. It’s a lesson for any large-scale project. The most valuable resource is not the code that gets merged, but the goodwill of the community that writes it. When contributors are made to feel that their efforts are disappearing into a void, they won’t just close their PRs; they will quietly stop carrying.