Linux kernel worth €1 billion
computerworlduk.com
computerworlduk.com
You'd think that in a world full of businesses who survive on getting people to pay part of the difference between cost of production and value to the customer that there might be a general understanding that they are not the same thing. But no.
What makes it particularly egregious in this case is that whoever wrote the headline ignored the fact that the article itself is clear on the difference between cost and value, and that value was not estimated here.
For instance, the SLOCCount tools use the COCOMO model (http://www.dwheeler.com/sloccount/sloccount.html#cocomo), whose follow-on COCOMO II is discussed here (http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html). These models use factors like the following to calculate an exponent which is applied to the SLOC count to estimate cost to produce:
Required software reliability Database size Product complexity Execution time constraint Main storage constraint Virtual machine (HW and OS) volatility Computer turnaround time Analyst capability Applications experience Programmer capability Virtual machine experience Programming language experience Use of "modern" programming practices (e.g. structured programming) Use of software tools Required development schedule
Are these the right factors? How are they suited to estimating the cost to produce or reproduce a piece of software? What would you add?
It seems like some measure of the cyclomatic complexity of a codebase, or the number of syntactic elements, might add some information to the raw SLOC count. Arguably this doesn't tell you much about how much it might cost somebody to reimplement it (since that person might come up with an easier-to-code-and-maintain variant with lower cyclomatic complexity or in a more powerful language), but it might help estimate the cost to get it working in the first place.
And, of course, if you want to estimate costs and schedules for your software then I highly recommend reading Software Estimation. It offers a lot of good advice for people who seriously want to come up with somewhat less ineffective estimates.
They'd all switch to an identical Linux fork though, which I think was part of the original point being made.