Debian discusses vendoring—again

Posted Jan 13, 2021 13:45 UTC (Wed) by dottedmag (subscriber, #18590)
In reply to: Debian discusses vendoring—again by pizza
Parent article: Debian discusses vendoring—again

I happen to be making these decisions and I know how to translate them to the money.

«This critical-and-not easy-to-replace library has N 0-day exploits with RCE per year. The choices are: 1) use it as is and sustain M break-ins, each conservatively estimated to cost $X / year in lost revenue, cleanups, damage control etc plus $Q for initial use of this library; 2) proactively monitor and patch vulnerabilities, estimated cost is $Y / year plus $Q for initial use of this library; 3) develop a replacement in-house, estimated cost is one-time $Z and $W / year maintenance»

Sure it takes some experience and data to start making these decisions, but once the data is there it becomes much easier to decide. Also over time (3) becomes cheaper as problems don't tend to be unique every time.

to post comments

Debian discusses vendoring—again

Posted Jan 13, 2021 14:47 UTC (Wed) by pizza (subscriber, #46) [Link] (3 responses)

> 3) develop a replacement in-house, estimated cost is one-time $Z and $W / year maintenance»
> Also over time (3) becomes cheaper as problems don't tend to be unique every time.

You left out the cost of cleaning up after exploits found in your in-house library. Because your in-house code is far (far!) more likely to be full of holes than random F/OSS libraries that are used by a variety of other folks.

You also left out the fact that if it's in-house, $Z and $W are paid entirely by your organization, so while (3) might get smaller (relative to itself) over time, it will forever remain much larger than using a F/OSS library whose $Z and $W approach $0, as you're not shouldering the entire price of development and maintenance yourself.

In the end, most organizations go with (1) because they simply don't have the resources to do anything differently. (3) tends to only happen in areas where cost is not a primary consideration (eg military, medical, safety, and other highly regulated industries) or when there are specific requirements that cannot be met any other way. Varying degrees of (2) is where most organizations end up, typically balanced on the trailing edge of cost-benefit analyses.

Debian discusses vendoring—again

Posted Jan 13, 2021 18:36 UTC (Wed) by hkario (subscriber, #94864) [Link] (2 responses)

(3) also makes sense if any of the existing solutions don't share the goals you have (platform support, maintenance windows, etc.)

and just because you develop in-house doesn't mean you have a). started from zero, b). don't open-source it so that others that do share your goals can contribute

Debian discusses vendoring—again

Posted Jan 13, 2021 19:31 UTC (Wed) by pizza (subscriber, #46) [Link] (1 responses)

oh, quite right.

It's just that when you make that decision to go your own way, you can't assume that anyone else will ever contribute anything, much less shoulder the majority burden of developing/maintaining it.

Debian discusses vendoring—again

Posted Jan 13, 2021 19:36 UTC (Wed) by dottedmag (subscriber, #18590) [Link]

This equally applies to every open source library ever published, doesn't it? :)