4 ms·

"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." I

"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 3y 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 3y 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 3y 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 3y ago
      You're absolutely right. Something suitable will probably be available at any future point in time.
      - Zak 3y 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 3y 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 3y 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.

Zak 3y 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 3y 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 3y 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 3y ago
    You're absolutely right. Something suitable will probably be available at any future point in time.
    - Zak 3y 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 3y 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 3y 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.