The Simple Economics of Open Source

[Robin Becker]

In article <3dya67xga4.fsf at amarok.cnri.reston.va.us>, Andrew M. Kuchling
<akuchlin at mems-exchange.org> writes
....
>Also, ever had to debug a problem in a binary-only library through
>trial-and-error?  You can burn lots of time that way.  <core dump>
>"Hmm... maybe that parameter can't be NULL."  <core dump> "Maybe that
>struct field should be 1." <core dump>.  I like the fact that, if I
>start seeing mysterious errors, I can dive down into the language
>interpreter, farther down into the C library, and even into the kernel
>if needed.  Though I've only followed a problem all the way into the
>Linux kernel once (to discover it was my error), it was reassuring to
>be able to do so.
>
Well I did a bit of reverse engineering in my time, but I think that
along with many others I'm living in the past. Software doesn't cost
nearly so much as it used to. In real terms the average application
doesn't cost nearly so much as my perceived $10k=car. The computer I
have at home is about the same power as a CDC 8600 of 20 years ago. It
doesn't need 50 people to run it and the software cost me around 300$.
I don't think I need to worry about cost (even though it still seems to
hurt). I worry more about the control of the software development
process more than the economics.

As for diving into the mechanics, would you do the same to your car? How
about fixing the video recorder or the mobile phone? Similar
intellectual requirements, but not so interesting to the 'nerds'.
-- 
Robin Becker