6 ms·

We as an industry need to seriously tackle the social and market dynamics that lead to this situation. When and why has "stable" become synonymous with "unmaint

We as an industry need to seriously tackle the social and market dynamics that lead to this situation. When and why has "stable" become synonymous with "unmaintained"? Why is it that practically every attempt to build a stable abstraction layer has turned out to be significantly less stable than the layer it abstracts over?

bloppe 1y ago
At any given moment, there are 6 LTS versions of Ubuntu. Are you proposing that there should be more than that? The tradeoffs are pretty obvious. If you're maintaining a platform, and you want to innovate, you either have to deprecate old functionality or indefinitely increase your scope of responsibilities. On the other hand, if you refuse to innovate, you slide into obscurity as everyone eventually migrates to more innovative platforms. I don't want to change anything about these market and social dynamics. I like innovation
- tracker1 1y ago
  They aren't still supporting 14.04. How do you get 6? There's one every other year, and they retire one shortly after a new one comes out. They're also pretty quick to shutter non-lts release support each lts generation.
Ygg2 1y ago
> When and why has "stable" become synonymous with "unmaintained"? Because the software ecosystem is not static. People want your software to have more features, be more secure, and be more performant. So you and every one of your competitors are on an update treadmill. If you ARE standing (aka being stable) on the treadmill, you'll fall off. If you are on the treadmill you are accumulating code, features, and bug fixes, until you either get too big to maintain or a faster competitor emerges, and people flock to it. Solving this is just as easy as proving all your code is exactly as people wanted AND making sure people don't want anything more ever.
- codeflo 1y ago
  > People want your software to have more features, have fewer bugs, and not be exploited. So you and every one of your competitors are on an update treadmill. If you ARE stable, you'll probably fall off. If you are on the treadmill you are accumulating code, features, bug fixes, until you either get off or a faster competitor emerges. Runners on treadmills don't actually move forward.
  - Ygg2 1y ago
    Kinda the point of the threadmill metaphor. If you are standing on a threadmill, you will fall right off. It requires great effort to just stay at one spot.
    - BobaFloutist 1y ago
      But adding features isn't staying at the same spot.
      - Ygg2 1y ago
        Honestly. I think it is. All software exists in a kind of attract consumer/developer evolutionary race. If I assume your point is true, wouldn't everyone then just switch to Paint for all 2D picture editing? I mean it's the fastest - opens instantly on my machine vs 3-4sec for Krita/Gimp/Photoshop. But it's also bare bones. So why isn't Paint universal used by everyone? My assumption: what people want is to not waste their time. If a program is 3 seconds slower to start/edit, but saves you 45 minutes of fucking around in a less featureful editor, it's obvious which one is more expedient in the long run.
        GoblinSlayer 1y ago
        I use paint, because it starts fast so I don't waste my time. When I want complex edit, I use paint.net - because it does everything yet starts million times faster than Krita/Gimp/Photoshop. In fact paint.net 3 already had all the features in 2008, after that it was vapid churn, it's literally impossible to notice the difference.
dgoldstein0 1y ago
So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works on it, and people quit / change teams / etc, eventually the team tasked with maintaining it doesn't know how it works. At which point they may not be suited to maintaining it anymore. This effect gets accelerated when teams or individuals make their code more magical or even just more different than other code at the company, which makes it harder for new maintainers to step in. Add to this that not all code has all the test coverage and monitoring it should... It shouldn't be too surprising there's always some incentives to kill, change, or otherwise stop supporting what we shipped 5 years ago.
- codeflo 1y ago
  That's probably true, but you're describing incentives and social dynamics, not a technological problem. I notice that every other kind of infrastructure in my life that I depend upon is maintained by qualified teams, sometimes for decades, who aren't incentivized to rebuild the thing every six months.
  - BobaFloutist 1y ago
    If you're asking why software has more frequent rebuild cycles than, say, buildings, or roads, or plumbing, it's because it's way cheaper and easier, can be distributed at scale for ~free (compared to road designs which necessarily have to be backward compatible since you can't very well replace every intersection in a city simultaneously), and for all the computerification of the modern world, is largely less essential and less painful to get wrong than your average bridge or bus.
    - tracker1 1y ago
      It's like the difference between building a Bird house, Dog house, people house, mansion, large building and a sky scraper... it's different levels of planning, preparation and logistics involved. A lot of software can (or at least should) be done at the bird or dog house level... pretty easy to replace.
gjvc 1y ago
post a link to a stable repository on github on this site. watch as several people pipe up and say "last commit 2020; must be dead" source code is ascii text, and ascii text is not alive. it doesn't need to breathe, modulo dependencies, yes. but this attitude that "not active, must be dead and therefore: avoid" leads people to believing that the opposite: unproven and buggy new stuff, is always better. silly counter-example: vim from 10 years ago is just as usable for the 90% case as the latest one
- tracker1 1y ago
  I don't assume it's dead based on the last commit. I will look a little further and see where it stands. If there hasn't been a commit for a few years AND there are multiple pull requests that have been sitting unmerged for years and dozens/hundreds of really old issues... then, I'll assume it's dead, and often open another issue asking if it's dead, if there isn't one already.

