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


	[...] at the bleeding edge, it's not clear
	which way is forward.  So be nondeterministic and parallel: try them
	all.

My vague impression is that that is how Microsoft runs, within the
constraint of finding a continuous, (mostly) upwardly compatible path
from previous releases.  One occasionally hears stories about
competing lines of development with MS and the politics between
internal projects when the search is pruned.  

A funny thing about the way MS software is architected is that
sometimes, when a search is concluded, the result requires lots of
small changes throughtout most or all of the software: centralized
control and command of a single corporation makes such architectural
weaknesses into a business strength for a company with an army of
compliant programmers.

Many years ago, MS implemented an academic brain-drain, bringing in,
for example, lots of low-level OS academics -- who then set about
making changes to relax the implications of the upward-compatability
constraints.  They've been doing a good job.  In more recent years,
they've brought in lots of experts on high level programming
languages.  In my opinion, from a technology point of view, and in
spite of all the popular sentiment about MS incompetence, the FSB
world is in big trouble as a result.

Within the walls of MS, we may presume, internal competition is never
wasted, and always well focused; cooperation, where valuable, is
always implemented with near perfection.  FSBs ought to learn to have
projects cooperate and compete in similar patterns, with similar
efficiency, in spite of corporate boundaries.  Fortunately, being unix
and software tools based at the core, we are well positioned to
implement a competing search starting from a superior architecture
without the need for a centralized command-and-control development
process.  Really, the required competition can come about through
independent technical decisions made by individual FSB development
organizations.



    Tom> It hasn't helped when FSB's undertake to compete with one
    Tom> another on software products -- a tactic that makes much
    Tom> sense for proprietary software, but little sense for open
    Tom> source software.


    Face it: forks and rivalry are a fact of life.  

I agree that forks and rivalry are a fact of life.  A good fact, even,
at least in some cases.  Central arbiters of taste for individual
projects, the opposite of forks and rivalry, are also a fact of life
and also a good fact, at least in some cases.

My criticism is against businesses that hack open source projects as
if they were hacking proprietary software: making decisions on the
presumption that they should be the sole provider of that software.
The opposite presumption, that NO open source technology should be
vendor specific, is the better idea.  (This is not the same thing
as saying that all FSBs should, at all times, wear all of their
source code or project plans on their sleeve.)

Some companies seem to believe that by generating a sufficiently
opaque cloud of complexity, they can achieve the same effect as a
proprietary license.  Undervaluing documentation, hoarding testing and
other maintenance infrastructure, insisting on owning copyrights,
promoting valueless incompatability, and introducing gratuitous
interdependencies/complexity are typical sins.  All of those sins
emulate business tactics from the empire-building world of proprietary
software.  They are silly wastes of time in the FSB world.

We ought to more often take the view that project boundaries and
corporate boundaries are best when they are (in practice) orthogonal.
There is a landscape of free software, without legal boundaries, and a
collection of FSBs, constrained in part by the topology of that
landscape.  The opportunities of each individual (sanely designed) FSB
are maximized when the overall landscape of free software is improved
at the greatest possible rate, and when each individual FSB is able to
roam freely over that landscape with maximal engineering skill.
FSB corporations should implement engineering processes, seeking
business models that link revenues to the quality and applicability of
those engineering processes.  See my previous note on "how to organize
programmers".

A unique strength of open source businesses is the ability to
cooperate on projects.  Because that is a unique strength, we should
(a) maximize its exploitation by FSBs, both in business practices and
software architectures, and (b) attempt to exclude non-FSBs from the
process by universally and unilaterally adopting and enforcing the
GPL.

	Japan, Inc was a whole national economy organized on the
	"Cathedral" principle.

I am very far from advocating the cathedral principle for FSBs.  In
fact, I am criticizing business that build cathedral-style software
architectures, attempting to win pointless competitions with other
FSBs making rival cathedrals.

-t