>Around 95 percent of this figure is attributable to 3,000 developers worldwide. In addition, open-source software is included in 96 percent of all codebases.
Not shocking to see the big guns coming hard at FOSS.
That value and cost-factory is likely a higher multiple when talking about infrastructure. If everyone had to pay for Windows (or a similar OS) instead of Linux and numerous other systems (PostgreSQL, OpenLDAP, Nginx, ...) our costs for hosting services would move up at least an order of magnitude.
We make future open source software; it becomes open source when we recouped our investments. It's the only way I found that works. If we never recoup them, then ok, we open source them too but that we don't tell anyone. And yes, we donate what we can to projects we use. But that's not a plan; unfortunately it doesn't work outside a few coffees for them if the project is substantial.
That's like saying companies you worked for couldn't exist without indoor plumbing (which is what OSS effectively is). Yet the earliest company was founded in the year 578 AD, and other massive organizations (like empires) existed much earlier than that. OSS is plumbing, cheaper plumbing makes for more tiny fruit-fly companies, yes, but there are always alternatives.
brief critique of the methodology from a skim-read of the paper:
> We first estimate the supply-side value by calculating the cost to recreate the most widely used OSS once. 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. We estimate the supply-side value of widely-used OSS is $4.15 billion, but that the demand-side value is much larger at $8.8 trillion
[...]
> We first measure the value of OSS by considering the supply and the demand side of OSS using a
labor market approach. The thought experiment is that we live in a world where OSS does not
exist and has to be recreated at each firm that uses a given piece of OSS. Using the labor market
approach, we calculate the labor replacement cost of each OSS package. To estimate the value for
each package, we use COCOMO II (Boehm, 1984; Boehm et al., 2009) at the individual package
level and then sum across all package values to obtain a supply-side labor market replacement
value. Then, we scale the supply-side value by the number of times firms are using each package
while removing multi-usage within each firm to obtain a demand-side value.
The demand-side estimate (used to produce the headline $8.8 trillion US dollar number) is simple, but has a few flaws:
- it assumes a world where commercial software vendors cannot replace open source projects to become suppliers and maintainers of equivalent packages / libraries. Instead, each firm must internally reconstruct each package it depends upon without external communication or trade. This seems to be a poor approximation of how the world works -- it assumes specialisation of firms and trade between firms is impossible.
- it assumes that each firm that uses a package uses _all_ the code in the package. but often in practice, an open source package caters to a variety of use cases, but its use by a particular firm may only be for a single or sparse number of use cases involving a subset of the code
- it assumes that demand for a good (an open-source software package) does not reduce as the price of that good increases from zero to a potentially extremely high capex cost. in practice we might find that the _benefit_ firms obtain from depending upon an open source package is marginal, and an increase in the cost of the package from "free" to even 1% or 10% of the capex cost to develop it in house (let alone if it cost 100% of the capex cost) might result in it being irrational for the firm to depend on the package, and the firm would eliminate the dependency by switching to a cheaper alternative (use a manual process instead of a software process, switch to a commercial package sold by a vendor for a modest licensing fee, simply stop doing the marginal-value job that the software was doing)
From a quick skim-read, the authors do not explicitly seem to address any of these potential weaknesses in the demand-side estimation approach in their paper, but to their credit they do include "Appendix A) Goods-Market Valuation Approach" where they explore an alternative.
> The top 5 programming languages contain C (including C# and C++), Java, JavaScript, Python, and Typescript. We also add Go to this list of top languages since it is an increasingly widely used language in OSS.
They group C# and C++ together with C as "C"!
> For both the supply and demand models, we obtain the dollar-value for each package via the Constructive Cost Model II, also abbreviated as COCOMO II (Boehm 1984, Boehm et al.
2009). [ ... ] It is a highly flexible model that allows us to create non-linear
transformations of lines of code to dollar-values. It uses the following modelling equation: E_i = alpha eta L_i^beta where L_i represents the lines of codes in thousands and E_i the effort in person-month units for each project i. Consistent with Blind et al. (2021), we use the default parameter values for alpha, beta and eta. The parameters alpha, beta are non-linear adjustment factors set to 2.94, and 1.0997 respectively. The parameter eta is an effort-adjustment factor which can be modified to incorporate subjective assessments of product, hardware, personnel, and project attributes. Since we do not have a prior for each project, we set eta to the default value of one
So, if I follow that, the estimate of person-months of effort for package i is E_i := alpha eta L_i^beta = 2.94 * L_i^1.0997 where L_i is the number of lines of code in thousands in package i.
Interestingly, this approximation for effort is independent of programming language used to develop the package!
This suggests that if we rewrote a given package in a less expressive programming language, where 10x as many lines of code were required to produce a package with equivalent functionality, then all things equal, the estimated "value" of our package would increase by 10x, as a result of labour productivity decreasing by a factor of 10!
This doesn't make a lot of sense, but is a consequence of the assumption to approximate the firm's value of using a package with the replacement cost. I imagine that estimating the actual economic value of the package to each firm, independently of the cost, would require a lot of very hard work and information that is difficult or impossible to obtain.
It is unclear if the approach of "Blind et al (2021)" to set all the COCOMO II model parameters alpha and beta to defaults, and further the author's decision to set the parameter eta to one, produces accurate estimates of effort as a function of lines of source code. It is certainly an easy thing to do!
edit: i mixed up supply-side & demand-side in parts of my critique. fixed.
They have to choose between contributing a salary for a year to open source projects that are the foundation of their business or fuelling one of the corporate jets for an hour. Making these sorts of tough decisions are what the 10mil+ in bonuses are for at the end of the year.
I suspect many of these open source developers are employed in this capacity on some level by for-profit corporations (which sadly does bring a high degree of dysfunction in terms of resource allocation). But I can't imagine being this productive as a side-gig.
well, most successful oss projects are paid for through that one guy at the corner cubicle that has very few company responsibilities, but he maintains lib-fart-chart, which is also used at said company.
[+] [-] zonkerdonker|1 year ago|reply
>Around 95 percent of this figure is attributable to 3,000 developers worldwide. In addition, open-source software is included in 96 percent of all codebases.
Not shocking to see the big guns coming hard at FOSS.
[+] [-] blitzar|1 year ago|reply
Linus is probably 60% of that?
[+] [-] WithinReason|1 year ago|reply
[+] [-] c0balt|1 year ago|reply
[+] [-] flanked-evergl|1 year ago|reply
[+] [-] anonzzzies|1 year ago|reply
[+] [-] rvense|1 year ago|reply
[+] [-] 7e|1 year ago|reply
[+] [-] shoo|1 year ago|reply
Hoffmann, M., Nagle, F. and Zhou, Y., 2024. The value of open source software. Harvard Business School Strategy Unit Working Paper, (24-038).
link to HBR summary (published March 2024): https://www.library.hbs.edu/working-knowledge/open-source-so...
link to the 2024 working paper [pdf]: https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-...
[+] [-] shoo|1 year ago|reply
> We first estimate the supply-side value by calculating the cost to recreate the most widely used OSS once. 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. We estimate the supply-side value of widely-used OSS is $4.15 billion, but that the demand-side value is much larger at $8.8 trillion
[...]
> We first measure the value of OSS by considering the supply and the demand side of OSS using a labor market approach. The thought experiment is that we live in a world where OSS does not exist and has to be recreated at each firm that uses a given piece of OSS. Using the labor market approach, we calculate the labor replacement cost of each OSS package. To estimate the value for each package, we use COCOMO II (Boehm, 1984; Boehm et al., 2009) at the individual package level and then sum across all package values to obtain a supply-side labor market replacement value. Then, we scale the supply-side value by the number of times firms are using each package while removing multi-usage within each firm to obtain a demand-side value.
The demand-side estimate (used to produce the headline $8.8 trillion US dollar number) is simple, but has a few flaws:
- it assumes a world where commercial software vendors cannot replace open source projects to become suppliers and maintainers of equivalent packages / libraries. Instead, each firm must internally reconstruct each package it depends upon without external communication or trade. This seems to be a poor approximation of how the world works -- it assumes specialisation of firms and trade between firms is impossible.
- it assumes that each firm that uses a package uses _all_ the code in the package. but often in practice, an open source package caters to a variety of use cases, but its use by a particular firm may only be for a single or sparse number of use cases involving a subset of the code
- it assumes that demand for a good (an open-source software package) does not reduce as the price of that good increases from zero to a potentially extremely high capex cost. in practice we might find that the _benefit_ firms obtain from depending upon an open source package is marginal, and an increase in the cost of the package from "free" to even 1% or 10% of the capex cost to develop it in house (let alone if it cost 100% of the capex cost) might result in it being irrational for the firm to depend on the package, and the firm would eliminate the dependency by switching to a cheaper alternative (use a manual process instead of a software process, switch to a commercial package sold by a vendor for a modest licensing fee, simply stop doing the marginal-value job that the software was doing)
From a quick skim-read, the authors do not explicitly seem to address any of these potential weaknesses in the demand-side estimation approach in their paper, but to their credit they do include "Appendix A) Goods-Market Valuation Approach" where they explore an alternative.
> The top 5 programming languages contain C (including C# and C++), Java, JavaScript, Python, and Typescript. We also add Go to this list of top languages since it is an increasingly widely used language in OSS.
They group C# and C++ together with C as "C"!
> For both the supply and demand models, we obtain the dollar-value for each package via the Constructive Cost Model II, also abbreviated as COCOMO II (Boehm 1984, Boehm et al. 2009). [ ... ] It is a highly flexible model that allows us to create non-linear transformations of lines of code to dollar-values. It uses the following modelling equation: E_i = alpha eta L_i^beta where L_i represents the lines of codes in thousands and E_i the effort in person-month units for each project i. Consistent with Blind et al. (2021), we use the default parameter values for alpha, beta and eta. The parameters alpha, beta are non-linear adjustment factors set to 2.94, and 1.0997 respectively. The parameter eta is an effort-adjustment factor which can be modified to incorporate subjective assessments of product, hardware, personnel, and project attributes. Since we do not have a prior for each project, we set eta to the default value of one
So, if I follow that, the estimate of person-months of effort for package i is E_i := alpha eta L_i^beta = 2.94 * L_i^1.0997 where L_i is the number of lines of code in thousands in package i.
Interestingly, this approximation for effort is independent of programming language used to develop the package!
This suggests that if we rewrote a given package in a less expressive programming language, where 10x as many lines of code were required to produce a package with equivalent functionality, then all things equal, the estimated "value" of our package would increase by 10x, as a result of labour productivity decreasing by a factor of 10!
This doesn't make a lot of sense, but is a consequence of the assumption to approximate the firm's value of using a package with the replacement cost. I imagine that estimating the actual economic value of the package to each firm, independently of the cost, would require a lot of very hard work and information that is difficult or impossible to obtain.
It is unclear if the approach of "Blind et al (2021)" to set all the COCOMO II model parameters alpha and beta to defaults, and further the author's decision to set the parameter eta to one, produces accurate estimates of effort as a function of lines of source code. It is certainly an easy thing to do!
edit: i mixed up supply-side & demand-side in parts of my critique. fixed.
[+] [-] feverzsj|1 year ago|reply
[+] [-] blitzar|1 year ago|reply
They have to choose between contributing a salary for a year to open source projects that are the foundation of their business or fuelling one of the corporate jets for an hour. Making these sorts of tough decisions are what the 10mil+ in bonuses are for at the end of the year.
[+] [-] ForTheKidz|1 year ago|reply
[+] [-] almosthere|1 year ago|reply
[+] [-] high_na_euv|1 year ago|reply