4 ms·

Not only that, but also the concept of open-source development is not the panacea we believe it to be. Bear with me. Software is extremely complex, even if it

by sph 3y ago

Not only that, but also the concept of open-source development is not the panacea we believe it to be. Bear with me. Software is extremely complex, even if it is open-source, no one except the original developers and very dedicated people will attempt to patch the myriad of issues and bugs they encounter daily. And even if we do spend the time to track down and fix a bug, there's a political and diplomatic game to convince the maintainers to incorporate your fix. It is not uncommon for a PR to just sit, unreviewed, for years. Open-source does not and will never scale, because software is orders of magnitude too complex. Outside of software, this problem is lessened because maintainership is distributed: if your car engine breaks, you do not depend on your manufacturer to have enough time and energy to fix it. There are thousands of licensed garages that can do it for you. And, not least, the real world is much simpler than any piece of software, which is effectively completely ad-hoc: knowing how Chrome works will not help you fix this Firefox issue, whereas if you can fix the carburettor on a Honda car, you probably can do the same on a FIAT. Open-source/distributed development and bug fixing worked much better when computers had 64 kB of RAM and programs no more than 10 pages long. EDIT TO CLARIFY: I'm not talking of open-source vs commercial, or other types of governance. I'm talking more abstractly about the fact that having source available and open contributions does not noticeably increase the amount of bugs fixed. This comment is about software complexity and logistics of distributed bugfixing.

nine_k 3y ago
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.
- jlkuester7 3y ago
  > 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!
  - nine_k 3y ago
    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. It's like a Honda Civic vs some Jaguar.
  - chongli 3y ago
    Your analogy breaks down pretty fast, though 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?
    - lelanthran 3y ago
      > Your analogy breaks down pretty fast, though > 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.
msla 3y ago
All of your arguments work much better in favor of Open Source and against closed-source. After all, in Open Source, maintainership can be distributed, but a single closed-source shop is much more likely to simply declare bug bankruptcy and refuse to even consider a fix, at which point absolutely nobody else can do it.
- sph 3y ago
  I haven't mentioned anything about closed-source development. I'm talking about software complexity here. I've updated my comment to clarify.
  - msla 3y ago
    Still: > And even if we do spend the time to track down and fix a bug, there's a political and diplomatic game to convince the maintainers to incorporate your fix. That's why forking is one of the Four Freedoms. It's written into the licenses. Granted that you need to be dedicated to even attempt to fix complex software. However, Open Source can draw from a larger pool of potential talent, and it's more likely that someone out there will care than someone in a company. What's that saying? "If you're one in a million, there's three of you in New York."? > And, not least, the real world is much simpler than any piece of software, which is effectively completely ad-hoc: knowing how Chrome works will not help you fix this Firefox issue, whereas if you can fix the carburettor on a Honda car, you probably can do the same on a FIAT. Aside from the difficulty of finding a carburetor on a modern car, this is about software complexity, not Open Source/closed-source per se. Fixing problems in a badly-architectured codebase is always difficult, time-consuming, and likely to introduce more bugs. Closed source doesn't make it any better.
    - sph 3y ago
      I have never said that closed source makes it better. I don't know how to make that more clear. You're focusing too much on politics, I'm focusing on Stallman wanting the source code of his printer to be available, so he could change it to better suit his needs. I'm just saying that in 2023 even if your printer is open-source, ain't nobody got time to dive into hundreds of thousands of line of code to change it.
itsoktocry 3y ago
>Open-source does not and will never scale, because software is orders of magnitude too complex But there are examples of long-time open source projects all over the place. This sounds like an argument for open source. If you work for a for-profit company you face two different problems: overnight the company can disappear, and the IP is lost/locked forever; problems are only ever fixed if there's a profit incentive. That works, a lot, but it's not perfect either.
- sph 3y ago
  Mind you I'm not talking of open-source vs commercial, or other types of governance. I'm talking more abstractly about the fact that having source available and open contributions does not noticeably increase the amount of bugs fixed. It's a discussion about software complexity and logistics of distributed bugfixing, not organisational.
  - riwsky 3y ago
    You said “does not noticeably increase”; you need a reference point for “increase”. If you’re not comparing open source to other types of governance, then what are you comparing it to?
