4 ms·

We then calculate the demand side value based on a replacement value for each firm that uses the software and would need to build it internally if OSS did not e

We then calculate the demand side value based on a replacement value for each firm that uses the software and would need to build it internally if OSS did not exist. Presumably in the absence of OSS, companies would write far simpler software than the OSS they presently use. What fraction of the code in the Linux kernel do most users ever run?

metadat 3y ago
What leads you to presume company devs would be able to pull this off? Go write your own queuing solution from the ground up in real life. You'll learn it's non-trivial to cover all necessary edge cases while simultaneously avoiding tight/brittle coupling. Insane amount of work compared to dropping in battle-tested (or even modestly used) OSS, with stackoverflow/gpt solutions at your fingertips for nearly anything imaginable. Most companies core competency is in delivering business value, which means shipping useable products and features. This most often boils down to building atop a thick stack of open-source technologies (e.g. Dropwizard, Kafka, Postgres, MySQL, Opensearch/License, the vast Java and Golang ecosystems, Python, Django, RoR, PHP, and on and on). Without that, devs would need to spend $$$ licensing privately owned solutions, or do a ton of work developing homegrown spaghetti frameworks and platforms from scratch before even being able to start considering addressing core functional use cases. This would be very bad for startups with limited runway to get off the ground. What can be in days to weeks through OSS resources would take months to years, or costly licensing.
samatman 3y ago
Why would you presume that? There's plenty of proprietary software to test this assumption against: Microsoft sells it, Oracle sells it, IBM sells it. Are their wares simple?
- cperciva 3y ago
  The authors are talking about a counterfactual of companies building software internally, not buying it from a publisher.
- ensignavenger 3y ago
  There wares have to meet the needs of a diverse customer base. Custom software developed for in house use only needs to implement the features you need. Though without OSS, I suspect a lot of companies would opt for purchasing off the shelf solutions, which would quite possibly be a worse fit than the OSS solutions. Or, they may just go without.
bruce511 3y ago
The opposite of OSS is not "write your own", it's "buy commercial". And while (clearly) that would "cost more", the difference would be insignificant. In the sense that lots of companies already buy everything commercially, and the software budget is trivial compared to just about everything else. We buy a lot of software that we use, and our software budget is still smaller than our coffee budget. OSS delivers many benefits, but I'd argue that "price" is not the primary one. (It just feels that way when you're a student.)
- cperciva 3y ago
  The opposite of OSS is not "write your own", it's "buy commercial". I agree, but that's not the counterfactual the authors considered. They asked how much it would cost for everyone to independently rewrite the same software. It's not surprising that such a ludicrous concept produced an absurd estimated value.
yjftsjthsd-h 3y ago
> Presumably in the absence of OSS, companies would write far simpler software than the OSS they presently use. Simpler, but also worse. Part of the beauty of sharing common code is that you only need to prevent a problem once and then it can be fixed for everyone. If you write it in-house, it's easy to say "oh it's fine, nobody will ever attack this, it'll only be used under boring conditions, we'll never hit those edge cases" which is great right up until the day when it suddenly becomes very painfully untrue.
- cperciva 3y ago
  Simpler isn't necessarily worse. Having fewer features tends to make software more reliable and secure.
  - pornel 3y ago
    I don't think you can generalize it like that. It really depends whether the complexity is necessary or not, and that's context-dependent. If the implementation is too simple, it may have issues that impact its reliability. For example, code may be using simple linear search instead of fancier data structures/algorithms, and have issues with handling larger inputs or have accidentally-quadratic code paths. Or may updating data files without the complexity of atomic writes or inter-process locking, and corrupt its data if it's unexpectedly killed/restarted. Implementations that are too simple may be less secure, e.g. lack features for precise access controls, or sandboxing. Simple parsers can become a vulnerability (e.g. request smuggling attacks from underestimating complexity of edge cases in HTTP and URLs). Too-simple tools may just push complexity and security risks elsewhere. There's an endless supply of simple templating engines that make it too easy to introduce XSS vulnerabilities.

metadat 3y ago

What leads you to presume company devs would be able to pull this off? Go write your own queuing solution from the ground up in real life. You'll learn it's non-trivial to cover all necessary edge cases while simultaneously avoiding tight/brittle coupling. Insane amount of work compared to dropping in battle-tested (or even modestly used) OSS, with stackoverflow/gpt solutions at your fingertips for nearly anything imaginable. Most companies core competency is in delivering business value, which means shipping useable products and features. This most often boils down to building atop a thick stack of open-source technologies (e.g. Dropwizard, Kafka, Postgres, MySQL, Opensearch/License, the vast Java and Golang ecosystems, Python, Django, RoR, PHP, and on and on). Without that, devs would need to spend $$$ licensing privately owned solutions, or do a ton of work developing homegrown spaghetti frameworks and platforms from scratch before even being able to start considering addressing core functional use cases. This would be very bad for startups with limited runway to get off the ground. What can be in days to weeks through OSS resources would take months to years, or costly licensing.

samatman 3y ago

Why would you presume that? There's plenty of proprietary software to test this assumption against: Microsoft sells it, Oracle sells it, IBM sells it. Are their wares simple?

cperciva 3y ago
The authors are talking about a counterfactual of companies building software internally, not buying it from a publisher.
ensignavenger 3y ago
There wares have to meet the needs of a diverse customer base. Custom software developed for in house use only needs to implement the features you need. Though without OSS, I suspect a lot of companies would opt for purchasing off the shelf solutions, which would quite possibly be a worse fit than the OSS solutions. Or, they may just go without.

bruce511 3y ago

The opposite of OSS is not "write your own", it's "buy commercial". And while (clearly) that would "cost more", the difference would be insignificant. In the sense that lots of companies already buy everything commercially, and the software budget is trivial compared to just about everything else. We buy a lot of software that we use, and our software budget is still smaller than our coffee budget. OSS delivers many benefits, but I'd argue that "price" is not the primary one. (It just feels that way when you're a student.)

cperciva 3y ago
The opposite of OSS is not "write your own", it's "buy commercial". I agree, but that's not the counterfactual the authors considered. They asked how much it would cost for everyone to independently rewrite the same software. It's not surprising that such a ludicrous concept produced an absurd estimated value.

yjftsjthsd-h 3y ago

> Presumably in the absence of OSS, companies would write far simpler software than the OSS they presently use. Simpler, but also worse. Part of the beauty of sharing common code is that you only need to prevent a problem once and then it can be fixed for everyone. If you write it in-house, it's easy to say "oh it's fine, nobody will ever attack this, it'll only be used under boring conditions, we'll never hit those edge cases" which is great right up until the day when it suddenly becomes very painfully untrue.

cperciva 3y ago
Simpler isn't necessarily worse. Having fewer features tends to make software more reliable and secure.
- pornel 3y ago
  I don't think you can generalize it like that. It really depends whether the complexity is necessary or not, and that's context-dependent. If the implementation is too simple, it may have issues that impact its reliability. For example, code may be using simple linear search instead of fancier data structures/algorithms, and have issues with handling larger inputs or have accidentally-quadratic code paths. Or may updating data files without the complexity of atomic writes or inter-process locking, and corrupt its data if it's unexpectedly killed/restarted. Implementations that are too simple may be less secure, e.g. lack features for precise access controls, or sandboxing. Simple parsers can become a vulnerability (e.g. request smuggling attacks from underestimating complexity of edge cases in HTTP and URLs). Too-simple tools may just push complexity and security risks elsewhere. There's an endless supply of simple templating engines that make it too easy to introduce XSS vulnerabilities.