5 ms·

Linux kernel worth €1 billion

16 points by dreemteem 17y ago

st3fan 17y ago
But I just downloaded it for free. I do not understand!? :-)
- almost 17y ago
  Auction it on eBay! You'll be rich!! :p
vital101 17y ago
The wonderful thing is that if a price tag was placed on the Linux Kernel, it would become worthless. Being free (monetarily and in philosophy) is what makes it so valuable.
- Retric 17y ago
  If the licensing costs of the Kernel were 1 cent I don't think many users would switch to another system. You might see a significant drop in the embedded systems market, but only because there are other systems of similar value floating out there.
  - ZeroGravitas 17y ago
    Even at 1c everyone would switch. They'd all switch to an identical Linux fork though, which I think was part of the original point being made.
    - barnaby 17y ago
      Exactly, because in a highly competitive market (like software) prices always drop to marginal cost of production. Since copy/paste of software is free, the price inevitably drops to zero. The only way to charge a penny for the kernel would be to create artificial scarcity, or to create artificial legal restrictions to copy and paste... basically to override the free market.
    - Retric 17y ago
      Your missing the point, if every Linux Kernel cost 1cent due to patent issues many people would still use it. The option to switch to a "free" BSD Kernel would cause many people to use that for new systems. However, the value of a Kernel is increased by the other systems that connect to it. So if you had 10k systems and you could keep using them with zero transition costs for 100$ most company's would do so. The fact the Kernel cost's nothing does not mean it's value is zero.
sparky 17y ago
This seems like as good an opportunity as any to start a discussion: what do people think about these software cost estimation models and tools? They seem like a valuable tool for communicating the value of working software to non-technical businesspeople, but any programmer knows that the value, complexity, or cost to reproduce software is a function of much more than SLOC count. For instance, the SLOCCount tools use the COCOMO model (http://www.dwheeler.com/sloccount/sloccount.html#cocomo 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 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.
- btilly 17y ago
  Software Estimation by Steve McConnell (who is pretty much always worth listening to) makes the point that models with many tweakable factors like COCOMO II are not good for estimating costs because people have a strong tendency to start with a number they want to find then tweak the factors to get there. However the research that went into discovering the relative costs in the model has uncovered a lot of data that is worth listening to. 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.
btilly 17y ago
And again cost and value get confused. 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.
t3rcio 17y ago
Despite all, can we get it free? That is the motive because is so important that the user make your donations.
dustingetz 17y ago
FTA: "the thought experiment is not intended to determine the actual value of the software, but to give policymakers a greater appreciation of the potential benefits of community-based collaboration"

16 points by dreemteem 17y ago

st3fan 17y ago

But I just downloaded it for free. I do not understand!? :-)

almost 17y ago
Auction it on eBay! You'll be rich!! :p

vital101 17y ago

The wonderful thing is that if a price tag was placed on the Linux Kernel, it would become worthless. Being free (monetarily and in philosophy) is what makes it so valuable.

Retric 17y ago
If the licensing costs of the Kernel were 1 cent I don't think many users would switch to another system. You might see a significant drop in the embedded systems market, but only because there are other systems of similar value floating out there.
- ZeroGravitas 17y ago
  Even at 1c everyone would switch. They'd all switch to an identical Linux fork though, which I think was part of the original point being made.
  - barnaby 17y ago
    Exactly, because in a highly competitive market (like software) prices always drop to marginal cost of production. Since copy/paste of software is free, the price inevitably drops to zero. The only way to charge a penny for the kernel would be to create artificial scarcity, or to create artificial legal restrictions to copy and paste... basically to override the free market.
  - Retric 17y ago
    Your missing the point, if every Linux Kernel cost 1cent due to patent issues many people would still use it. The option to switch to a "free" BSD Kernel would cause many people to use that for new systems. However, the value of a Kernel is increased by the other systems that connect to it. So if you had 10k systems and you could keep using them with zero transition costs for 100$ most company's would do so. The fact the Kernel cost's nothing does not mean it's value is zero.

sparky 17y ago

This seems like as good an opportunity as any to start a discussion: what do people think about these software cost estimation models and tools? They seem like a valuable tool for communicating the value of working software to non-technical businesspeople, but any programmer knows that the value, complexity, or cost to reproduce software is a function of much more than SLOC count. For instance, the SLOCCount tools use the COCOMO model (http://www.dwheeler.com/sloccount/sloccount.html#cocomo 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 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.

btilly 17y ago
Software Estimation by Steve McConnell (who is pretty much always worth listening to) makes the point that models with many tweakable factors like COCOMO II are not good for estimating costs because people have a strong tendency to start with a number they want to find then tweak the factors to get there. However the research that went into discovering the relative costs in the model has uncovered a lot of data that is worth listening to. 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.

btilly 17y ago

And again cost and value get confused. 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.

t3rcio 17y ago

Despite all, can we get it free? That is the motive because is so important that the user make your donations.

dustingetz 17y ago

FTA: "the thought experiment is not intended to determine the actual value of the software, but to give policymakers a greater appreciation of the potential benefits of community-based collaboration"