The Free Software movement never escaped from its origins: the early ‘80s MIT AI Lab. Two things were true in this environment:

• Back when most computers had tens of KiBs of RAM and 1 MiB was a huge amount, programs were simple. Very few programs were so complex that one person could not completely understand them.
• The AI Lab was full of some of the most talented programmers in the world.

This meant that the only obstacles for these people being able to fix bugs and add features to any program were access to the source code and the legal rights to modify it. Once you have those, any program was understandable by that group and they could modify it however they wished.

For the next 40 years, the FSF focused on these two things. The world around them changed. These two prerequisites were never enough for most people (what do 90% of computer users do if you give them even a modest 10,000 line C codebase and tell them they can change it however they like?) and now they aren’t enough even for competent programmers.

When Linus says ‘fork it’ to folks who don’t want LLM-extruded code in their kernel, he knows full well that it is almost impossible to fork a 40 MLoC C (and Rust now) codebase that averages more than one CVE per day and have something useful.

The Free Software movement is struggling now because it obsessed over licenses, which was never a path that would succeed, and ignored the hard problems:

• How do you design environments that enable end users to modify their software?
• How do you engineer software so that it is cheap and easy for a random user to maintain a fork that meets their specific needs?
• How do you foster communities where people want to share improvements, so forks don’t proliferate even when it’s easy?
• How do you create an environment where everyone sees the benefits of user-modifiable code to such a degree that trying to sell anything that doesn’t come with these rights is commercially impossible?

Instead of tackling any of these problems, they created more complex and restrictive GPL variants. And well-paid lawyers found loopholes in them that allowed corporations to keep doing what they wanted (and even pick licenses like AGPLv3 to control ecosystems, because they give the copyright owners so many more rights than everyone else that it’s hard for anyone else to compete). They said ‘don’t worry about the complexity of the licenses, you only need to understand the legal details if you’re creating and distributing derived works’ while completely forgetting that making it possible for anyone to create and distribute modified versions of the programs was the entire point of the Free Software movement.

@david_chisnall TL;dr — Linux has gotten too big.

Any pretense of a security focus is out the window now.

But this crisis isn't all to be placed at the feet of GenAI use: It demonstrates how the monolithic Linux architecture was wrong to begin with.

The future is already arriving in the form of small, trustworthy microkernels and hypervisors that can isolate risk and allow users to retain control of basic resources (the computers) even under heavy attack.

@david_chisnall

while completely forgetting that making it possible for anyone to create and distribute modified versions of the programs was the entire point of the Free Software movement.

An oft-ruminated point that IMO they (we) never forgot. It was always about acknowledging the dominance of copyright and trying to use it to provide breathing room for non-profit collaboration.

@toast

Microkernel designs give you some tools, but a microkernel that includes a large set of servers, all developed together, all with tightly bound interdependencies, is not much more approachable than a monolithic kernel with loadable modules.

I’m more inclined to look from the other direction. Look at plugin and expansion APIs in proprietary software and ask ‘what can these not do because the vendor doesn’t want to expose their implementation or enable competition?’ And then try to build things that enable all of those things.

@toast

As somebody starting to learn how to code and navigate the Linux command line, while there a lot of resources, they all assume a baseline level of understanding that I don't have. It can be hard to find some of that really kind of foundational understanding of how this all works.

I'm currently learning C# as my first language, but thinking about switching C because I need to understand how all of this is actually working "behind the scenes," as it were.

@toast @david_chisnall
So was Andrew Tanenbaum right after all?

Not really. However Linus should not have used C, already obsolete and known long before 1990-1993 that memory management, strings and array bounds were huge issues.

@novenary @toast

LLVM has the same problem. APIs change rapidly and so people are massively incentivised to get things into the LLVM project tree, even if they aren’t a good fit, because then updating them to work with new APIs isn’t their problem anymore.

This is one of the reasons I argued against the monorepo move. The strength of LLVM is the broader ecosystem that uses it. Projects like Mesa and rustc would make no sense to bring into the monorepo, but as a result they become second-class citizens. I wanted clang to be on parity with them: if you change an LLVM API that would break clang, it’s not your responsibility to fix clang, it’s your responsibility to do graceful deprecation and communicate the change. I was overruled because the biggest contributors to LLVM work in environments where these are not important concerns.

@novenary @toast @david_chisnall ghc’s llvm codegen doesn’t bother with the api and just calls llc directly

i wonder if that could help

@charlotte @novenary @toast

No, it's worse. Because that means you need to produce something that llc can consume. That's either bitcode, which has some backwards compatibility guarantees (but is a binary format) or the text serialisation. The text serialisation changes between minor revisions.

