IIRC, they said something like “we intend to open source it, but because of licensing and other IP concerns, we need to be careful how we structure the codebase, so we’re waiting until active development levels off”.

The “it’s just a tool” (with optional add-on “what matters is how you use it”) thought-terminating cliche makes me put my face in my hands a little bit deeper every time I see it.

Daily life in 2026 would be completely unrecognizable to a person from 5,000 years ago, and the difference is not just how we use our tools. The production, existence, and proliferation of the tools shape what is easy or hard, or even what is possible or impossible.

To think that you can reshape the contours of the decision-making terrain and that has no effect on what people do, or how they think of who they are… you’d have to accept that someone in the bronze age could just wake up one day and decide to be a telecommuting web developer on HRT and Ozempic.

To be fair to the original commenter: They did bring up copyright in the context of “what makes this a different kind of tool”, which is an empirical claim and not a normative one.

I can say a little bit on tooling: We’ve experimented with Chromatic. We’re on a mobile app though, so the idea with Chromatic is to render via react-native-web, which has its own issues, so the ROI is such that we haven’t taken it beyond POC. Seems nice though, and probably more in line with your domain.

But for org strategy, I take it you’re on a much bigger team than I ever have been. (10 people max for me) So I can’t speak to personal experience there, but what I will say is that being able to control your entire env top to bottom is crucial for pretty much anything where you want high fidelity testing.

Like, being able to set up an env that allows you to play with stuff like externally-sourced ads and CDN caches in a space that’s private and temporary. No small feat, but that’s pretty much what you have to do if you want to catch those Rube Goldberg style failures before prod.

It depends how much it’s worth it to you, to have a test env that’s 99.999% realistic. As with anything, the first two 9s are the cheapest.

Meanwhile at work we just had a training course that specifically said doing “opt out” instead of “opt in” violates the principle of informed consent.

I did it to invite collaboration and connect with other developers with similar interests. FOSS is more about building communities than building software, after all.

I did not anticipate that it could be (legally) used to dismantle the kinds of communities I wanted to build. (I did anticipate that it could be illegally used to that end, but historically that has tended to cause a Streisand Effect, so that risk seemed worth it.)

I don’t think there’s anything wrong with the author sticking to the level at which he’s an expert. If everyone had to chase down the lowest possible level, we’d all be physicists (or maybe philosophers, depending on your take there).

Besides, isn’t the “materialism” portion of “dialectical materialism” about interrogating the implications of present world you find yourself in, rather than evaluating what-ifs of alternate histories?

However generative AI might have emerged differently under a different regime, this is the version that we have access to inspect and, crucially, the version we must contend with if we want to influence its future trajectory under any regime.

Edit: But I do have to agree that he is much better at diagnosing the problem than he is at prescribing the solution. That seems to be the way of things. People tend to be good at either analyzing problems in detail, or rallying people around a tractible plan of action. It’s very very very rare to see someone who is good at both. So I don’t mind it too much.

Ehhh, probably the most pragmatic option for someone in his position, but I’m not gonna take that as an even-handed analysis of AI in open source, the software industry, the economy, or civilization writ large.

There was a post earlier today that directly counters the “just a tool” trope. (And if you’re thinking “but this is Linus! What credentials could this rando possibly have?”, allow me to preface their essay+video with a note that this guy has experience at high levels in the industry and then quit the industry to get a PhD with a focus on the social impacts of software development tools.)

And Cory Doctorow has a book (and many blog posts and speaking engagements covering the same content) about the precise harms (and non-harms) of AI.

Dr. Fatima (on Youtube) also has a pretty well-rounded take.

And Baldur Bjarnason makes some good points from a cognitive science perspective, though I think he’s ultimately out over his skis quite a bit.

Can’t answer for them, but I can explain a similar situation I ran into:

Large external RAID I was using for telescoping backups with a restic cron job. Didn’t want to have it on all the time cuz it was noisy, so I put it on a smart plug and had it turn on and off as part of the job.

I really wanted a set of backup rules that worked like… “always a full snapshot of current state, plus as much of the following as will fit into the destination: daily for the past 7 days, weekly for the past 4 weeks, monthly for the rest until full” …but restic doesn’t (or didn’t) support that kind of dynamic rule set.

I tried to estimate it programmatically, but it never worked 100% and I frequently ran into out of space errors.

