[Gnu-arch-users] [semi-OffTopic] UserLinux

[Tom Lord]

Let me quote and comment on what I think is the most interesting
section of Bruce's paper to try to make my thinking a bit clearer:


  B> Structure

  B> At the core of UserLinux is a not-for-profit entity in charge of
  B> the Linux distribution, with engineering-by-meritocracy as in the
  B> Linux kernel. Surrounding that non-profit are for-profit
  B> companies that are in the business of providing service and
  B> engineering for the UserLinux distribution. Some of them may
  B> specialize in providing service to a particular vertical market
  B> or geographical region, others might be more general.


That's a very logical and (once you see it) obvious structure.  It
puts "in the middle" those activities for which all the customers are
best-served by resource pooling and factors out to the surrounding
cloud of for-profit companies those activities that customers don't
share with one another.

Abstractly, it resembles the current vendors whom Bruce describes as
part of "The Problem" -- they don't have a single NPO in the middle
but they do have Linus, apache.org, gnome.org, etc.  (Where I think
Bruce would say they go wrong is in what they "factor out" from the
shared region and how they use the leverage that factoring gives them.
For example, they have organized in such a way that customers of
competing vendors _don't_ pool resources to make a base distribution
that might be recognized as a target by ISVs -- they have customers
pooling only to contribute to individual proto-components, such as the
linus kernel series, which are of very little direct use to anyone
besides hobbiests and these vendors.)

Abstractly it also resembles my proposal in

  http://mail.gnu.org/archive/html/gnu-misc-discuss/2002-11/msg00000.html

