Squeak in IEEE Software
agree at carltonfields.com
agree at carltonfields.com
Mon Feb 1 16:47:01 UTC 1999
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.
More information about the Squeak-dev
mailing list
|