bloppe 1y ago

At any given moment, there are 6 LTS versions of Ubuntu. Are you proposing that there should be more than that? The tradeoffs are pretty obvious. If you're maintaining a platform, and you want to innovate, you either have to deprecate old functionality or indefinitely increase your scope of responsibilities. On the other hand, if you refuse to innovate, you slide into obscurity as everyone eventually migrates to more innovative platforms. I don't want to change anything about these market and social dynamics. I like innovation

tracker1 1y ago
They aren't still supporting 14.04. How do you get 6? There's one every other year, and they retire one shortly after a new one comes out. They're also pretty quick to shutter non-lts release support each lts generation.

Ygg2 1y ago

> When and why has "stable" become synonymous with "unmaintained"? Because the software ecosystem is not static. People want your software to have more features, be more secure, and be more performant. So you and every one of your competitors are on an update treadmill. If you ARE standing (aka being stable) on the treadmill, you'll fall off. If you are on the treadmill you are accumulating code, features, and bug fixes, until you either get too big to maintain or a faster competitor emerges, and people flock to it. Solving this is just as easy as proving all your code is exactly as people wanted AND making sure people don't want anything more ever.

codeflo 1y ago
> People want your software to have more features, have fewer bugs, and not be exploited. So you and every one of your competitors are on an update treadmill. If you ARE stable, you'll probably fall off. If you are on the treadmill you are accumulating code, features, bug fixes, until you either get off or a faster competitor emerges. Runners on treadmills don't actually move forward.
- Ygg2 1y ago
  Kinda the point of the threadmill metaphor. If you are standing on a threadmill, you will fall right off. It requires great effort to just stay at one spot.
  - BobaFloutist 1y ago
    But adding features isn't staying at the same spot.
    - Ygg2 1y ago
      Honestly. I think it is. All software exists in a kind of attract consumer/developer evolutionary race. If I assume your point is true, wouldn't everyone then just switch to Paint for all 2D picture editing? I mean it's the fastest - opens instantly on my machine vs 3-4sec for Krita/Gimp/Photoshop. But it's also bare bones. So why isn't Paint universal used by everyone? My assumption: what people want is to not waste their time. If a program is 3 seconds slower to start/edit, but saves you 45 minutes of fucking around in a less featureful editor, it's obvious which one is more expedient in the long run.
      - GoblinSlayer 1y ago
        I use paint, because it starts fast so I don't waste my time. When I want complex edit, I use paint.net - because it does everything yet starts million times faster than Krita/Gimp/Photoshop. In fact paint.net 3 already had all the features in 2008, after that it was vapid churn, it's literally impossible to notice the difference.

dgoldstein0 1y ago

So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works on it, and people quit / change teams / etc, eventually the team tasked with maintaining it doesn't know how it works. At which point they may not be suited to maintaining it anymore. This effect gets accelerated when teams or individuals make their code more magical or even just more different than other code at the company, which makes it harder for new maintainers to step in. Add to this that not all code has all the test coverage and monitoring it should... It shouldn't be too surprising there's always some incentives to kill, change, or otherwise stop supporting what we shipped 5 years ago.

codeflo 1y ago
That's probably true, but you're describing incentives and social dynamics, not a technological problem. I notice that every other kind of infrastructure in my life that I depend upon is maintained by qualified teams, sometimes for decades, who aren't incentivized to rebuild the thing every six months.
- BobaFloutist 1y ago
  If you're asking why software has more frequent rebuild cycles than, say, buildings, or roads, or plumbing, it's because it's way cheaper and easier, can be distributed at scale for ~free (compared to road designs which necessarily have to be backward compatible since you can't very well replace every intersection in a city simultaneously), and for all the computerification of the modern world, is largely less essential and less painful to get wrong than your average bridge or bus.
  - tracker1 1y ago
    It's like the difference between building a Bird house, Dog house, people house, mansion, large building and a sky scraper... it's different levels of planning, preparation and logistics involved. A lot of software can (or at least should) be done at the bird or dog house level... pretty easy to replace.

gjvc 1y ago

post a link to a stable repository on github on this site. watch as several people pipe up and say "last commit 2020; must be dead" source code is ascii text, and ascii text is not alive. it doesn't need to breathe, modulo dependencies, yes. but this attitude that "not active, must be dead and therefore: avoid" leads people to believing that the opposite: unproven and buggy new stuff, is always better. silly counter-example: vim from 10 years ago is just as usable for the 90% case as the latest one

tracker1 1y ago
I don't assume it's dead based on the last commit. I will look a little further and see where it stands. If there hasn't been a commit for a few years AND there are multiple pull requests that have been sitting unmerged for years and dozens/hundreds of really old issues... then, I'll assume it's dead, and often open another issue asking if it's dead, if there isn't one already.