The Distance Between FOSS Utopia and Reality

All excellent open-source projects I've seen and used are either spearheaded by large enterprises/organizations or have over ninety percent of their code written by a single, highly skilled developer. These projects are less "open-source" and more "public source code," as it's difficult for external individuals to intervene in the main development process. In the dichotomy of "cathedral" versus "bazaar," these projects clearly lean towards the "cathedral," despite wearing the "open-source" label.

The open-source projects I've seen that widely attract external developers, where most people can "stick a foot in" the development process, are generally dumpster-fire level disasters. These are truly "open-source," clearly belonging to the "bazaar" side in the "cathedral" versus "bazaar" dichotomy.

With the above experience, it's hard not to form an opinion on the practical application of the "bazaar" model. The current state of the software industry has proven that the "bazaar" model is not suitable for most software projects.

Ask yourself, how many forks of open-source projects have you maintained? Can your fork keep up with upstream progress?

Most forked projects maintained by individuals/small organizations become relics after a short period of intensive commits:

Even large forks arising from a split in opinion, maintained by some members of the original development team, often struggle to persist. The evidence is clear: there are not many software projects on the market that successfully maintain parallel development after a major fork——it doesn't take long for one side to emerge victorious. The very few large forks that do manage to sustain parallel development either have an upstream that is a mature project adding almost no new features, or they have completely decoupled from upstream reliance.

There's a world of difference in the understanding of a project between its main maintainers and "random outsiders on the internet": To write "correct code" or code at the "strategic programming" level, the latter needs to spend a lot of time and effort to deepen their understanding of the project. Unfortunately, most contributors do not possess this level of open-source spirit or the objective conditions.

Open-source project maintainers need to review pull requests sent by "random outsiders on the internet," and with a high probability, find that most pull requests cannot be merged directly. The easier a project attracts low-skilled developers, the more likely it is to encounter such pull requests. Whether it's guiding external contributors to rewrite code to make it mergeable, or the maintainers personally stepping in to rewrite the code, both require an investment of time and effort. Communication and feedback loops built on open-source principles are usually extremely inefficient, so much so that often the effort invested doesn't match the return, and maintainers deserve to spend their time in more efficient places.

Differences between the goals of external contributors and the development team are a common phenomenon, and many projects therefore do not require feature-level external contributions.

For features the development team genuinely cares about, the official implementation is often fast and good. For features they don't truly care about, feature requests will be closed by a bot after a period of inactivity, and pull requests will sink without a trace. Or worse, a hasty implementation is merged, becoming a security vulnerability in the software, recurring in subsequent versions after multiple fix attempts, ultimately destined for deletion anyway.

How to maintain grace while maintaining open-source projects? Quality answer: I don't know.

Linus Torvalds, the leader of the most influential open-source project, probably doesn't know either. Considering that the projects he manages have quite high entry barriers, to the extent that a small fry like me wouldn't even consider contributing, the abilities required for him to fulfill his duties are beyond ordinary imagination. Even in these high-barrier projects, with information having been filtered through multiple layers before reaching Linus, Linus sometimes acts harshly and cruelly, resorting to extreme sarcasm and insults when criticizing——this phenomenon is so severe that appreciating these emotional outbursts has become a kind of pleasure. A significant proportion of developers view Linus's emotionality positively, even considering it an important part of Linus's good reputation (partly because such information has greater viral potential), because a world without a technical dictator like Linus is quite easy to imagine: we wouldn't get software of the current quality, and everything would only be worse than it is now. The situation is similar for those other than managers; the open-source community is not an echo chamber, and more efficient communication methods are often toxic.

There are indeed some superhumans in the world who can remain calm in any situation and handle everything smoothly; I attribute this to talent or medication. Because if this ability were teachable, or at least attainable through practice, then it should have spread widely by now, as many people in the world would desire such emotional control. At the same time, it should be noted that these superhumans are rarely at the pinnacle of the technical field——the pinnacle of the technical field is largely occupied by toxic megalomaniacs, and the differences you see between these individuals mainly depend on their PR capabilities. This correlation leads us to a rule that cannot be proven, yet seems to objectively exist: A good open-source spirit and a good mental state are like fish and bear's paw—you can't have both.

Unless you are already at the pinnacle of your field, you will always have the opportunity to meet people who are better than you: they know more, think deeper, and perform better. The gap between the worst engineers and the best engineers cannot be simply summarized as "10x engineer."In specialized domains, accompanied by differences in experience and expertise, the gap between engineers can be far greater than tenfold.

