Subject: Re: free vs proprietary software business models
From: Brian Bartholomew <bb@wv.com>
Date: Sat, 27 Dec 1997 00:06:22 -0500

> Free software also seems to break down for really complex pieces of
> software, like Windows NT, MS Office or Oracle, that require dozens
> to hundreds of full time, highly paid, and highly skilled engineers
> to maintain and enhance the code base.

I think the free word processor problem exists because a GUI word
processor is far more difficult than it looks, but also boring and
nit-picky.  How do we raise $1M to fund some highly-skilled, full-time
engineers to work on this problem for a year or two?  Sell a special
commemorative CD distribution of something or other at $29.95 to 35K
of our friends, with the proceeds to the GUI WP charity?  Would one of
the major freeware CD distribution houses want to head this up?

-----

I do have some ideas about a "word processor":

Build a system for typesetting any size or shape of graphical marks,
not just letters.  Build a system to make complex layered effects like
you see on commercial art, not just opaque black letters on opaque
white paper.

To me, the inside of a word processor suggests a directed graph of
dependencies (line wrap position depends on word lengths, which depend
on character kernings) with loops (table of contents depends on the
top of the tree).  The interactive part of the word processor makes
local progress (rewrap the paragraph) in the area of the graph where
the user is typing.  However, the program is cool with nearly
everything being somewhat out of date, so you can edit a page in the
middle of 20-volume indexed set of books and it still keeps up with
your typing.

The gimp model of functional composition (separate-process user code
reads and writes a powerful api) looks much more appropriate than the
shell-script model (one-directional, all data structures flattened to
a stream of characters and processed sequentially).

Don't replicate the hair of TeX, LaTeX, or PostScript, but use the
good ideas of each.  Make a resolution-independent ASCII page-layout
language that draws lines and positions bitmaps; use the same code to
generate screen and paper display.  Perhaps a scripting language for
gimp?  Don't make the page layout language Turing complete, because it
will defy analysis by an interactive editor.  Make an ASCII transport
representation of a document that can be coded in by humans or
machine-generated.  Don't make the transport Turing-complete.


Another member of the League for Programming Freedom (LPF) www.lpf.org
-------------------------------------------------------------------------------
Brian Bartholomew - bb@wv.com - www.wv.com - Working Version, Cambridge, MA