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