3 ms·

As you can see, the point was not "paying for things you like", if you could buy them and they're yours. The problem is paying an ongoing subscription where the

As you can see, the point was not "paying for things you like", if you could buy them and they're yours. The problem is paying an ongoing subscription where they can pull the plug at any time. And owning your data and your tools isn't a theoretical or fringe concern. It is a central aspect of many people's lives, with wide practical consequences.

shanebellone 4y ago
"And owning your data and your tools isn't a theoretical or fringe concern. It is a central aspect of many people's lives, with wide practical consequences." Ironically, most development eschews this practice. The default approach appears to be: "Import it... if you can."
- Zak 4y ago
  Using libraries that are open source or perpetually licensed doesn't come with that sort of platform risk. The analog there would be relying on third-party APIs.
  - shanebellone 4y ago
    I fundamentally disagree. Supply chain is as important for software as it is for manufacturing. All code presents risk. With modern dependencies chains, those risks compound through time too.
    - josephg 4y ago
      Sure; but npm packages are much more likely to still be around in a few years than some random startup’s web app. Even the original developers can’t take their own code off npm in most cases any more. And if you really needed to replace a package you depend on, most useful packages on npm have a bunch of good-enough alternatives you can switch to with a little bit of effort.
      - shanebellone 4y ago
        You're absolutely right. Something suitable will probably be available at any future point in time.
        Zak 4y ago
        Come to think of it, I have been bitten by something like this before. I used the (mostly) single-developer project clojure-android to build an app and had no good options when bit-rot set in.
        josephg 4y ago
        Sure but even then, forking & fixing that one library will be a walk in the park compared to remaking Figma or Google Docs if those sites ever go down. They don't seem like remotely comparable risks.
        shanebellone 4y ago
        "fixing that one library will be a walk in the park compared to remaking Figma or Google Docs if those sites ever go down" Most core tech is trivial to rebuild for a single user. It becomes complex over time due to scale and with the addition of user-guardrails. I've been running a homegrown Object-Oriented Database for months without issue. It's less than 100 lines of Python including the interface.

shanebellone 4y ago

"And owning your data and your tools isn't a theoretical or fringe concern. It is a central aspect of many people's lives, with wide practical consequences." Ironically, most development eschews this practice. The default approach appears to be: "Import it... if you can."

Zak 4y ago
Using libraries that are open source or perpetually licensed doesn't come with that sort of platform risk. The analog there would be relying on third-party APIs.
- shanebellone 4y ago
  I fundamentally disagree. Supply chain is as important for software as it is for manufacturing. All code presents risk. With modern dependencies chains, those risks compound through time too.
  - josephg 4y ago
    Sure; but npm packages are much more likely to still be around in a few years than some random startup’s web app. Even the original developers can’t take their own code off npm in most cases any more. And if you really needed to replace a package you depend on, most useful packages on npm have a bunch of good-enough alternatives you can switch to with a little bit of effort.
    - shanebellone 4y ago
      You're absolutely right. Something suitable will probably be available at any future point in time.
      - Zak 4y ago
        Come to think of it, I have been bitten by something like this before. I used the (mostly) single-developer project clojure-android to build an app and had no good options when bit-rot set in.
        josephg 4y ago
        Sure but even then, forking & fixing that one library will be a walk in the park compared to remaking Figma or Google Docs if those sites ever go down. They don't seem like remotely comparable risks.
        shanebellone 4y ago
        "fixing that one library will be a walk in the park compared to remaking Figma or Google Docs if those sites ever go down" Most core tech is trivial to rebuild for a single user. It becomes complex over time due to scale and with the addition of user-guardrails. I've been running a homegrown Object-Oriented Database for months without issue. It's less than 100 lines of Python including the interface.