Public developer spats put bcachefs at risk in Linux

Fisticuffs in FOSS-land! Fancy file system's future fraught!

Updated Bcachefs project lead Kent Overstreet has written about his problems with the Linux kernel folks and the code of conduct put in place to prevent such flamewars.

The bcachefs team is partly funding the development of their next-gen file system using Patreon, where the project lead Kent Overstreet posted a lengthy article about trouble in the kernel. The current dispute has resulted in Linus Torvalds refusing the latest fixes to this radical new file system, and there's a real risk that the Paramount Penguin may fulfill his threat last month to remove the bcachefs from the kernel. This would be a big loss; it took years of work before it was finally included earlier this year.

At least one of the causes of the current situation is that Overstreet posted an intemperate response in an earlier thread, which ended in swearing.

Now, to be fair, this is very far from the first time that's happened on the Linux kernel mailing list. Indeed, The Register has been reporting on such incidents at least since 2013. Even since Linus took a break back in 2018 to "get help on how to behave differently," it still occasionally happens.

The thing is, up to a point, Torvalds can get away with it. It's his project and he's still the boss. Overstreet isn't, and can't. Indeed, others in general shouldn't, and to prevent it from happening, the kernel team has adopted a code of conduct, and there's a committee to enforce it. It replaces a smaller, simpler code of conduct instituted nearly a decade ago, as we reported at the time.

In this instance, Shuah Khan of the CoC team has remonstrated with Overstreet. Although the tone of the exchange has calmed somewhat, it has yet to bring resolution.

Overstreet's post is over 6,000 words long, but in The Reg FOSS desk's opinion, he does in fact make his case fairly well. (We have seen vigorous rejection of this in discussions elsewhere, though.)

There are several aspects to the problem here, but one of the biggest is simple human nature. Whereas corporate products' development is driven solely by commercial imperatives, FOSS development is much more personal. People choose to get involved for all kinds of personal reasons, from wanting something to work a little differently (thanks to Eric Raymond, called scratching an itch), or having a clever idea and wanting to give it to a project, or some other motivation other than simply money. Although many big companies have made a lot of profit thanks to open source, it's made very few individuals rich.

Codes of conduct alone cannot prevent emotional conflicts in what are, for many of the people involved, passion projects. To make matters worse, the people most closely involved often possess the explosive combination of genius-level intelligence and intense personal investment in their projects.

Nobody is immune from letting their emotions get involved. Recently, the Rust-in-the-kernel project leader quit. Famously, after presenting a conference talk, he was on the receiving end of what's often termed "a question that's more of a comment" – or in this case, more of a complaint – from celebrated Linux file systems developer Ted Ts'o. As it happens, that talk was co-presented by the very same Kent Overstreet.

Linux Weekly News has a deep-dive into what the talk covered, but an executive summary might be that the Rust folks are proposing changing how the C parts of the kernel work slightly in pursuit of cleaner, more reliable code. Some of the people who wrote that C code are not at all happy about this.

It seems to us that neither side, strictly speaking, is right or wrong. As best as we can understand them, the suggestions seem practical and reasonable. But from the perspective of the folks who developed the existing file systems, years ago in plain old C, their code is good and works fine, so why change it? The result is that, from their own positions and perspectives, both sides are correct. That makes this a tricky discussion to mediate, and that seems to be at the core of the problem.

These things happen in long-running FOSS projects. For instance, in the Emacs world, Alan Mackenzie, who maintains the pivotal CC mode part of the program, just resigned from his role. (CC-Mode assists in editing code in C and C-like languages, which is arguably the single most important use of Emacs, so this is a big deal.)

It's too soon to call how this will end. The personal suspicion of this vulture is that ruffled feathers will be smoothed down and bcachefs will not be permanently dropped. There are many interested parties here who could really use an all-GPL next-generation file system with copy-on-write snapshots, which is more resilient and repairable than Btrfs. We're not convinced that Red Hat is committed enough to its Stratis storage project for that to be it, and no other vendors seem to be very interested.

As for the larger drama around Rust in the kernel and so on, maybe it will blow over, or maybe it will drive the main development efforts elsewhere. It's still possible that something radically simpler may yet supplant it, and relegate Linux to a compatibility layer that only runs inside VMs. Stranger things have happened. ®

Bootnotes

Just yesterday, Torvalds sent a code commit that finally removes ReiserFS from kernel 6.13. That long and tragic story is finally over.

In case you have difficulties opening Kent Overstreet's blog, Patreon has protective measures in place, which gave us problems on some browsers. When we were using Waterfox, it didn't believe this vulture was a human (we assure you, the FOSS desk is an entirely LLM-free zone). You may have to try a few different browsers or machines.

Updated to add on November 29th:

A verdict was reached and punishment handed down by the kernel's Technical Advisory Board:

The code of Conduct Committee has determined that your written abuse of another community member required action on your part to repair the damage to the individual and the community. You took insufficient action to restore the community's faith in having otherwise productive technical discussions without the fear of personal attacks.
Following the Code of Conduct Interpretation process the TAB has approved has approved the following recommendation:

-- Restrict Kent Overstreet's participation in the kernel development process during the Linux 6.13 kernel development cycle.

- Scope: Decline all pull requests from Kent Overstreet during the Linux 6.13 kernel development cycle.

The current kernel is version 6.12. It's likely to declared the latest long-term support version before the end of the year, but it hasn't just yet. The future next version, 6.13, is still under construction. This means that there won't be any new code or fixes from Overstreet in that forthcoming version of the Linux kernel. What happens in the version after that, presumably version 6.14, remains to be seen. That release, early next year, will matter a bit more, as it's quite likely to be in Ubuntu 25.04 and Fedora 42. Right now, it's not likely that anyone is using bcachefs in production and so this shouldn't directly affect anyone very much.

Even so, it's a serious rap on the bcachefs project's metaphorical wrist. Although this vulture doesn't track internal work-in-progress all that closely – there is always some bickering going on – we can't recall a previous event like this before.

Overstreet responded: "I do want to apologize for things getting this heated the other day, but I need to also tell you why I reacted the way I did."

It is an apology, but a guarded and defensive one. We suspect that this will blow over, but only time will tell.