Mark writes:
I wonder how much of his argument is related to architecture. If you have a good underlying architecture that supports decoupled development efforts, can you go further with unpaid-but-enthusiastic programmers? From what I know of the literature, the data about errors per KLOC (thousands of lines of code) is amazingly stable across projects and languages. But I don't know how many of the studies have looked at truly O-O projects like Squeak and Python.
I think it has to do with a host of factors. Tools for programmers, including alternative operating systems, and utilities users of such systems might use are candidates for Cathedral development. What about accounting programs for law offices?
One of the key virtues of OSS is that, if the program isn't behaving as you want it to be behaving, you can change it because you have the source. But what if you couldn't use the source code because you simply aren't technical, or if the costs of hiring programmers to learn the source and change it are large when compared to the benefits of the change? Suddenly, the presence of free source code changes nothing.
While for key, widely used, applications, a consulting business of pre-trained experts in the application do and have prospered, who is going to develop a consulting practice for maintaining and making changes to more obscure applications? As the prices go up for such OSS consulting, traditional business models become more attractive.
Now, mind you, OSS makes economically feasible things that were not before. Suppose there was a great, general purpose Word Processing program (closed source) named Letters. In the marketplace, users ask for features and publishers trade off costs and benefits in determining what the next upgrade will include. Their bottom line is usually to maximize profits by maximizing sales, which may mean that features highly valued by small numbers of customers will be given less weight than other more generally desired requests (for one-price/one-version business models).
So these features, though highly desired in a small market, may never get built? Why not? Presumably an enhanced product would sell at a nice premium. Answer: Often, the marginal benefits of such software features do not justify building the entire framework of a Letters program, the cost of which can only be amortized by selling the general framework to a large number of people. But with OSS Letters, a consultant can be brought in to make the marginal changes at relatively low cost. Because Letters is a general purpose program, a practice of consulting can be built around supporting it, and thus the cost of learning Letters' code can be shared among all clients seeking Letters support. Suddenly, a new kind of software becomes economically possible. (Of course, here's where Mark's architecture arguments come in).
At any rate, my key point is that OSS Cathedral development benefits may be limited to broad, general purpose programs, or programs for which the user community has a natural built-in technical capability.
I think that scripting languages may in time go a long way to change this, effectively broadening the community of persons who can adapt adaptable software. (Again, I'm implicitly buying into Mark's architecture issues). But fundamentally, I think the issue of OSS' chances in the future is economic and not technical in nature, although of course technical issues will affect the economics -- and that these economic forces must be understood first and foremost to even begin to guess where OSS is going.
For my part, the economic arguments are simply gratuitous -- the true virtue of OSS is its support of the hacker ethic -- information wants to be free. Now, as a stodgy IP attorney, its strange to see those words leaving my keyboard, but not so strange when you considered my roots. I still disagree strongly with gurus such as RMS who argue that the hacker ethic should be policy, for a host of reasons, economic and liberty-based. However, in MY OWN COMMUNITY, things like Squeak improve my life BECAUSE they are OSS, because its just plain fun to play with. Its the joy of hacking that supports things like Squeak, not the economics of its merits. Let's not lose track of the fact that some products, like Bind, are not labors of love for the community as a whole, despite their intensively important utility. Squeak is a joy for the people who use Squeak, and it is that joy that will drive its success under an OSS model. Were Squeak closed like its friends, my Xerox books might still be packed in a box in my attic and I might still be looking for something fun to hack.
So, there is an economic component, yes. But lets not forget the community, fun, hacker ethic component as well. The latter, more than the former, drives some of these movements.
I doubt we will find such interest and joy in hacking the law firm accounting program.
squeak-dev@lists.squeakfoundation.org