Harvard study: open-source has an economic value of 8.8T dollars

Linus is probably 60% of that?

> 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.