The upgrade support from bitcode doesn't always work across more than one or two revisions, the old semantics are upgraded to the new ones on a best-effort basis. If you use the APIs, at least you get compile failures when things change. If you emit bitcode, you lose that feedback.

@david_chisnall @novenary @toast

i am not sure the text serialization assessment is entirely accurate at this point. i had the mispleasure of compiling ghc 9.6.7 with an unregistered build of ghc 9.4.8 with no native code generator. nominally ghc 9.4.8 supports LLVM versions 10 to 13 but i only got LLVM 18 and newer. and it built and ran just fine with either llvm 20 or 21, not sure

My guess is that there is no guarantee from llvm that this is the case, or that GHC goes through great lengths to ensure such broad compatibility, but that seems way more flexible than what rust does

@charlotte @novenary @toast

My guess is that there is no guarantee from llvm that this is the case, or that GHC goes through great lengths to ensure such broad compatibility, but that seems way more flexible than what rust does

There isn't, and they've broken it in the past. Most recently, when pointers removed pointee types, the bitcode had auto-upgrade that stripped those and mapped them to untyped pointers, the text serialisation was just rejected.

@david_chisnall @novenary @toast Well at least it is rejected

it’s not a stable format by any means i guess but at least more stable than the API? i think rust only ever compiles with a small handful of LLVM versions due to api changes

@charlotte @novenary @toast

It's sometimes rejected. There are subtler cases where attributes become necessary for specific behaviour. The bitcode is versioned and so will add the attributes. The APIs will typically change to require an enum with the attributes, possibly with a default value that's the old behaviour. The text serialisation will just generate subtly different code.

The stance from the LLVM project on things that emit the text serialisation has always been: don't, it's not stable and we don't care if we break you in obvious or subtle ways, it exists solely for debugging. And people keep doing it.

@david_chisnall

There’s also a massive and relatively unaddressed social problem in the free software movement. Many people there don’t understand:

• People won’t like you if you’re mean to them

• No amount of being good at software will change that

There are two major consequences of this. The first is that, for free software to succeed, projects that require teamwork are necessary. These are made much harder when they’re helmed by someone who’s an asshole, even if they’re competent. I would go so far as saying that being an asshole makes you incompetent at teamwork.

The second is that if people can’t get over themselves enough to teach noobs, you’ll never get the reach to build communities where people want to share improvements, or to built an environment where people see the benefits of free software.

@david_chisnall

Interesting perspective. So how do you make it possible for anyone to modify the software? If average users never had the know-how to do this, and programs even getting too big for even experienced programmers to easily understand and modify, what is even the point of a license that allows it?

Ultimately it's not just about the legal permission to modify it, but about the physical ability to do it. The skill, knowledge and expertise, that most users lack. Often I wish some application was put together differently, but I'm not going to put in the time to learn and understand that code base.

So in light of Linus' announcement that Linux is not going to be anti-AI, I now find myself wondering if AI could be the solution to it. Dangerous of course, to have users vibe-coding their own modifications. But now I'm wondering if open source projects could include the tools and context files to make this viable.

AI is not popular among the whole open source community, but now I find myself wondering if it could turn out to be the missing key to enable users to take more control over their system. Not sure what to think about it, but the goal is interesting.

@mcv

Something I observed over twenty years ago:

There are a bunch of proprietary programs where more end users modify them than most Free Software things. MS Office’s VBScript wasn’t used by everyone, but it was used by a lot of people and there was a thriving ecosystem of people extending Office and sharing or selling their extensions.

Windows 3 came with a program called Recorder, which could create macros by just doing a thing with it running. It would record the events that were sent and replay them. It had a bunch of problems. It was basically only usable if you maximised windows because it didn’t translate events into the target window’s coordinate space (or track new windows), but people used it for lightweight automation. Coupling something like that with a Scratch-like interface so you can write simple control flow around actions recorded from the UI would be useful, but is much less valuable if apps are siloes (which proprietary software makes them because an app is a unit of revenue and a unit of lock in).

The most popular programming language in the world is the Calc language in MS Excel, which has a billion users. Smalltalk made it easy to visually inspect objects in the system and modify them.

There are lots of systems to learn from.

@david_chisnall "This meant that the only obstacles for these people being able to fix bugs and add features to any program were access to the source code and the legal rights to modify it." This phrase is why this doesn't work at all. Not anyone could modify it, because modifying it and having it be useful requires knowing how to code. Not everyone wants or desires to know code just to get their program to do what they want.

