Subject: Re: [coallesced replies] Re: how to create 21,780 new fr
From: Tom Lord <>
Date: Wed, 6 Nov 2002 10:31:37 -0800 (PST)


       > Users (and user populations) have very diverse needs, which
       > are satisfied by using many different software packages.  You
       > can never offer "all your binaries."  You must fence off a
       > subset of what you will support, which is another way of
       > saying you divided your market/created a new distro.  

Agreed.  I understand you better rereading this after other people
said similar things.  The data and anecdotes you go on to cite are
interesting, so I've addressed them in some detail.

Generally, users who need an app not in that distro can pay some 3rd
party to be added to the directory access list for that app -- it's
easier than driving all the way to the software store and it lowers
the operating costs for 3rd party developers.  The plan creates a new,
low-cost distribution channel -- it lowers the barrier to entry for 
people that want to make app companies.  (Several months ago, I called 
app companies dinosaurs, but I was wrong.)

Saying "created a new distro" is a little misleading.  Remember that
the plan creates thousands of R&D positions, and an order of magnitude
more custodial positions.  Yes, each 60k user community gets, in
effect, it's own distribution -- but 98% of the work to produce those
distributions (source package creation, release engineering tools,
testing and testing tools, etc.) is the job of the R&D folks; the
custodial folks are (directly or indirectly) their customers.

      Looking at the size of *BSD ports, CPAN, or similar would give
      you an idea of diversity in open communities.  Let's say on the
      order of 5000.

      Selecting populations geographically results in the maximum
      diversity (in everything except culture and language.)  Any
      resonably sized population (N > 1000) which is selected
      geographically would be expected to include users of almost
      every one of those 5000 packages.

I don't know much about CPAN, but the FreeBSD ports collection
contradicts your estimate.  I've found plenty of packages in the
FreeBSD ports collection that are stale links; many that are
localized versions of other packages; not a few that just aren't very
good.  Putting up a package seems to be something a lot of people do
for fun for a while -- production exceeds demand.

If we count the FreeBSD ports naively, we'll get a big overcount.

A notorious problem isn't that there are too many packages that might
go in a distro, but that there isn't free software R&D to develop a
some packages that could compete with specialized proprietary apps.
The plan addresses that shortfall in three separate ways: (1) With a
large R&D staff; (2) by creating of a new distribution channel for 3rd
parties; (3) by giving the custodial staff lots of free time.

	 I asked someone who does systems support/2nd level help desk
	 for a largish global non-techie corporation.  She didn't say
	 how many are in her group, but my guess (based on previous
	 conversations) is that they probably have about 10 people,
	 and they do provide the top-notch support that you outline
	 (for the apps they officially support.)
	 They support a userbase of 30,000 running a mixture of
	 systems from Windows to mainframes. But most of their service
	 load is for desktops and laptops (at least 25% are laptops.)

	 They officially support Windows 95, 98, NT, 2000. (That might
	 give you an idea of how easy/likely it is to assume you
	 always have up to date versions.)

You're pretty much answering your own objection.  Your example is 
an organization with the 2nd-level help desk having a ratio of:

	10:30,000 == 1:3000  staff:users

the plan has 2nd level staff at:

	4:60,000 == 1:15,000 staff:users

a x5 disadvantage.  On the other hand, the plan simplifies the task.
Instead of supporting four platforms, the plan has the staff
supporting just one.  Instead of supporting platforms that are
individually installed and configured, the plan has the staff managing
the network via the global file system (yes, vendors of all types are
also _trying_ to solve the remote admin problem in other ways).

	She doesn't get the pie-in-the-sky salary or benefits you
	mention in your outline and spends 1 of every 4 weeks on-call
	(168 hours continuous.)

From the details you provided of what she does, I'm not surprised.
She's supporting a more heterogenous network consisting of platforms
that are harder for her department to admin.  The plan homogenizes the
network, and makes admining all the clients a comparative snap.  It's
a historical fact that fs-based admin at this scale works perfectly

	Their small number of apps is probably explained
	by the fact that her employer is not selling technology
	or services, so users have pretty homogeneous needs on the
	desktop.  That is totally unlike what you would have in a
	geographically delineated market like you outline.  

Just to repeat: all those obscure apps that only a few in each user
community use, and the support for them, can be provided by 3rd

	There is no way to provide top-notch (i.e. "official" support)
	for two orders of magnitude more applications with 10 people,
	or even your figure of 16 people per 30,000.

We're missing some data.   We could use:

1) A study of the nature of the support calls your friend gets.   
   How many of them, for example, would never come up if you're 
   getting a centrally admined platform off a global file system?
   How many could be solved with less work?  And, ob-FSB, how many
   of them are common user errors that could be quickly eliminated
   given a tight-turnaround and good feedback with people who can 
   modify the programs to fix the underlying UI bug?

2) We need harder numbers about the experience of universities than
   those I'm able to conjur up from 15-year old memory.

	I'd estimate you'd need significant staff just for
	updating/repackaging/regression testing apps from the official
	maintainer's sources.

A portion of the R&D group has that job.  They're product should be a
customizable source-based distribution whose infrastructure makes
building a new instance and running the tests on it a kind of "push
this here button" experience.  The user community custodianship
business units are franchises.  Someone on the list has been working
on tools for that, as I recall :-)   Beyond that, other people's work
can perhaps be repurposed for this (e.g., RH's internal infrastructure
turned into a distributed package -- if it's any good :).