[Pipet Devel] goings on

J.W. Bizzaro bizzaro at bc.edu
Mon Feb 15 20:16:09 EST 1999

Hello Locians!

I guess we've all been kind of quiet.  I'm working on a better description of
the project for the Web site.  This is in preparation of some announcements I
hope to post at some relevant places on the Internet.  Once posted, I hope we
can pick up some more developers, particularly people with experience in GTK. 
We have many more projects than people at this time.  I also hope to get a new
projects/TODO list to you guys soon.

Also, I still haven't heard back from Peter Rice of the EMBOSS project. 
Everything is really quiet there.

For your reading pleasure, I found an interesting editorial by Ajay Shah that
seems to hit on some of the key features of our project.  Here is an excerpt:


Strategies for building applications software

  * Model 1: Clean core, with third party extensions

The development model which fits open source the best, of course, is something
like GIMP or Emacs, where a technically solid core is extensible by third
parties. This is the most parallelisable development style which obtains the
maximum human inputs from across the globe with minimal problems of

If such a design can be applied to build a product, then I believe that `open
source' always wins because of the range of extensions, and the code quality
therein. The entry barrier of knowledge required to obtain the thrills of
producing useful code is very low with the scripting languages used in such
situations - as compared with starting from scratch writing in C. Hence it's
easier for the project to recruit developers. I suspect this design will work
for a spreadsheet and (to some extent) for a presentation program, but not
really for a word processor.

  * Model 2: Moving the application onto the network

The second way in which open source can make inroads is by making an established
product category obsolete. If personal finance programs turn into Internet sites
then the personal finance category ceases to exist. I have seen applications
which are painful attempts at putting databases (on CD or on hard disk) for
local querying under Microsoft Windows. This is ultimately obsolete because it's
so much more sensible to simply query this same data over the Internet.

Open source developers are in a unique position to apply this principle. Open
source developers are innovative, and highly knowledgeable about the Internet.
Open source developers have no qualms about cannibalising existing product
lines, a hurdle which limits innovation with many shareholder-owned companies.
To take a standalone application and convert it into an Internet service scores
high marks on the coolness scale; it'd attract development talent.

To the extent that innovative open source developers migrate existing
application categories into Internet versions, the problem of replicating
existing software is sidestepped. Of course, if Microsoft is able to own basic
protocols of the Internet or of Internet commerce, then Internet applications
could be even more closed than traditional MS Windows applications. Microsoft
has thus far had a near--zero impact upon protocol or technology development in
the context of the Internet, so this is not going to be easy for them.

  * Model 3: Applications which implement 20% of the features which account for
90% of the use

Every software product manager knows the misery of seeing 90% of users use only
20% of the features. I believe this is the direction from which new projects can
rapidly come up against well-established incumbents.

I feel there is something misplaced about the debates about whether `open
source' applications software match the features of mainstream commercial
products. A product which contains 20% of the features of a mainstream word
processor is adequate at the low-end market, since the bulk of the low-end
market never uses the complex features anyway. New projects should work to
carefully isolate the features which the `open source' applications should

It can't be very difficult for the wizards to hack up a filter which logs the
features used by existing word processor users. Such a program, runing at
workplaces all over the world, would yield data about the features that are
useful versus the features that aren't. This is reminiscent of the discovery, in
the days that preceded RISC, that compilers were only utilising a small core of
the instruction set.

I suspect that a program which implements one-fifth the complexity accounts for
90% of the usage. A clean reimplementation of these one--fifth of the features
would be lean and bug-free when compared with the bloated implementations that
are presently found with commercial user applications.

If this conjecture is on track, it implies that Microsoft's marketing department
is confused in what they're trying on applications software complexity. I
believe that 90% of humans will enjoy a lean word processor (with one-fifth the
features of existing GUI word processors) and the remaining 10% would be better
off with TeX.

Free, as in zero dollars

rms has talked at length about the issue of freedom, not price. I agree with him
on the way his argument applies to the development process. However, when we
discuss large-scale adoption by computer users worldwide, I wonder if we're
losing sight of the power of `free', as in zero dollars. If there was one thing
I was surprised to not see in the `haloween memo', it was the discomfort that
Microsoft must feel when competing against a price tag of 0. It is common to ask
whether linux, apache etc. are beating Microsoft technically, and generally the
answers are in the affirmative both on product and on development process. The
debate is incomplete unless we also factor in the price at which users access
the alternative products.

This is where the "20% of the features" product becomes compelling. The
competition is not between a 100% product and a 20% product at the same price.
The competition is between a 100% product at commercial prices versus a 20%
product at zero cost. Users would have to really want the remaining 80% of the
features to put up the money for commercial software. My suspicion is that the
fraction of users who use those remaining 80% of the features is around 10%.

J.W. Bizzaro                  Phone: 617-552-3905
Boston College                mailto:bizzaro at bc.edu
Department of Chemistry       http://www.uml.edu/Dept/Chem/Bizzaro/

More information about the Pipet-Devel mailing list