Slashdot Mirror
Estimating the Size/Cost of Linux
2bits writes "Wow... A Billion Dollars Worth Of Software On My System For Free! Check This Guy Out, He Came Up With A Counting / Pricing Method For Quite A Few Types of Source Code. Here is the Program. The results on the site are sorta dated, based on RH 7.1, but the app is pretty cool!... Hey, I can finally find out how much all my side projects are worth / costing me..."
[cmdrtaco@localhost]$ est slashcode
Analyzing slashcode.....
Result: $6.66
[cmdrtaco@localhost]$
I know I'll get modded down for saying this, but Taco, as an "editor", couldn't you at least have fixed This Guy's Moronic Capitalization Scheme?
It's hard to be religious when certain people are never incinerated by bolts of lightning.
A Billion Dollars Worth Of Software On My System For Free!
Yeah, that's what happens when you use P2P _WAY_ too much
This looks like a serious problem for Linux distributors like Red Hat, Mandrake, and Debian. They sell their products (which consist of software and support and manuals) for $40-$100, usually. Now we see that what they put into their product (i.e., the cost) is orders of magnitude beyond that. Even if Red Hat sold every single copy it packaged (it doesn't even come close), and even if nobody downloaded it for free or copied the CDs for a friend (again, an incredibly optimistic assumption), it would still be looking at huge losses.
This might have worked a few years ago, but with accounting practices coming under scrutiny across the board, I fear that these companies are headed for trouble.
Karma: Good (despite my invention of the Karma: sig)
Instead of wasting time figuring out ficticious pricing based on the way that corporate america prices software, why not figure out a way to remove the aforementioned hidden costs from Linux so that the masses can begin to see what many of us on /. have known for a while: That GNU Linux and Open Source Software represent a great choice.
Amazing magic tricks
Sure, but what about the time spent in bug fixes, patches, etc? I supposed you can do something like this:
Programming cost = E dollars * ((X lines * C * percent * A minutes) + (X lines * D percent * B minutes))
You could even go fancy and calculate lines-per-minute based on each langauge. But then, what about Man pages, documentation, support sites, etc. These are things you would pay for in commercial software. Shouldn't these be a factor as well?
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
I'll never use macros, functions, classes, or the stl again!
"Look, I wrote a program which does the exact same thing as another program, but mine is worth much, much more!"
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I love these kind of stats.
Slashdot has, say, 100,000 US readers per day.
Each spends an hour reading slashdot when they should be working.
Let's say an average Slashdot reader is worth say, $40 an hour, and they read Slashdot on 300 days during the year.
That means Slashdot costs the USA $1,200,000,000 dollars a year! Crikey! Don't tell Bush!
To put it mildly...
In his paper, he uses the basic COCOMO model for estimating the cost. This model, quite frankly, sucks. Boehm's book even states, more or less, that the COCOMO model is only accurate to a factor of 10.
Since I no longer have the Boehm book, this quote from a google-found web page will have to do. This is a quote of a quote from Boehm's book, Software Engineering Economics:
"Basic COCOMO is good for rough order of magnitude estimates of software costs, but its accuracy is necessarily limited because of its lack of factors to account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on costs."
Basically, this means that the estimate could be anywhere from $100M->10B in true cost.
At the very least, this kid should have stated which of the model variants he was using.
Better yet, he should have subdivided the source code into multiple categories: kernel+drivers, tools, productivity software, etc. etc., and then applied the various models to them.
Just my 2 bits.
BTW, here is the google-found page which has the quote I stole. Plus, it gives a nice, albeit brief, overview of COCOMO.
-d
if analyzing SLOC says nothing about developer contributions, efficiency, or effectiveness - then isn't estimating value based off SLOC fundamentally flawed?
i mean, you can't have it both ways. Either SLOC shows how productive programmers are, or it doesn't.
if it does - then get over the SLOC analysis in your job reviews.
if it doesn't - then you cannot even remotely accurately guage monetary worth through SLOC.
good luck to the people trying to estimate worth of OSS. good luck to the people trying to estimate the worth of programmers.
i just don't know why people don't count 'Customer Problems Solved Over Time' as the end-all, be-all.
(and time and energy fixing software bugs doesn't count. that's not the customers problem. it's the developers)
who cares how many SLOC are in a product. how many needs of the end user does it fulfill, and how long did it take to get done from the word 'go'?
yeah, you'd need to define customer needs much more carefully than most shops do... but isn't that part of the eXtreme Programming retinue
// "Can't clowns and pirates just -try- to get along?"
Running the same SLOC figures against the statistics from the Function Points methodology and you get a different picture. You are looking at 2500 person years of effort, with a cost optimum development time of 6.5 years. However, to deal with the complexity involved you will need approximately 3000 average and 1500 above average developers (at average development rate you could expect a 13 year delivery!). Total price tag: around $2 billion (that's 2e9, in case your definition of billion is different).
Of course, this is still a very skewed figure. There is no accounting for the quality of code (at the end of such a complex development cycle, you could expect as many as 7 million defects!), and both FP and COCOMO estimate development effort inclusive of design work and documentation, which in OpenSource typically don't match those in mature commercial development environments (from which the FP and COCOMO statistics are derived).
There is also a huge, and invalid, assumption made by the author, regarding the application of COCOMO (and my FP calculations suffer the same problem). The complexity of a system is MORE than the sum of its parts. This is because developer productivity declines as system complexity increases.
At 10,000 FP, as developer is often only 60% as productive compared to 1,000 FP. The situation is obviously far worse at 300,000 FP (the entire distribution), yet the kernel itself only weighs in at around 20,000 FP. And even then, clear modularisation reduces complexity for individual developers. So it is grossly unfair to base calculations on the system as a whole.
The kernel (around 2.5 MLOC) as a single system would be a task for 300 skilled developers over around 3 years, while the Gimp (around 500 KLOC, still near the top of the list in size) would be looking at 50 developers over 18 months. More complex projects need relatively more time and more developers. Doing all these projects in parallel (assuming it were possible - which is isn't because of dependancies, and that's another factor) would take less than the most complex task (kernel = 3 years) and relatively less developers than estimated based on the complexity of that task (30 MLOC / 2.5 MLOC * 300 developers = max 3600 for entire distribution). Max cost: 3600 * 3 * $55k = $594 million.
And you're STILL not accounting for the fact that employing someone costs a lot more than just paying a salary. Which puts all estimates (mine and the authors) up.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
A proof point from Abiword. A just ran the program over our abi-unstable directory. About 300,000 LOC estimated cost to produce about $10,000,000.
I also ran the program over the abiword plugins directory. Estimated cost to produce, $1,200,000.
Now I know from direct experience that building the main code base of the AbiWord Word Processor took about 100 times more effort than the plugins.
Cheers
Martin Sevior
AbiWord Developer
Priceless
if analyzing SLOC says nothing about developer contributions, efficiency, or effectiveness - then isn't estimating value based off SLOC fundamentally flawed?
1) SLOC says nearly *EVERYTHING* about developer contributions. After all, the SLOC is what the developer contributes.
2) Efficiency is a measurable metric, and can be quite as simple as (SLOC/MM)-(NumBugs/MM), where MM=Man-Month.
While there is a variance in the efficiency of programmers, for any given company a median efficiency can be determined. From this, a decent cost-estimate for SLOC may be determined.
i just don't know why people don't count 'Customer Problems Solved Over Time' as the end-all, be-all.
That collected metric would have almost no utility, unless you could atomize the concept of a 'customer problem'.
"Well, it took us 6MM to craete that web-based
accounting system, so it should take us about
the same to develop these kernel drivers"
Something like the above doesn't help anyone. It doesn't help the programmers who take part in recording the data; it doesn't help the managers plan and predict the product lifecycle; it doesn't help the customer in letting him know when to expect to see the next product release.
What you failed to do was drill down further in your analysis of the problem.
Let's say you just finished putting out product "X", which solved some customer problem. Now the customer wants product "Y" to solve some other problem. How do you estimate "Y" based upon "X"?
Answer: Break it down. "X" required the following capabilities: A,B,C, and D. You recorded and tracked the amount of time it took to accomplish each capability.
Now, you break down the customer problem, "Y", and determine what it would take to solve it.
If you did a good job at atomizing the customer problem on project "X", then you should have been able to come up with an average amount of time/AtomicProblem. Apply this metric and Viola!, you should have a good idea about the scope of "Y".
Many people like to take the AtomicProblem and equate it to a SLOC estimate.
What SLOC counting does is try to establish a commonality among various projects so that future projects of various natures may be estimated using previous metrics. This is not perfect, but it should be used as an aid in determining overall project scope and costs.
i mean, you can't have it both ways. Either SLOC shows how productive programmers are, or it doesn't.
SLOC shouldn't be used to estimate programmer productivity. It should be used to estimate project productity.
-D
Obligatory Simpsons quote:
"Oh, people can come up with statistics to prove anything, Kent. 14% of people know that."
I would agree, but even the crappy slashdot search came up with the old story post while searching for SLOC. It only came back with 3 stories including this current one. The best part is that Taco also posted the original.
Note to Mr. Wheeler: when your shirt is the same color as the background of your web site, you might want to put a thin border around the picture with your favorite free image editing software.. though I'm wondering why exactly your picture is there at all..
Sloccount run on Slashcode 2.25 gives us this:
Total Estimated Cost to Develop = $ 996,916
I would have posted the entire output of the program, but unfortunately, their million-dollar lameness filter wouldn't let me!
No, Thursday's out. How about never - is never good for you?
His paper is valuable, priceless even, in that it is throwing a spotlight on a part of the Open Source phenomenon that has not yet come into public discussion.
While I don't know COCOMO, I accept that his numbers are highly suspect. But you have provided a range of accuracy that corrects for this. I am very confident that any reasonable assessment of the Linux development effort is going to be greater than $100 million and less than $10 billion.
So it is indisputable that Linux is a resource whose development effort exceeds $100 million.
And no reasonable person can question that this resource is now available at very low cost to anyone or any institution, on a global level.
It is difficult to see how anyone could not recognize that the use of this resource increases global wealth. Linux does make the world pie bigger.
I think that is the real story here. Linux is a tool, a lever, that has required at least $100 million of effort to develop, but which anyone can put to work for extremely low cost. I think this kind of phrasing needs to be brought to the attention of those who are being FUDded by groups that feel threatened by Open Source.
So either I'm doing enough work to be worth several hundred thousand dollars a year, or this thing is complete nonsense.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
- David A. Wheeler (see my Secure Programming HOWTO)
We worked out that it took 8 MAN YEARS to write some code.
That's all well and good, but it's been mostly me writing it on 37.5-hour weeks for the past 10 months.
This is a big "duh" in my book.
Smegma.