4 ms·

I think the gliding slope pattern has more than one reason to exist. One is the inability to innovate due to backward compatibility requirements. In fact this p

by mojuba 5y ago

I think the gliding slope pattern has more than one reason to exist. One is the inability to innovate due to backward compatibility requirements. In fact this pattern repeats itself in smaller software not just platforms. Look at Adobe Photoshop, and now it's Sketch's time to glide while infinitely approaching the ground. But I think there's another reason: not only inability to innovate but also unwillingness to do so. Companies on a gliding slope trajectory can attract a special kind of management people who like just that: to be in a gliding flight that can give enough material reward for a sufficient period of time. Why innovate then? I can think of maybe 2 or 3 exceptions of durable technologies that have survived decades and are still thriving because they don't belong to anyone. Unix for one, maybe SQL too. Ownership (or lack thereof) is the key here it seems.

simonh 5y ago
I think a really important factor is a well engineered extensible architecture. As you say, the incredible longevity of Unix, compared to any of its contemporaries. Windows finally got there with NT, though iterating on that had been painful I think that just down to Microsoft’s approach to product development projects.
- digisud 5y ago
  Huh? There are plenty of binary incompatiblies. Alone x32 to x64. Lots of dependency resolution going in under the hood of it as well.
- megameter 5y ago
  When we look at the compatibility story of Unix, it doesn't hold up well at all except as a ship-of-Theseus exercise. The original system design gradually became usurped by GNU tools, Linux kernels, and X11 window management. Sometimes you might be able to compile old stuff, but guess what, the C standard changed too. And every one of those things is in turn being challenged - "rewrite it in Rust" has produced new, similar, sometimes compatible but still different programs from the original inspirations. sysvinit was replaced with systemd. X11 became Xorg plus various extensions. Linux was eschewed as the kernel for OSX decades ago, and it's typical for software to need an "OSX build". There is old Unix software that can run on modern Unixes, but it depends heavily on not doing much I/O. Once you introduce an I/O requirement, failure is imminent - the protocols change, hardware gets accessed with a new method. You end up needing some kind of emulation. The same was basically true of DOS apps running natively on Windows - it would probably run your old Lotus 1-2-3 or WordPerfect in a window, but not games. Windows itself has had plenty of API churn(albeit with an unusually strong compatibility story), but a large share of new Windows apps are actually Electron wrappers. The glide slope theory isn't perfect because the life cycles do seem to depend on what you look at specifically, and there may have been a slowing of the curve with greater reliance on open-source and Internet technology. However it does seem to be predictable in describing the limits of software platform economics.
  - simonh 5y ago
    A ship of Theseus is fine as long as, at any given time, you have a seaworthy ship. MacOS deprecated 32 bit applications just a few years ago, that's a chunk of dead wood that got stripped out, some people are sticking with the older OS so we're in a transition period on that right now. A series of small incremental steps is vastly superior to a complete rewrite, or massive re-engineering project from the ground up every 10 years.

by mojuba 5y ago

simonh 5y ago

I think a really important factor is a well engineered extensible architecture. As you say, the incredible longevity of Unix, compared to any of its contemporaries. Windows finally got there with NT, though iterating on that had been painful I think that just down to Microsoft’s approach to product development projects.

digisud 5y ago
Huh? There are plenty of binary incompatiblies. Alone x32 to x64. Lots of dependency resolution going in under the hood of it as well.
megameter 5y ago
When we look at the compatibility story of Unix, it doesn't hold up well at all except as a ship-of-Theseus exercise. The original system design gradually became usurped by GNU tools, Linux kernels, and X11 window management. Sometimes you might be able to compile old stuff, but guess what, the C standard changed too. And every one of those things is in turn being challenged - "rewrite it in Rust" has produced new, similar, sometimes compatible but still different programs from the original inspirations. sysvinit was replaced with systemd. X11 became Xorg plus various extensions. Linux was eschewed as the kernel for OSX decades ago, and it's typical for software to need an "OSX build". There is old Unix software that can run on modern Unixes, but it depends heavily on not doing much I/O. Once you introduce an I/O requirement, failure is imminent - the protocols change, hardware gets accessed with a new method. You end up needing some kind of emulation. The same was basically true of DOS apps running natively on Windows - it would probably run your old Lotus 1-2-3 or WordPerfect in a window, but not games. Windows itself has had plenty of API churn(albeit with an unusually strong compatibility story), but a large share of new Windows apps are actually Electron wrappers. The glide slope theory isn't perfect because the life cycles do seem to depend on what you look at specifically, and there may have been a slowing of the curve with greater reliance on open-source and Internet technology. However it does seem to be predictable in describing the limits of software platform economics.
- simonh 5y ago
  A ship of Theseus is fine as long as, at any given time, you have a seaworthy ship. MacOS deprecated 32 bit applications just a few years ago, that's a chunk of dead wood that got stripped out, some people are sticking with the older OS so we're in a transition period on that right now. A series of small incremental steps is vastly superior to a complete rewrite, or massive re-engineering project from the ground up every 10 years.