06.06.21
Gemini version available ♊︎The New Generation of Vendor Lock-in, Even in ‘Open’ Clothing
Summary: Very large and increasingly monolithic projects (lack of modularity, constant changes everywhere) pose a threat to some of the Four Freedoms; while in theory it’s possible to control all the code in practice it’s becoming infeasible and very frequent ‘stable’ releases make that even harder, quite likely by intention
WE NEED to talk about an issue that more and more people have spoken about in recent years. It’s not a case of “trolling” or “bashing”; there are technically legitimate concerns therein.
We’ve long written about feature churn, too frequent a release cycle, OSPS and all that jazz. In a nutshell, for those who don’t know the basics, there are some projects that call themselves “Open Source” but are very much akin to “Proprietary Software” (the “PS” in “OSPS”). Chrome (or Chromium for openwashing’s sake) is one example and systemd is another. Linux is also released very often (RC every week, typically late on Sunday, and a final release every 6-8 weeks), it’s extremely large (the same is true for Chrome and systemd, which had over 36,000 files last year), so prospects of forking are slim to none. Even just compiling takes ages and much skill. It would take a massive scandal to induce a reorganisation large enough for momentum (like Oracle buying projects it has no intention of properly maintaining, hence LibreOffice exists). The benefits espoused in relation to Free software are mostly obsoleted, except if you want to remove some malicious feature and repeat for each release cycle. Mozilla Firefox with its version inflation (they used to release infrequently and test more extensively before final releases) is basically mimicking what Chrome is doing; recently, Google further increased the Chrome release frequency and further added restrictions (such as access to Google (dis)services) to discourage derivatives, forks, etc. Who didn’t see that coming?
“Recently, as in last week, Richard Stallman alluded to Rust as moving to fast. He said it would help to fork or branch out Rust (maybe call it “crust” to avoid trademark-related restrictions), then maintain that instead. So it seems clear Stallman is at least vaguely aware of those things.”If this is the best we have, what level of freedom are we truly enjoying/exercising at the level of studying, modifying, and redistributing code? After all, most of us need a “Big Browser” (at least sometimes, e.g. for online banking) and a kernel with extensive hardware support. How many of us can feasibly change those and keep up with new versions/releases? How many projects can do so? Not even Gentoo or Debian have enough developers to study and garden millions of lines of such code. Not without a salary and full-time job.
Free software will need to cope with or handle this issue. A good start would be at least talking about those sorts of issues. Without talking about them there will be no widespread recognition. Recently, as in last week, Richard Stallman alluded to Rust as moving to fast. He said it would help to fork or branch out Rust (maybe call it “crust” to avoid trademark-related restrictions), then maintain that instead. So it seems clear Stallman is at least vaguely aware of those things. This talk is not online yet, but certainly it will be some time soon (I watched it live, but exact quotes require something other than a livestream). There are several other issues with Rust (we covered some before), but they’re a footnote in the context of what Drew DeVault wrote a few months back. █
ᶃ Gemini Space
This post is also available in 
Content is available under CC-BY-SA