Subject: Re: Paper on dual licensing
From: Tom Lord <>
Date: Thu, 26 Dec 2002 13:55:49 -0800 (PST)

   Tom Lord says:
   > You're arguing from the oft repeated belief that if you don't like
   > what RHAT has sold you, just hire someone else to work on the source.
   > Bullcookies.  How many enterprise customers currently posses (in any
   > meaningful sense) complete source for their RHAT systems?  How often
   > do they rebuild from scratch?  What testing infrasture do they have in
   > house?  How many competing vendors are ready to take over maintenance?

   I don't normally respond to Tom Lord posts, but I have the opportunity
   to flatly contradict him here.

I guess I'm honored.

Actually, you wind up supporting the point I was trying to make.
Among other things, companies like yours should be further empowered:

   I work for a company that ships servers running Red Hat Linux running
   a proprietary application.  We have modified the kernel and several of
   the daemons running on the box.     We don't build most of the system
   from source --- only the programs we've modified --- but I don't think
   that matters much.

I'm advocating for a shift towards "managed source" products and away
from "binary distribution" products -- at least at the high-end of the

A managed source product looks more like a development and release
engineering environment, less like a CD image and update server.  It's
tuned to help you audit, inspect, customize, build, test, and maintain
your own images and update pipelines starting from source.  It's like
selling a tiny, cheap-to-run factory instead of the products coming
off the line of your own factory.

You say you don't build most of the system: but managed source
products would make it cheap and natural for you to do so.  It would
make companies like yours easier to create and it would give those
companies greater degrees of freedom.

In effect, your customers now depend on not one but two binary-release
engineering pipelines: yours and Red Hat's.  What does that do for
their emergency preparedness?  How many new vulnerabilities does it
introduce?  What companies are they now locked-in with?  If your
customers want to further customize, how expensive will it be for them
to build yet a third release engineering process?

In the parts that you modify: what mechanisms do you use to track and
integrate changes made to those parts upstream?  How hard is it to
produce an accurate and detailed report comparing your product with
Red Hat's from Red Hat and Red Hat's from IBM and Red Hat's from Sun
(for example, to determine whether or not you've picked up a
particular feature or security patch).

Supposing a critical source patch to a part you've also modified
appears upstream of you and that some but not all of your customers
want or need it quickly.  What's the turn-around on that going to be?
How much will it cost?  How will the divergence of the effected
customers impact future upgrades?

Managed source isn't just for emergency preparedness and
software-OEMs: it's also an enabler for more customer-employed and
customer-contracted engineering -- a larger free software developer
community that, by growing, decentralizing, and moving closer to
customers, gives them a family of products that is more flexible, more
rapidly responsive to their needs, and more rapidly improving.