Diseased Open Source Software Community - it's about ethics in Code of Conducts

LWN: Bcachefs goes to "externally maintained" (a)
Phoronix: Linus Torvalds Marks Bcachefs As Now "Externally Maintained" (a)
So, not completely out of the kernel (yet), but not accepting patches.
Kent FINALLY put everyone else over the edge. Just from this guy's writing, I wouldn't want him anywhere near a team I am on. He is totally unable to play nicely in the sandbox.

This whole issue is so stupid. Linus (and most of the team) have a strong policy that during a release candidate of the kernel that one is only allowed to submit bugfixes. This is an old, old, old policy. Kent's been told this, and many many many people are subject to the same type of restriction. Here's a brief wall of shame so you can see how long this stupidity has gone on:

Kent Overstreet Timeline of Conflict

Late 2023:

Pre-mainline drama begins as Bcachefs merges into Linux 6.7 kernel
Early adopters note "30 preparatory patches" sparking negative feedback
"Kent spends a lot of time and effort defending Kent. Some feel his communication style is as complex as his filesystem." - HN thread, June 2023
His Patreon updates reveal defensiveness; critics call him "difficult"
"Kent is obviously well-intentioned and acting in good faith. He is also rather difficult." – October 2023 thread

August 2024:
Debian packaging ordeal hits hard
Maintainers cite "hostile emails" and "public rants on lkml and reddit" for Bcachefs-tools orphaning
"Upstream insists on exact versioning... and also insists that Debian maintainers go on a war to change Debian's Rust policy to his liking. If it's 'my way or the highway', I guess it's the highway." – Debian packager, Aug 2024

October 2024:
Clash with Linus Torvalds over pull requests
Linus claims Kent "won't follow process and work with others"
Kent retorts: "If you're so convinced you know best, I invite you to start writing your own filesystem. Go for it." – deemed "tone-deaf" by HN

November 2024:

Linux CoC decision on his behavior
Kent tells critic to "get their head checked" and "get the fuck out of here with this shit"
"His language is frequently escalatory and he seems unable to contemplate alternatives until at the brink of someone's patience." – Nov 2024 thread

July 2025:
Bcachefs may be headed out of mainline kernel
"Kent has gotten this same feedback across practically every single platform... He is unable to take critique and will instead just continue to argue and be combative." – HN, July 2025

August 2025:
Bcachefs marked "Externally maintained"
"Every comment and e-mail I've seen from you has demonstrated an impressive lack of understanding with regard to why you're being treated as you are."


Kent's mode of operation is to join a team project or organization. He says he understands the rules. Then the trouble begins. The only one who knows anything in Kent's world is Kent. He begins to ignore the rules, citing them as being "unfair" and "inefficient". If anyone calls him out, he says they are part of the problem. Kent can never be a subordinate. He thinks his own ways of working are the best. Unfortunately for him, Linux is not his project and he is not king.

The sad thing is that his filesystem actually shows a lot of promise, but his bull-headed nature leaves him unable to follow any externally imposed rules, even in the name of progress.

The future of Bcachefs is almost certainly going to be a total table-flip by Kent, because if it's maintained externally from the kernel, it's much less likely to be supported in distributions and consequently way less users will have their hands on it.

The length and breadth of his bad behavior is awe-inspiring. He's fought with essentially every single person he's ever worked with, has never backed down and has never learned one iota about teamwork or compromise.

It's rare to see someone this harmful to themselves and to their own project.

Fuck you Kent; both for wasting everyone's time fighting instead of working on the kernel and for flushing Bcachefs down the toilet. As much as I like ZFS, it can never be merged with the Linux kernel and will always be a second citizen. That leaves btrfs, which people are still heavily divided on. Some users love it, some hate it, and it doesn't help they never got their RAID implementation right, which will eat people's data even at the current date. (To be fair, they tell you not to use it now)

That means that the state of advanced file-systems in Linux is rather poor: almost all users run one of ext4, btrfs, xfs. Both ext4 and xfs are very conservative designs. btrfs is more ambitious, but also so ambitious that it has annoyed some people with its quirks.

Open Source has a lot of advantages over commerical software development, but handling bad actors is not one of them. If Linux was a company, Kent would have been shot out of a cannon and fired long ago. However, in an organization where everyone is volunteers things are a bit more murky and slow.

I am skeptical Kent will continue development on bcachefs for an extended period now. It's not like he can easily just take it and convert it to working on some other operating system. In a world where that is easy, Kent's nasty attitude would soon turn whomever ran that project against him.

Sorry for the extended post, but I find Kent so eternally frustrating I was counting down time until him and Linus finally had it with each other, and sure enough, it came. Reading posts by Kent always raises my blood pressure and I'm happy that he's almost certainly permanently sidelined from here on out.
 
I am skeptical Kent will continue development on bcachefs for an extended period now. It's not like he can easily just take it and convert it to working on some other operating system. In a world where that is easy, Kent's nasty attitude would soon turn whomever ran that project against him.