otteromkram 3y ago
If a PR is just chilling for years, couldn't a user just keep the updated fork/clone separate and periodically update it from the remote master (trigger warning, lol) branch?
- sph 3y ago
  This only works in theory, because it is obvious it does not work in practice at any scale. What if tomorrow Firefox does a major code refactor and your patch breaks? Would you be able to fix and rewrite it in a reasonable amount of time (i.e. hours) with no knowledge, experience and insight into Firefox's development process? Only full-time Firefox devs can keep an updated fork with their patches, or people paid to do so. That's the point. It's such a massive effort you can do only where and when strictly necessary. There are hundreds open-source project I interact with every single day.
  - The_Colonel 3y ago
    Same as with cars, you can use your mod in the car you have, but can't expect to be compatible with new models.
guappa 3y ago
> if your car engine breaks, you do not depend on your manufacturer to have enough time and energy to fix it If it's a design problem rather than the parts just wearing down… unless it is life threatening on a large scale, it just won't be taken care of.
pmontra 3y ago
Cars analogies don't go far this time. If a mirror breaks, I replace it with another mirror, but my car never changes its features overnight. My Thunderbird updated to version 115 yesterday. I fiddled with settings to bring it back to as close as possible to its previous UI but I could do nothing about the incompatibility with an addon that lets decide how to order folders and subfolders [1] As a partial workaround I started using favorites but overall v 115 is broken and can't be repaired easily. My car is still doing what it was doing last week. [1] https://github.com/protz/Manually-Sort-Folders/issues/199 https://github.com/protz/Manually-Sort-Folders/issues/199
- Kye 3y ago
  >> "but my car never changes its features overnight." It's been a long time since I've had a new car, but from the sound of it, cars with stable feature sets are on the way toward history. Everything is fly-by-wire now, and features are increasingly implemented through software exposed through a touch screen.
  - Shorel 3y ago
    This is because software is creeping inside the cars. It is not because cars have an inherently changeable feature set.
    - Kye 3y ago
      They do increasingly have an inherently changeable feature set. That's the point.
- ncallaway 3y ago
  Does the previous version no longer run? Can it not still be installed?
  - pmontra 3y ago
    Probably, but I'm afraid it will break when it gets too distant from the system libraries. It's not that I need new features, I could probably use Thunderbird from 20 years ago and notice only because of the look of the UI.

by sph 3y ago

nine_k 3y ago

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.

jlkuester7 3y ago
> 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!
- nine_k 3y ago
  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. It's like a Honda Civic vs some Jaguar.
- chongli 3y ago
  Your analogy breaks down pretty fast, though 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?
  - lelanthran 3y ago
    > Your analogy breaks down pretty fast, though > 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.

msla 3y ago

All of your arguments work much better in favor of Open Source and against closed-source. After all, in Open Source, maintainership can be distributed, but a single closed-source shop is much more likely to simply declare bug bankruptcy and refuse to even consider a fix, at which point absolutely nobody else can do it.