the idea of which is to have smaller-scale, "body shop", for-profit
organizations serving specific user communities, but also pooling a
small percentage of their profit for the R&D and support activities
that it makes sense to share accross those communities.  (Where I
think Bruce would say I go wrong in that proposal is that I asserted
we ought to try to bootstrap by starting with the pooled R&D effort
and "building out" towards the customers whereas UserLinux is aimed at
starting with specific and interested user community and "building
inward" towards the pooled-resource activities.)


  B> Many of these companies already exist and have developed their
  B> customer base, and would be adding UserLinux to their existing
  B> services. Each of those businesses would reside upon a level
  B> playing field, with the same access to the software as any of the
  B> others. The non-profit core would be the entity that would be
  B> branded and certified as an enterprise-quality system.  Customers
  B> would have their choice of service company, and would be able to
  B> select from multiple, competing vendors who service and improve
  B> the same system.

This is an example of where I think it shows that Bruce isn't thinking
enough about engineering.  Specifically, "the same access to the
software" is not a very interesting or useful attribute of this
market.  All the UserLinux companies can download the same bits -- big
whoop.  That's no different from the situation that already exists.

What will be more interesting is to have the UserLinux vendors
_sharing_work_ on that shared source, in a robust and well organized
way, and also _collectively_sponsoring_work_ on that shared source.

The proposition here is to carve away from the vendor businesses
exemplified by SuSE and RedHat a portion of what they do and to move
that activity to a shared tent -- the activity of making the base
distribution.  The product of that activity is more than just bits
that can be downloaded -- the product is a _process_ that admits
feedback from customer needs to platform development and back again.

The Debian process, by definition -- by the social contract, can not
implement that feedback.  Debian has pledged to treat all users
equally -- not to give special attention to the customers of Bruce's
service companies.  Debian can't address customer's needs
preferentially.  It can't provide service-level guarantees.  There's a
layer missing there between Debian and UserLinux customers and it's a
more complex layer than just "same access to the software".


  B> There will be a service organization built on top of all of the
  B> individual service companies, so that customers can have a "large
  B> entity" to call that can provide service anywhere, but customers
  B> will also be able to go directly to individual service vendors.

That needs more attention.  What exactly does this service
organization _do_ besides answer a toll-free phone number and maintain
a list of endorsed service providers?

For example, if one of these service providers plugs, during an
emergency, a security whole for one of its customers -- I'd like to
see this umbrella organization make sure that the fix is proactively
and agressively propogated to the competing service providers and thus
to their customers.  I don't think it's reasonable to _rely_ on that
propogation round-tripping through the Debian process which, after
all, has an agenda much larger than these service providers.  The
"spirit" I think Bruce is aiming for is that the service providers
compete, sure -- but also cooperate by proactively working to make the
offerings of all the providers better in all areas where work (hence
customer dollars) can be effectively pooled.   So again: what does
this umbrella organization do besides answer the phone and read names
off of a list?

Bruce speaks to this very issue:

  B> [....]

  B> The service companies and their customers will drive development
  B> of the umbrella service organization and certification by
  B> standards organizations.

What I'm suggesting might be described as:

     Let us (free software volunteer engineers) beat the service
     companies to the top of that hill.  Let's get there first and
     have in hand, when they show up, a plan that says "Here's what we
     think makes sense for that umbrella service.  Here's how we
     understand the problems you're trying to solve; how we think they
     can be solved; and how we'd like to participate."

We (free software volunteer engineers) are a critical supply of labor 
for the effort Bruce is proposing.   We ought to see if we can raise
our collective voice here to help define the economic world in which 
we will be living and working.



  B> This structure establishes economic limits on the service
  B> companies. While they can make a living, they can't make a
  B> killing. These businesses would be "body-shops", which means they
  B> would scale linearly with the addition of engineering talent -
  B> each body brings in n additional dollars of profit. Venture
  B> capitalists aren't very interested in funding businesses that
  B> scale linearly, but fortunately the cost-of-entry for these
  B> businesses will be low. Many consulting firms are quite
  B> profitable, even if they are limited by the body-shop equation. A
  B> well-known Linux distribution company that I consulted tells me
  B> that they are already doing 70% of their business as service, and
  B> will be happy to live in the structure I have outlined.


Good points.  Personally, I believe that "low entry costs" plus "body
shop equation" suggests that excellent venture capital strategies _do_
exist in this area.  The tricks for VCs are to (a) clarify their
thinking about the orthogonality of risk and investment horizon, 
(b) learn to scale in the direction of making a large cumulative
profit from many small investments rather than a few large ones, 
and (c) learn the difference between controlling interest and
profitable return (a successful IPO is not the only way to be rewarded
for taking risk).

"Many small investments" and "not assuming a controlling interest" are
the tradition purview of conventional business loans rather than
adventurous investments but there is a gap (hence risk opportunity)
there between business models lenders recognize as "safe, on average"
and those which are "worthy of speculation".


  B> One of the areas in which UserLinux could probably differentiate
  B> is the ability to actually provide service to a large number of
  B> customers. 

_"probably"?!?!_  :-)

  B> Red Hat boasts that it employs 300 engineers, but few
  B> of those engineers are in customer-contact positions. Their
  B> support organization is surprisingly small. 

Formally, perhaps.  But I wonder how much clout they have internally?
I think Bruce might be failing to recognize de facto matrix management
in action.

But anyway, 300 is a pretty damn small number.



  B> Our multi-company effort has the potential to be able to offer
  B> more service, even by simple metrics like head-count, reasonably
  B> early in its existence. It can provide better-localized service
  B> because of the potential for involvement by service companies in
  B> many regions. And we can provide better quality, and lower-cost
  B> service, due to the fact that our service providers will compete
  B> with each other for business.

Absolutely.  I think that at least in the abstract, the UserLinux
model represents the future of IT, including home-consumer-oriented
IT.

The current IT model is like a crooked poker game with a subset of
ringers and a subset of patsies around the table.   (And a subset of
truly good card players frustrated in their attempts to play a
straight-up and honorable game, of course.)


  B> There are examples of the sort of structure I propose for
  B> UserLinux already existing, if on a smaller scale: Apache is a
  B> non-profit software core with a number of for-profit companies
  B> that service and engineer it, including HP and IBM. The same
  B> could be said for the Linux kernel.

Right -- the general pattern is clear.  The devil is in the details.

-t