Sorry for the extended post, but I find Kent so eternally frustrating I was counting down time until him and Linus finally had it with each other, and sure enough, it came. Reading posts by Kent always raises my blood pressure and I'm happy that he's almost certainly permanently sidelined from here on out.
bcachefs is now marked "Externally maintained" rather than "Supported" (per the linked stories upthread), except no one seems to understand what that means. Kent himself said he doesn't know. I searched the MAINTAINERS file and do not see this "Externally maintained" phrase anywhere else, so it may be innovated just for Kent. It may be symbolic, and Linus will continue to accept pull requests, just perhaps with more friction. Presumably Linus won't remove it from the kernel any time soon, since people are already using it, but then he won't want to leave fixed bugs in, either.

bcachefs does really seem like the only hope for a Linux next-gen filesystem. It would be a pity if it got stuck out of tree forever just because of Kent's combative personality. Hopefully they can come to some understanding. Maybe if bcachefs stabilizes out of tree, it will be let back in.

Kent's view is that his fixes and features are urgent because he doesn't want bcachefs's users to suffer data loss, and also he wants beta testers to be on the latest so he won't field obsolete bug reports and will quickly learn of any new bugs. Linus's view is that submitted changes must follow the established kernel release schedule. These views are currently unreconcilable.

Hacker News discussion: https://news.ycombinator.com/item?id=45074312

return to monkey
*monke
 
Kent FINALLY put everyone else over the edge. Just from this guy's writing, I wouldn't want him anywhere near a team I am on. He is totally unable to play nicely in the sandbox.
what is it with linux filesystem creators being completely batshit insane
this is like the second time
 
bcachefs is now marked "Externally maintained" rather than "Supported" (per the linked stories upthread), except no one seems to understand what that means. Kent himself said he doesn't know. I searched the MAINTAINERS file and do not see this "Externally maintained" phrase anywhere else, so it may be innovated just for Kent. It may be symbolic, and Linus will continue to accept pull requests, just perhaps with more friction. Presumably Linus won't remove it from the kernel any time soon, since people are already using it, but then he won't want to leave fixed bugs in, either.
I think it means that the kernel version of bcachefs will have a feature freeze with no new pulls allowed again, and in time it will be removed from the kernel entirely in favour of an external repository like ZFS, where Kent can have full control over the release schedule for his filesystem without putting the kernel schedule at risk. AI summary below
 
Kent's view is that his fixes and features are urgent because he doesn't want bcachefs's users to suffer data loss, and also he wants beta testers to be on the latest so he won't field obsolete bug reports and will quickly learn of any new bugs. Linus's view is that submitted changes must follow the established kernel release schedule. These views are currently unreconcilable.
There is a strict hierarchy to Linux Kernel development that flows down from Linus. Kent's opinion is relevant as far as Linus will consider it. Linus has long ago set his standards for the kernel and the relevant ceremony around releases. Kent's biggest problem is that he answers only to himself and makes excuses when he needs to violate other people's rules. Until such time as Kent establishes his own *nix kernel and can run things as he sees, he's going to be watching the game from the bleachers since he can't figure out what it means to be part of a team.

One is free to walk all over the Earth talking about the shortcomings of Linus' approach. However, if one wants to get their code and/or subsystem part of mainline, you better follow the guidance from the fellows at the top of the tree. Kent's perpetually unable to do this. In what is a common trend for Linux / OSS related sperging, Kent is "not sure" why he's being singled out.

I have some strong opinions myself. However, when I'm not in charge (and stand to benefit by being part of a team) I know how to fall in line. I recall seeing something from Intel a while back (not recently, they are a nightmare now) and the quote was "Disagree and commit". I've always thought that was a great philosophy.

I've heard it said that a large and competent team accomplishes far more than an individual can. If you collaborate with the skill of Kent, your output will be naturally limited to what a single individual can do. That's not nothing, but consider how different the Linux kernel would be if Linus was the only one allowed to write code for it.

what is it with linux filesystem creators being completely batshit insane
this is like the second time
Well, at least Kent hasn't killed anyone. He probably does have strong opinions about the most efficient way to kill someone, however.

bcachefs is now marked "Externally maintained" rather than "Supported" (per the linked stories upthread), except no one seems to understand what that means. Kent himself said he doesn't know.
Well, it certainly doesn't mean anything good and I don't think this will increase support for bcachefs. Regarding Kent saying "I don't know", he also "doesn't know" why he's being singled out. I'd love to see him join a project with Kenneth Reitz and Lennart Poettering. It might not release any software, but it would make for amusing drama and a lot of gnashing of teeth.

I'd imagine its new status means that bcachefs will more or less get feature frozen in the kernel. It's possible someone talented and more compliant than Kent will contribute, it being open source. I am not sure how feasible that is. Hopefully bcachefs doesn't have a bus factor of one. Filesystems written by one person and filesystems that cannot move forward without that one person is probably a really bad idea.

