Subject: Re: Development Shop FSB
From: Tom Lord <lord@regexps.com>
Date: Wed, 13 Mar 2002 00:36:58 -0800 (PST)



       Tom:

       As for the installation program, Anaconda is GPL.  So I don't know
       what you mean there.

I keep reading reviews about how much better RH's install process is
than the competition.  Since it's GPL, I'm surprised that those other
companies haven't picked it up.  Is there some technical barrier to
them doing so or is it just NIH?  Are there non-trivial components
related Anaconda, used to prepare distributions which use Anaconda,
that are kept solely in house or is the whole infrastructure really
available for download somewhere?

If the whole infrastructure really is available and usable by others,
then I'm simply wrong about the install program.  Sorry.


      Tom> RH brags a lot about the amount of development they do but I
      Tom> don't see them even trying to integrate that work into the public
      Tom> sphere except in cases where they can take more from others than
      Tom> they give back.  Thus, they play in the "classpath" and "gcc"
      Tom> projects, but hold back in the installation program and
      Tom> upgrade-over-the-net spaces.

      I think you're wrong about Classpath.  Classpath has benefited more
      than Red Hat from our work on it.

I don't want to ask you to give away trade secrets, but was that the
plan?  Is that the expectation for the future?  Or, when Classpath is
closer to done, is the plan to leverage it's existance following the
current "Subscriptions" and "Services" business models?  Applying
those business models to the project is what I'd expect Red Hat to be
planning based on their SEC filings.

I reached my conclusion this way:

I see plenty of contributions to Classpath coming from outside of Red
Hat (while also seeing plenty of contributions and project leadership
coming from inside Red Hat).  To an outsider, it looks like Red Hat is
doing what we all think FSB's _should_ do: leveraging the benefits of
cooperation to help produce a piece of software that's larger in scope
than what they could do by themselves, in house.

Why, I asked myself, would Red Hat do that given that they don't have
a general policy of doing all their development in the public sphere?
Presumably because, once Classpath is a little further along, it will
have commercial value to Red Hat (as a tool for network consulting or
custom development services;  or as an element of a
testing-differentiated subscription).

For either a subscription or services-based business use of Classpath,
the ideal outcome for Red Hat is complete cooperation on the project
up to the point where lots of code has been collected, but where
there's a quality problem with the public project that keeps people
from using it directly, and/or a complexity problem with it that
creates a need for consulting and development services.  What wouldn't
do Red Hat much good (given existing business models) is if the
project wound up in such a great state that nobody needed to buy
subscriptions and just about anybody could figure out how to use it
and build on it.

What I've been proposing in the "the process is the solution" messages
is that there are companies who have an economic interest in seeing
Classpath reach completion and seeing the public project wind up in a
great state.  They should be your customers and the work that Red Hat
currently contributes to the project should be (directly) yielding
profit.

-t