sph 3y ago
I haven't mentioned anything about closed-source development. I'm talking about software complexity here. I've updated my comment to clarify.
- msla 3y ago
  Still: > And even if we do spend the time to track down and fix a bug, there's a political and diplomatic game to convince the maintainers to incorporate your fix. That's why forking is one of the Four Freedoms. It's written into the licenses. Granted that you need to be dedicated to even attempt to fix complex software. However, Open Source can draw from a larger pool of potential talent, and it's more likely that someone out there will care than someone in a company. What's that saying? "If you're one in a million, there's three of you in New York."? > And, not least, the real world is much simpler than any piece of software, which is effectively completely ad-hoc: knowing how Chrome works will not help you fix this Firefox issue, whereas if you can fix the carburettor on a Honda car, you probably can do the same on a FIAT. Aside from the difficulty of finding a carburetor on a modern car, this is about software complexity, not Open Source/closed-source per se. Fixing problems in a badly-architectured codebase is always difficult, time-consuming, and likely to introduce more bugs. Closed source doesn't make it any better.
  - sph 3y ago
    I have never said that closed source makes it better. I don't know how to make that more clear. You're focusing too much on politics, I'm focusing on Stallman wanting the source code of his printer to be available, so he could change it to better suit his needs. I'm just saying that in 2023 even if your printer is open-source, ain't nobody got time to dive into hundreds of thousands of line of code to change it.

itsoktocry 3y ago

>Open-source does not and will never scale, because software is orders of magnitude too complex But there are examples of long-time open source projects all over the place. This sounds like an argument for open source. If you work for a for-profit company you face two different problems: overnight the company can disappear, and the IP is lost/locked forever; problems are only ever fixed if there's a profit incentive. That works, a lot, but it's not perfect either.

sph 3y ago
Mind you I'm not talking of open-source vs commercial, or other types of governance. I'm talking more abstractly about the fact that having source available and open contributions does not noticeably increase the amount of bugs fixed. It's a discussion about software complexity and logistics of distributed bugfixing, not organisational.
- riwsky 3y ago
  You said “does not noticeably increase”; you need a reference point for “increase”. If you’re not comparing open source to other types of governance, then what are you comparing it to?

otteromkram 3y ago

If a PR is just chilling for years, couldn't a user just keep the updated fork/clone separate and periodically update it from the remote master (trigger warning, lol) branch?

sph 3y ago
This only works in theory, because it is obvious it does not work in practice at any scale. What if tomorrow Firefox does a major code refactor and your patch breaks? Would you be able to fix and rewrite it in a reasonable amount of time (i.e. hours) with no knowledge, experience and insight into Firefox's development process? Only full-time Firefox devs can keep an updated fork with their patches, or people paid to do so. That's the point. It's such a massive effort you can do only where and when strictly necessary. There are hundreds open-source project I interact with every single day.
- The_Colonel 3y ago
  Same as with cars, you can use your mod in the car you have, but can't expect to be compatible with new models.

guappa 3y ago

> if your car engine breaks, you do not depend on your manufacturer to have enough time and energy to fix it If it's a design problem rather than the parts just wearing down… unless it is life threatening on a large scale, it just won't be taken care of.

pmontra 3y ago

Cars analogies don't go far this time. If a mirror breaks, I replace it with another mirror, but my car never changes its features overnight. My Thunderbird updated to version 115 yesterday. I fiddled with settings to bring it back to as close as possible to its previous UI but I could do nothing about the incompatibility with an addon that lets decide how to order folders and subfolders [1] As a partial workaround I started using favorites but overall v 115 is broken and can't be repaired easily. My car is still doing what it was doing last week. [1] https://github.com/protz/Manually-Sort-Folders/issues/199 https://github.com/protz/Manually-Sort-Folders/issues/199

Kye 3y ago
>> "but my car never changes its features overnight." It's been a long time since I've had a new car, but from the sound of it, cars with stable feature sets are on the way toward history. Everything is fly-by-wire now, and features are increasingly implemented through software exposed through a touch screen.
- Shorel 3y ago
  This is because software is creeping inside the cars. It is not because cars have an inherently changeable feature set.
  - Kye 3y ago
    They do increasingly have an inherently changeable feature set. That's the point.
ncallaway 3y ago
Does the previous version no longer run? Can it not still be installed?
- pmontra 3y ago
  Probably, but I'm afraid it will break when it gets too distant from the system libraries. It's not that I need new features, I could probably use Thunderbird from 20 years ago and notice only because of the look of the UI.