The real tragedy is all the time that could have been spent by kernel developers writing C code for the kernel had to get spent reminding Kent for the Nth time the rules around development, and waste further time answering his long rants on LKML. There is no upside at all to this. Linus is well aware of other development modes and methods and is well set in his ways.

If Kent could somehow prove his cowboy coding gets better results, then maybe Linus would be receptive. Don't forget Kent is so sloppy he submitted patches that don't even compile which is an odd scenario for someone claiming to care so much about reliability.

"Move fast and break things" is not the way you want to run a filesystem at all. At least, one that keeps your data safe.
 
"Upstream insists on exact versioning... and also insists that Debian maintainers go on a war to change Debian's Rust policy to his liking. If it's 'my way or the highway', I guess it's the highway." – Debian packager, Aug 2024
i wish for TRD, if only to save the poor debian packagers from a small fraction of their eternal suffering
That's not nothing, but consider how different the Linux kernel would be if Linus was the only one allowed to write code for it.
insert a joke about the gnu hurd here
Well, at least Kent hasn't killed anyone.
that we know of...
He probably does have strong opinions about the most efficient way to kill someone, however.
:thinking:
I'd imagine its new status means that bcachefs will more or less get feature frozen in the kernel. It's possible someone talented and more compliant than Kent will contribute, it being open source. I am not sure how feasible that is. Hopefully bcachefs doesn't have a bus factor of one. Filesystems written by one person and filesystems that cannot move forward without that one person is probably a really bad idea.
well apparently a lot of people care about it, so as long as the quality is good enough for people to understand, somebody else might become the new bcachefs guy
or maybe it will be abandoned and left to rot like reiserfs
Don't forget Kent is so sloppy he submitted patches that don't even compile which is an odd scenario for someone claiming to care so much about reliability.

"Move fast and break things" is not the way you want to run a filesystem at all. At least, one that keeps your data safe.
ok it's plain to see that any sane person would keep this guy very far away from the kernel
"move fast and break things" is a terrible idea when developing any software that is expected to function properly at all times
guess what the average kernel is the epitome of
 
Hopefully bcachefs doesn't have a bus factor of one. Filesystems written by one person and filesystems that cannot move forward without that one person is probably a really bad idea.
It absolutely has a bus factor of one.
While having to live outside of linus tree is suboptimal, that is the least of Kent's and bcachefs problems going forward.

The much more serious issue and why it is and will remain bus-factor-one is Kent's behavior an how abrasive he is. How he treats any disagreement or criticism no matter how minute as a vicious personal attack and responds in flaming anger.

Having a filesystem live outside the tree is not a big deal in itself. There are several very important fileystems that do and have lived successfully outside of the tree for a long time.
It causes some extra work living outside of the tree but is not a big deal.

What is a SUPER fucking enormously big deal is how Kent has alienated a very large number of very important people in the VFS and MM space to the point that they refuse to interact with him in any shape or form.
That is a pretty fucking serious issue. Not which repo that code lives in.
That is a big deal and why the filesystem will struggle or just die out long term.
 
What is a SUPER fucking enormously big deal is how Kent has alienated a very large number of very important people in the VFS and MM space to the point that they refuse to interact with him in any shape or form.
That is a pretty fucking serious issue. Not which repo that code lives in.
That is a big deal and why the filesystem will struggle or just die out long term.
this would be circumvented if some hypothetical gigachad were to familiarize himself with bcachefs, and then hack on a fork while also following basic instructions from top kernel mailing list brass
 
  • Optimistic
Reactions: Markass the Worst
Kent's mode of operation is to join a team project or organization. He says he understands the rules. Then the trouble begins. The only one who knows anything in Kent's world is Kent. He begins to ignore the rules, citing them as being "unfair" and "inefficient". If anyone calls him out, he says they are part of the problem. Kent can never be a subordinate. He thinks his own ways of working are the best. Unfortunately for him, Linux is not his project and he is not king.
Sounds like Hector "Definitely not Lina" Martin, who spent months complaining about kernel procedures and then flounced for very similar reasons.
 
Open Source has a lot of advantages over commerical software development, but handling bad actors is not one of them. If Linux was a company, Kent would have been shot out of a cannon and fired long ago.

Maybe. Depends on the company. Some would just shove him in a dead end team, giving him big solo tasks they need done quickly but making it clear he'll never get promoted and eventually axe him in a mass layoff. Some companies would just fire him. I've been both in small and large companies.

what is it with linux filesystem creators being completely batshit insane
this is like the second time
Well, at least Kent hasn't killed anyone. He probably does have strong opinions about the most efficient way to kill someone, however.

If you read Reiser's letter from prison, I have a feeling he's probably reflected/learned more about life and people than Kent ever will.
 
Back