3 ms·

Isn't this the responsibility of the team choosing to use that project (transitively or directly)? If this was a commercial vendor that went out of business, w

Isn't this the responsibility of the team choosing to use that project (transitively or directly)? If this was a commercial vendor that went out of business, we wouldn't be discussing it. It would be a failure in the procurement process that didn't detect (and risk manage) the supplier's insolvency. The same due diligence should apply to open source projects. The benefit of open source is that it makes code escrow (and follow-on maintenance) a lot easier.

x86x87 4y ago
In theory you are right. In the real world the reality is that most of the software out there is built on the shoulders of open source. Due diligence for every thing you pull in (along with planning on what to do if you need to remove/maintain yourself) is prohibitory expensive. If you rely on something you should try to ensure that it survives and trives. Especially if you are raking in money as a result of using that something.
- jpollock 4y ago
  Paying for maintenance is part of a viable risk management plan. Due diligence is a measure of the size of the risk. Eventually, the risk will outweigh the cost of checking. Some firms will track the cost vs risk and act based on that, others wait until it explodes. e.g. The company is using software stack "D", and is launching a new business. They have no money. If they get sued, they close up shop and move on. They have a successful funding round and get an injection of $100m. This hits the news, and they are immediately hit with a lawsuit alleging copyright infringement through their use of "D" (GPLv3 perhaps?). Somewhere between launch and funding there was a point where the cost of diligence (detecting the license problem) would have dropped below the risk adjusted settlement cost (remediation + lawyers fees + lost sales), hopefully allowing the lawsuit to be avoided. Then again, it might never have crossed below. Knowing that line is an acceptance of the risk. That's also perfectly valid.
TheRealPomax 4y ago
This is a list of "destructive" incidents, rather than the usual "the project died and dropped off the web as a result" that you're thinking of (based on the vendor going out of business reference). A more apt comparison would be if a vendor didn't want to support an obsolete product anymore and so they remotely rig it to intentionally take down their client's business portal when they try to update instead of just not being available anymore. (And of course, that's the analogy, many of the items on this list don't hold up to it, as is the case with all analogies)
- jpollock 4y ago
  Risk management reveals risks such as: "the vendor disappeared", "the vendor hacked us", "someone hacked us through the vendor", "the vendor is no longer providing support". Those are all risks associated with using a vendor, regardless of whether or not you are paying for the software. If your business relies on it, it should manage those risks (insurance, escrow, business processes, paying for support, etc). The project disappearing/bankruptcy is only the easiest to point to.
jeroenhd 4y ago
I think it is. It's way too normal to build a product and pull source code from hundreds or even thousands of packages that you have no idea about. Even worse, loading these dependencies may execute install scripts that have full access to your dev computer. Open source is fine and using it is great. I trust many dev teams, but not all. Many languages (JS, Python, Rust, Go) have a super extensible, developer-friendly library of open source components for you to reuse, but this model also encourages relying on these tiny libraries often written by volunteers with no time to prune and maintain their own dependency tree. Personally, I try to just grab the code I need from small projects (with a link back to the library of origin) rather than add the dependency. This makes license management more difficult (as the source code usually comes with license terms) but packages like left-pad are better off in some kind of helper folder than in the dependency graph.

x86x87 4y ago

In theory you are right. In the real world the reality is that most of the software out there is built on the shoulders of open source. Due diligence for every thing you pull in (along with planning on what to do if you need to remove/maintain yourself) is prohibitory expensive. If you rely on something you should try to ensure that it survives and trives. Especially if you are raking in money as a result of using that something.

jpollock 4y ago
Paying for maintenance is part of a viable risk management plan. Due diligence is a measure of the size of the risk. Eventually, the risk will outweigh the cost of checking. Some firms will track the cost vs risk and act based on that, others wait until it explodes. e.g. The company is using software stack "D", and is launching a new business. They have no money. If they get sued, they close up shop and move on. They have a successful funding round and get an injection of $100m. This hits the news, and they are immediately hit with a lawsuit alleging copyright infringement through their use of "D" (GPLv3 perhaps?). Somewhere between launch and funding there was a point where the cost of diligence (detecting the license problem) would have dropped below the risk adjusted settlement cost (remediation + lawyers fees + lost sales), hopefully allowing the lawsuit to be avoided. Then again, it might never have crossed below. Knowing that line is an acceptance of the risk. That's also perfectly valid.

TheRealPomax 4y ago

This is a list of "destructive" incidents, rather than the usual "the project died and dropped off the web as a result" that you're thinking of (based on the vendor going out of business reference). A more apt comparison would be if a vendor didn't want to support an obsolete product anymore and so they remotely rig it to intentionally take down their client's business portal when they try to update instead of just not being available anymore. (And of course, that's the analogy, many of the items on this list don't hold up to it, as is the case with all analogies)

jpollock 4y ago
Risk management reveals risks such as: "the vendor disappeared", "the vendor hacked us", "someone hacked us through the vendor", "the vendor is no longer providing support". Those are all risks associated with using a vendor, regardless of whether or not you are paying for the software. If your business relies on it, it should manage those risks (insurance, escrow, business processes, paying for support, etc). The project disappearing/bankruptcy is only the easiest to point to.

jeroenhd 4y ago

I think it is. It's way too normal to build a product and pull source code from hundreds or even thousands of packages that you have no idea about. Even worse, loading these dependencies may execute install scripts that have full access to your dev computer. Open source is fine and using it is great. I trust many dev teams, but not all. Many languages (JS, Python, Rust, Go) have a super extensible, developer-friendly library of open source components for you to reuse, but this model also encourages relying on these tiny libraries often written by volunteers with no time to prune and maintain their own dependency tree. Personally, I try to just grab the code I need from small projects (with a link back to the library of origin) rather than add the dependency. This makes license management more difficult (as the source code usually comes with license terms) but packages like left-pad are better off in some kind of helper folder than in the dependency graph.