The problem is also in (lack of) modularity that makes fixing small things disproportionately onerous.
If ypur car's engine breaks, it's usually petty localized. Most of the time it's enough to open the hold and remove a few small parts to reach it. If your stoplight breaks, again, the scope is pretty local.
To fix or to even diagnose the issue with a tooltip in Firefox, you have to rebuild it whole, and it's about as involved and long as rebuilding a car. And even though Mozilla invented Rust to make Firefox development easier, it's far, far from just saying `cargo build`.
This raises the barrier to entry quite noticeably, even if you are an experienced software mechanic but never worked in a Mozilla-oriented garage. But even if you fixed the issue on your platform, you now have to test that the fix did not introduce a regression on at least two other major platforms (or more, depending on the component).
No wonder it's much easier to hack on smaller projects, or on projects written in JS, Python, elisp, you name it.
> If ypur car's engine breaks, it's usually petty localized
I think your point here is that typically with software, changing one line of code means that you need to rebuild the entire executable.
Your analogy breaks down pretty fast, though. While fixing one thing on a car _never_ requires totally rebuilding the thing from scratch, there are still tons of interlocking dependencies and architectural challenges that can impact the time/complexity required to change out a part. (See the effort required in most vehicles to change simple wear items such as a timing chain or a water pump....)
In my experience of software, most of the "rebuild pain" is self-inflicted by the project maintainers (poor automation/containerization of the build process). Software has the luxury of abstraction and automation that can reduce the build effort required from an individual in ways that a mechanic could only dream of!
I agree: the pain of rebuilding characteristic to large software is not inherent to software in general. Software can be highly modular, allowing for fast and flexible changes of many important parts. You don't have to rebuild a Linux or Windows kernel to update a driver; usually you don't even need to reboot it.
But Firefox specifically, and a few other old, large, and highly multiplatform projects had more important things to do than to make building them easy, and in doing so made contributing to them harder.
Yeah this analogy doesn't make sense to me. My dad has seen head gaskets fail on multiple previous cars of his. Each time, the labour cost to replace the head gasket (a fairly cheap part) exceeded the value of the car, so he sold it to a scrapyard instead of ordering the repair.
Software does not have anything remotely analogous to this. One small bug somehow requiring you to throw out the entire codebase and start over from scratch?
> Yeah this analogy doesn't make sense to me. My dad has seen head gaskets fail on multiple previous cars of his. Each time, the labour cost to replace the head gasket (a fairly cheap part) exceeded the value of the car, so he sold it to a scrapyard instead of ordering the repair.
The key word there is labour. I change my own headgaskets.
Giving up a Sunday (which is not worth money to me) to replace the head gasket is analogous to me giving up a Sunday to track down and fix a software annoyance to me (yes, I've committed fixes to a few open source projects).
So the analogy does sorta fit, for opensource anyway.
Among other things, it allocates an IP address to listen on, and both depends on and is a dependency of a decades-old standardized file that other stuff relies on.
That means it has a circular dependency with network interface bring up, and with external DNS server configuration. The article goes on for a dozen more pages explaining other issues like this.
Yes this is a major problem. I've been thinking hard about this space, the future of software engineering, and the conceptual similarity between the idea of containers the world is coalescing around, and Alan Kay's model of object orientation.
Our issue today is that programming is too low level. We're still figuring out the standardised atomic components software of the future can be built from, but in the meantime we're rewriting the same concept, ideas and subsystem in every project. Contributing to a new project is akin to learning a new language, a new culture.
Industry wise recalls are very much a thing, and nearly bankrupt companies in the regular. On car engines. Those are the ‘programming’ (aka design) bugs from the manufacturer.
The difference here is rather different than you’re presenting - individual cars/trucks are so expensive that one off fixes (replacing the equivalent of RAM, or a CPU, or rigging some weird combination of drives/accessories) even on really old individual machines is economic. That’s what those repair shops are doing.
also changing anything physical on a car (or even having a human of known level of knowledge verifiably look at it) is expensive and difficult to scale. And unlike computers, cars/trucks are 90% or more physical.
And while a single truck or car breaking down is localized, so is a typical PC, tablet or phone.
Computers are typically so cheap and the technology is progressing so rapidly, it’s rarely economically worthwhile to do that kind of thing. Occasionally, yes. But Certainly not at the scale cars/trucks are.
Having someone do custom work to fix the design (aka ‘fix the programming’) is relatively rare, and more of a hobbyist thing. But does happen (project cars, open source hobby projects). Though exceptions abound for simple fixes. (Which can also typically be done for individual computers through normal configuration/customization settings, or some software).
Cars and trucks are very complicated, just in ways that a techie may not recognize. Bolt patterns. Offsets. Metric vs SAE. Vacuum line levels. Metallurgy. Heat treatments. Tolerances. Hell even DC voltage levels can come into play sometimes (12v vs 24v). Vehicle communication bus type (CAN vs something else).
And working in physical parts is extremely expensive, error prone, and slow.
If ypur car's engine breaks, it's usually petty localized. Most of the time it's enough to open the hold and remove a few small parts to reach it. If your stoplight breaks, again, the scope is pretty local.
To fix or to even diagnose the issue with a tooltip in Firefox, you have to rebuild it whole, and it's about as involved and long as rebuilding a car. And even though Mozilla invented Rust to make Firefox development easier, it's far, far from just saying `cargo build`.
This raises the barrier to entry quite noticeably, even if you are an experienced software mechanic but never worked in a Mozilla-oriented garage. But even if you fixed the issue on your platform, you now have to test that the fix did not introduce a regression on at least two other major platforms (or more, depending on the component).
No wonder it's much easier to hack on smaller projects, or on projects written in JS, Python, elisp, you name it.