3 ms·

Only for some incredibly broad definition of fault that almost no one uses. How many people make sure all of the open source libraries they're using are bug fr

• majormajor 4y ago
  I've never cared per se that a library was bug free but I've put a lot of effort/$ into making sure the features that used the libraries in my product were bug free (with the amount of effort depending on the sensitivity of the feature, data, etc). Usually "fix the original library" wasn't as easy or immediate a fix as "hack around it" which is sad just re: the overall OSS ecosystem but still the person releasing a product's responsibility. Unfortunately these sorts of bugs are wildly difficult to predict. Yet it's also a wildly common architecture. That's what's sad for all of us as engineers as a whole. But "caching credit card details and home addresses", for instance, is... particularly dicey. That's very sensitive, and you're tossing it into more DBs, without good access control restrictions?
• JohnFen 4y ago
  > Only for some incredibly broad definition of fault that almost no one uses. It's a definition most laypeople use. It's developers who tend to use a very narrow definition. I don't think it should be controversial to say that when you ship a product, you are responsible for how that product behaves.
• rschoultz 4y ago
  Anywhere where you have payments related or any other PII data, then transitive dependencies, framework and language choices, memory sharing and other risks are taken into account as something that you as someone developing and operating a service is solely responsible for.
• pjmlp 4y ago
  Anyone that has to pay from their own pocket when things go wrong, like consulting warranties, liabitiliy in security exploits,...