Subject: Re: authentication systems (.NET, .GNU): Its the desktop, dummy.
From: Tom Lord <lord@regexps.com>
Date: Thu, 13 Sep 2001 08:12:10 -0700 (PDT)



      > A better reply is to wrestle the current desktop monopoly away from
      > Microsoft

      How do you propose that we can go about this?

I'll try to give a good answer, but I'll start with a cop-out.

That's a huge question.  There is no such thing as a "complete"
answer.  It will take ongoing tactical analysis of where the software
is and strategic analysis of where it can wind up.  The right answer
at any given moment depends on who is asking and why, what they're
able to do, what resources are available, what business goals they do
or could have (if they're part of a business), what the customers are
saying and how they're behaving, etc.

So I can't possibly answer your question.  But if I could, here's
what I might say:

* What We've Got

In the short term, I think we have an existing code base with some
interesting properties.  We have some apps that are close enough to
the look-and-feel of Microsoft products that MS users can recognize
them and figure out how to use them.  I think we have some apps that
are in various stages of readiness for importing and exporting the
most common types of data from MS environments.  We have at least
three different sets of such apps and they are just starting to
achieve a tiny little bit of market penetration.  That's good.

Now the bad news: My experience with some of those apps has convinced
me that they badly need spit and polish more than they need new
features or architectural expansion.  I've found them to be buggy,
inconsistent, and sluggish.  I've found the programmer documentation
to be appallingly bad, and the on-line user documentation to be
inadequate and inconsistently presented.  I've found the
window-manager/desktop system they use to be confusingly presented and
somewhat at odds with sane ways of managing unix processes.  The code
base of at least one popular collection of apps (the GNOME family) is
disappointingly non-portable.  There is a lack of consistency for how
pieces of the system are built and installed.  There isn't much by way
of testing infrastructure.  There are a ridiculous number of
interdependencies between separately distributed packages so that just
putting together a development environment for one of the programs is
a monsterous undertaking.

Were I the czar of one of these families of apps, I would pull back
from the grand ambitions a bit, and concentrate on making what is
currently there work really, really well from both developer and
end-user perspectives, for just a core set of productivity apps.  That
would mean cleaning up the portability problems; standardizing the
makefiles in such a way as to encourage 3rd party developers; cranking
out good documentation; making the programs more useful independently
of one another and of the desktop; polishing the on-line
documentation; building up the testing infrastructure; shaking out the
bugs; and improving start-up times and overall performance.  I'd ask
as many developers as I could to work on myriad details of that sort
-- centralized issue tracking would be critical.  I'd start with
Makefile conventions and source packaging to set up a better
foundation on which to build-up distributed development for the rest
of the problems.  For a project of this scale, I'd want an engineering
process based on hierarchical patch acceptence with continuous, rather
than periodic release engineering at the top of the tree.

I've seen unix software development shops where developers have to
have two machines each: one for development -- and one to run outlook
and a few other MS apps just to communicate with non-programmers.  I'm
aware of plenty of offices where just the basic productivity apps,
with no more sophisticated functionality than was available from MS 5
or even 10 years ago is more than sufficient (with the addition of a
very basic browser).  A good goal would be to polish the existing
desktop app families with those kinds of audiences in mind, aiming for
inexpensive hardware.

When such an audience is finally beginning to be well served, the next
challenge is to implement tight feedback between that audience and the
developers to guide further refinement and enhancement.  The users,
not MS, should be telling us what new features are needed.


* What We Need Next: Software Tools

None of the popular linux desktop frameworks have a particularly
"unixish" architecture.  Apps and app components aren't built
as simple, specialized programs, generalized within their domain
of specialization, designed to be combined with one another in a small
number of generic yet powerful ways.

I think the next generation of productivity apps ought to embrace a
more classically unix style of architecture.  There are at least two
good reasons: First, a successful collection of software tools is good
for problem solving -- you aren't constrained to just the
functionality anticipated by the original developers.  Users will be
able to make neat, new applications of a family of software tools that
would be inconceivable with an MS-style architecture.  Second,
software tools can be developed and polished independently of one
another -- which is a more effective use of open source practices than
trying to have a central authority define a comprehensive, behemoth
architecture for everything.

Sometimes people draw a false distinction between unix software tools
and interactive or GUI software.  In fact, there is a very good
software tools approach to GUI apps and that is to build generic GUI
programs which manage interaction in application-independent ways,
backed by text (plain or structured) based apps which implement
application-specific functionality.  Some of Rob Pike's work on Plan 9
suggests some good directions.  Emacs suggests some good directions.

Does a web browser have to be a single program, separate from all
the other programs?

-t