@Newhereish Yes, that is my point. MIT computer scientists are not a representative subset of computer users in this regard.

@david_chisnall I think I need to explain what I was trying to say a bit differently. That the conditions don't work right off the bat means that the concept was doomed from the start, it didn't become doomed from development or change, it wasn't going to work in the first place.

@Newhereish

I think the goals are laudable (and ones I agree with), but the strategy is skewed by the unstated assumptions. Once you state those assumptions, it becomes a lot more obvious why the strategy isn't working.

@david_chisnall I definitely agree with this analysis, but it is worth saying that the items on that list are all really hard problems.

The free software movement (GNUish and otherwise) has preferred to put work into a "free version of X" not something better than X. But surely a large part of the explanation is that harnessing collective effort is hugely easier if you have a clear specification of the thing to build ("it should work like X").

@david_chisnall I'm
reminded of Bret Victor's "The Future of Programming" when he lampoons what a terrible idea APIs are. I agree, and I even did a PhD attempting to address some of the problems with APIs... but must admit the problems are still there.

@david_chisnall The kind of major reimagining of programming around enabling these things, e.g. even to get something like Smalltalk afloat in enough people's minds, seems intractable by any obvious approach. (That's why I am trying to find ways to sneak it in to the systems that are already deployed at large scale....)

@david_chisnall And perhaps ironically, glue code and complexity reduction are for me among the more compelling and perhaps-not-so-dangerous applications of LLMs, compared to "generating lots of new stuff quickly"... yet the latter seems to be what people are hooked on.

@stephenrkell

The free software movement (GNUish and otherwise) has preferred to put work into a "free version of X" not something better than X.

I think this approach is doomed to failure because successful proprietary programs are successful because the program structure is a good fit for proprietary software. It's a variation of Conway's Law: your program embodies not just your org chart, but the economic system in which it was successful. For example, proprietary software has an evolutionary advantage if:

• It is hard to reimplement.
• It has file formats that are hard to integrate with.
• It subsumes functionality of other programs so users spend more time there.
• It defines extension points that allow third parties to make it better, but not replace it.

If a proprietary program has these properties and succeeds, a Free Software program that also embodies these ideas will struggle to compete. The only benefit that it will have over the proprietary equivalent is price.

@novenary @charlotte @toast @david_chisnall i recently also found out that jellyfin also vendor its own ffmpeg :)

@flammableengineering @david_chisnall related: the reason i work on FOSS is to reduce misery. principally my own (a lot of software, free and not, is intensely misery-inducing), but that of others just as well

this is essentially a social task. yes, there is technology involved, as leverage; but both the motivation and the means are social in nature

@stephenrkell @david_chisnall They may be 'really hard problems', but they've also had 40 years, by which point I'd say it's reasonable to conclude that the reason they haven't been addressed *isn't* that they're hard problems, but rather that the interest has not been there.

@joepie91 @david_chisnall I think you're right, although it seems worth probing what sort of "interest" might be lacking. "Funding" is one answer (these are things the military-industrial complex increasingly declines to get behind); "shared vision" is another (why FOSS hasn't filled the gap). Among programmers at large, I'd say the intellectual interest is there (... but I made the mistake of starting my research career based on such intellectual interest, not a well-funded research programme).

@stephenrkell Honestly, the source of the issue seems quite obvious: for as long as I can remember, the Free Software movement has been absolutely steeped in dogma. And I don't mean "ideological insistence on a certain goal", but rather that it has come to redefine the envisioned solution (licensing) as the goal itself.

The underlying mechanisms behind that phenomenon are also not hard to find; there is a general disregard for other people and their emotional experiences in FOSS circles, with everything instead centering around the technology and, usually, the personal preferences of the author(s) of things. The patronizing attitudes around UX are a commonly-seen outgrowth of that.

It's also the same reason that every time human rights, bigotry, etc. come up in the context of a FOSS project, there's a good chance that you'll be told to "keep politics out of it". There is no (desire to) recognize that FOSS itself is political, and the only way to reconcile that with the movement's shape is to redefine the movement as being *about* the licenses, because that feels values-neutral and doesn't require people to engage with and reflect on the underlying politics.

And if you consider these things, and then look back to those four hard problems that @david_chisnall raised, you'll notice that all of them revolve around ideological questions of agency and social dynamics, and are thus political in exactly the way that people in FOSS circles frequently do not *want* to engage with. As doing so would require them to come to some uncomfortable conclusions about their own view of the world, like their idea of 'meritocracy'.

Finally: you mention 'intellectual interest', but that was never the part that's missing. People endlessly argue about free vs. open for a reason. The part that's missing is empathy.