Subject: Re: [CoreTeam]Re: authentication systems (.NET, .GNU): Its the desktop, dummy.
From: Barry Fitzgerald <>
Date: Thu, 13 Sep 2001 14:34:53 -0400

Norbert Bollow wrote:
> Tom Lord <> had written:
> >       > A better reply is to wrestle the current desktop monopoly away from
> >       > Microsoft
> I had replied:
> >       How do you propose that we can go about this?
> Tom Lord <> replied:
> > 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.
> Yes... and I think that the best possible avenue of attack
> against Microsoft's desktop monopoly is the DotGNU project.
> (And I'll probably not change my mind about this until
> someone proposes a different plan for attacking Microsoft's
> desktop monopoly, and convinces me that the plan is feasible).
> > So I can't possibly answer your question.  But if I could, here's
> > what I might say:
> These are all good thoughts....  thank you for reminding us of them.
> Greetings, Norbert.
> --
> A member of FreeDevelopers and the DotGNU Steering Committee:
> Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich, Switzerland)
> Tel +41 1 972 20 59       Fax +41 1 972 20 69
> Your own domain with all your Mailman lists: $15/month
> >
> > * 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
> >

These are some VERY VERY good points.  I'd like to offer up some further
points if you don't mind - in support of DotGNU.

Yes, we absolutely need to take the desktop.  There is no doubt about
that.  We need to take the desktop and hold the server market.  These
are key goals to overtaking the proprietary infrastructures in use
today.  If we lose one in an effort to gain the other, we are in an
equally bad position.  This dictates that we need not only a good
development structure (Unix "everything is a file" and "small, simple
programs interacting" philosophies are a great start) but also a diverse
strategy of resource allotment.

To me, this is one of the most progressive points about the Free
Software community.  We can focus on many different strategies without
putting too much weight on one direction.  Yes, we need to focus on the
desktop.  But, we also need to focus on server technologies and we need
to keep up with the technology that is being produced by proprietary
vendors.  It is not, however, enough to simply emulate their
technologies - we must do better than they have.  We must supercede the
job that has been done by them.  We ABSOLUTELY have to answer hailstorm
and .Net.  DotGNU is, IMHO, the best strategy for this.  How do we take
the desktop if hailstorm is successful and we don't have an alternative?

We're not going to take the desktop today.  We need to be ready to take
it in 2 years or more.  Within that time frame, hailstorm might be a
dominant player in the industry.  However, let's assume that hailstorm
doesn't take off and neither does DotGNU.  Then, there's nothing lost. 
The development by the community being done on other strategies will
have continued.  Therefore no one wants unilateral strategic action -
what we want is to diversify our strategy.  The key is that we shouldn't
diversify our strategy to the point where resoures become
extraordinarily difficult to find.  I don't think that we're at that
point just yet.

Thank you for your input, I await a response. :)