But of course, I never saw the actual disk usage in my day-to-day, because the RAID was only on at like 4 AM.

Agreed.

I’m also a fan of Kent Beck’s “make the change easy, then make the easy change”.

i.e. Do one PR that changes the code’s design but not its behavior, in order to make the next feature easier to implement. Then do another PR that changes just the behavior but not the design.

This way, you get earlier feedback on refactors and you keep behavior PRs small so you reduce the likelihood of the scenario where “we really need to ship this feature but it’s tied to this massive refactor that isn’t quite right”.

(Note that this is just for the case where a feature genuinely requires a refactor. If it’s just “boy-scouting”, then order shouldn’t matter but you should still keep them separate.)

I’ve seen that before. It’s a self-destructive policy.

I’m disappointed by Linux on almost a daily basis. And MacOS. And iOS. And Android.

(I haven’t used Windows in a long time, so I guess it’s the only major OS I’m not routinely disappointed by? Whoa, that’s a realization…)

But this is just what happens when you’re constantly messing with stuff.

Since “do one thing principle” is pretty abstract, I’ll give you one example of a downstream consequence.

I wanted to set up a NixOS microVM using docker sbx. Turns out, it was basically impossible (nothing is actually impossible, it just depends how much you want to modify/rebuild things).

Much of NixOS depends on systemd to manage lifecycles of this or that, but systemd only works properly if it’s the first PID, and when it runs in that mode it also wants to initialize hardware.

But the hardware is all managed by the microVM, so systemd blows up. All it needs to do is nothing, but that turns out to be very difficult to achieve.

If these were like 3 or 4 distinct utilities, there would be obvious seams where I could separate them and only activate the stuff that’s relevant to my use case. But it’s all one big ball of mud.

It’s the combination of “breaking changes on minor releases” and “disregard for … production environments”.

Can you stop releasing breaking changes on minor releases? It’s absolutely infuriating that you guys keep doing this over and over again with complete disregard for people downstream using this package in production environments.

By the time you’re deploying to production, you should already have your versions locked in, so semver does not factor into resolving dependencies for production deployments at all.

I can understand it being annoying for development processes. Like, if you have a dependabot-style tool that tests against new releases and submits PRs for them, that can definitely be a waste of time and attention if it fails frequently on patch-level updates.

But in between that “eager testing” step and a production rollout, there needs to be a moment where a human reviews the updates and signs off on updating the lockfile.

And at that moment, reading the changelog, it really doesn’t matter if it says “1.0.1: breaking changes!” or “2.0.0: breaking changes!”, because you need to be looking at the substance of the update.

The only way semver violations burn you in a prod env is if you’re YOLOing new versions out there, either by forgoing a lockfile or by merging lockfile updates without review.

Complains about improper release management.

Apparently not using lockfiles for prod.

This is not a serious developer.

Full context of the first quote:

Those who believe we’ve been in an incrementally escalating software crisis since at least 2007.

Our current software crisis – we’ve had a few – has been ramping up since the US gave up on regulation after the 2007 crash. Instead of reforming and regulating finance, the US decided to let the finance industry take over all of its industries, which hasn’t been great overall, but for software it’s meant that “quality” stopped mattering.

• Well-funded startups capture market share with subsidised products.
• Big tech is a cluster of oligopolies and monopolies.
• Internal software projects are driven by their potential effects on stock prices (“UGC! No, Web 2.0! No, blockchain! No, AI!”).
• Customer lock-in is a standard tactic.

There is little to no downside to poor software quality. The upside of doing the job well is limited compared to tactics like lock-in, dishonest subscription models, and monopolies

If his principal complaint is industry consolidation and consumer abuse, then the browser situation is not a great counterexample.

Very wise words, that will probably go unheeded.

It echoes the theory of constraints mantra of reducing WIP, because WIP itself has a cost.

That’s a carefully crafted illusion. And if you’re a power user, it won’t last long.

How so? I’m probably as power user as it gets (been using Macs since around ‘95, been splitting roughly 50/50 between Mac and Linux since around ‘06, and I love weird esoteric coding tools, so I’ll try to run some truly cursed setups) and I can’t imagine what you’re alluding to.

Preview.app

A spec that’s more than a single page rarely survives initial contact with reality.