Regarding the open-source movement alone, there's a simple way to categorize engineers with different skill levels:

However, in the open-source community, fake engineers lacking self-awareness are as ubiquitous as if to validate the Dunning-Kruger effect. These troublemakers are often also keen on earning "social credit," preferring to leave behind text lacking useful information, and contributing for the sake of contributing. Between these two types of engineers actually lies an intermediate stage, known as imposter syndrome; these individuals often don't participate in open-source projects, and are thus less harmful.

The most annoying part of open-source is when errors, problems, and misunderstandings that could be independently resolved are incorrectly shifted from fake engineers to true engineers due to skill level disparities. This is purely a waste of the latter's time. If people could first doubt themselves and act with careful prudence, then most such situations should be avoidable, even with differences in skill levels. Sadly, these qualities, which should be fundamental, are actually quite scarce, and the open-source movement lacks effective means to keep fake engineers out.

Whether you admit it or not, the concepts of free software and open-source software are essentially the same when directed at end-users——they are alternative terms for "free, secure software."

"Reward without effort" has a very strong effect on the marketing level, and most people are powerless to resist this temptation. The most typical example occurs in the gaming industry (which is also part of the software industry), where the most profitable games are so-called "free-to-play" games. Ask yourself this question: if it weren't free, would you still choose it?

For a significant proportion of "open-source projects," the "open-source" label's value as an advertisement far exceeds its value as a development model. These people either clearly realize that such projects are difficult to sustain once separated from the original development team, and merely use open-source as a marketing tool to gain an edge over competitors; or they simply use their own defined "open-source licenses," and when an "open-source project" doesn't use common licenses, it's not hard to imagine the trickery involved; some projects that were originally open-source continue to use the open-source moniker to mislead after switching to non-open-source licenses, which shows the marketing value of the term "open-source."

In the field of AI, even "open weights" are now being called "open source."Just as "source code readable" is not open source, "open weights" are not open source. The only ones who benefit from this kind of arbitrary semantic expansion are those who count on open source as an advertisement.

The ugly side of open-source software is often obscured by its superficial "freeness."There's no such thing as a free lunch; learning, understanding, utilizing, and contributing to open-source software all come with costs. Due to sparser documentation, heavy reliance on the community for debugging and support, and the common presence of code not proven in practice, open-source software often incurs unexpected costs. When you decide to rely on an open-source project, you are already bearing these costs.

The only free part of open-source software lies in the self-enslavement of maintainers driven by ideals and a sense of mission, which can easily lead to a greater collapse. An open-source software that currently functions well doesn't mean it will continue to function well in the future. Maintainers might get tired, give up, lose their ability to maintain, be incompetent, or even just have a sudden fit of madness and decide to destroy an otherwise good project. Therefore, using open-source software not only has costs but also entails risks. Commercial software, due to obvious profit motives, ironically offers more guarantees than open-source software.

"But open-source maintainers don't owe you anything!"——I hope you can still say that confidently when you suffer losses due to supply chain attacks and security vulnerabilities. Even if it's just a handout of porridge, urinating in it is unforgivable. People's blind trust and misuse of open-source software create too many opportunities to "urinate in the porridge,"leading to any software using external dependencies potentially accidentally and indirectly introducing problematic dependencies, thus harming everyone downstream in the dependency chain. This crisis of trust fundamentally increases the cost for everyone to continue using open-source software; in the end, everything that was originally light will be shackled by the security posturing of some "problem solvers" who appear out of nowhere.

The misuse of LLMs has caused the inherent problems of FOSS to completely and centrally erupt. If previous open-source software still retained some utility value, today's open-source software has completely lost this value: the cost of judging an author's skill level and understanding of the problem domain through code has become too high. Especially code released after November 2025, it is no longer worth a single second of serious attention; only by treating all of it as garbage can there be any efficiency.

In my opinion, FOSS is already dead in all but name. The community's only way out is to create a new brand, uniting those who still respect code quality under a new banner—and this is contingent on these individuals being able to overcome the new generation of worse is better brought about by LLM programming.

Until LLMs collapse due to new training data consisting only of garbage, I believe the FOSS community has no chance of recovery. The best choice they can make is to acknowledge the value of LLM-generated code, then pretend everything is still fine, and finally perish in silence and suffocation like the Soviet Union.