Subject: Re: Cygnus
From: John Gilmore <gnu@toad.com>
Date: Thu, 20 May 1999 18:37:50 -0700

Not every Cygnus product is open source (e.g. they have a proprietary
debugger), but most of them are.

When I was there, it was common practice for the developers to test
their own components (e.g. GCC, GDB, Linker) and then release them as
GNU releases.  A week or two after the GNU release, after the world's
users had pointed out any major problems and we had patched them, the
"development" source tree was transferred into the "release" source
tree, and the more rigorous 100-host-target-combinations automated
build/test cycle begun.  After a month or six weeks of that, including
fixing any problems found, the customer release would be cut: tapes
made, manuals printed, eventually CD's burned.  A few weeks later it
would start up all over again; we were cutting quarterly software
releases back then (4 per year).  Cygnus built the tools that
automated these fast, solid releases, including DejaGnu for regression
testing in both hosted and embedded environments; "configure" scripts
and the architecture-system-opsys triples that still frequently define
GNU configurations; a source tree that would automatically build
dozens of GNU components and install them coherently.  Oh, and remote
CVS so our developers could work from anywhere, and Gnats for bug
tracking.

All of these benefits were released to the GNU community.

Cygnus occasionally built features in GNU software that it couldn't
release publicly yet.  Usually these were new support for some chip
maker's unannounced architecture.  For example the UltraSPARC
(sparcv9) was supported by GCC and the binutils long before it was
announced; Sun built some of their hardware diagnostic programs with
these GNU tools.  Cygnus had a convention for marking such additions
in the sources, and for sanitizing a source tree so that it includes
none, one, or several of these as-yet-unreleased features.  The
contracts that Cygnus wrote permitted Cygnus to release the software
eventually, particularly after we almost got burned by some
long-delayed projects.  Generally nobody would get these features
except the customer paying for them (and their customers, if needed).
Each recipient was free to pass them on under the GPL.  For general
distribution they always waited until the feature was announced, and
in the next GNU and Cygnus release it would come out.  (It's a pain to
keep parts of the code separately maintained; Cygnus would always
release these features as soon as it could.)  At all times the
software was GPL, and in no case were binaries shipped that we
couldn't supply matching sources for.

Cygnus would sell its releases to anyone ($1000 on popular platforms,
with support) and anyone who bought them could put them up for free
downloading.  The fact that nobody did makes it likely that nobody was
sufficiently disgruntled, i.e. they were getting 99% of the value in
the GNU releases already.  Today you can get Linux compilers from
Cygnus for $79, in a box at Fry's (or from www.cygnus.com).  Buy one
and put up a copy on the Web if you like.

Why do people pay Cygnus money for all this?  Two main reasons:

  * They aren't compiler experts, and they want to be able to depend
on these compilers for something that matters very much to them (like
Cisco's next OS release, or Sony's PlayStation II games).  Such projects
frequently cost the company millions of dollars in sales for every day
of delay; sometimes an entire market can be lost by not being first to
ship.  Cygnus responds very quickly to technical problem reports and
gets critical customer projects off the shoals of unreliable tools.
This "insurance" is worth significant fractions of a million dollars
to such companies.

  * They aren't compiler experts, and they want to be able to depend
on these compilers for something the compilers can't do today.  Sony
wanted compilers, emulators, and debugging tools for hardware they
hadn't even built yet, so that game vendors could work on hot games
long before the hardware was available.  Many chip vendors wanted GNU
tools that work as well for their chips as the tools do for popular
platforms like M68K or SPARC.  Cygnus would estimate the difficulty of
each job and the value to the customer, price it to make money, and if
accepted, do the work.  Sometimes, as in the case of MIPS or Solaris
support, Cygnus had to find several companies who would all benefit
from having the support, and convince each of them to contribute part
of the cost.  Market rates for developing a basic set of tools for a
new microprocessor were in the $500K to $1000K range in 1990, and the
standard price for proprietary tools -- AFTER paying for the
development -- was $10K/user.  Cygnus found it fairly easy to beat
that initial price, due to its low overhead, very talented
programmers, and well designed GNU tools to start from.  The cost of
the Cygnus tools to users afterward was much cheaper, ranging down to
zero, which was a big benefit to the chip makers (who make their money
on chips, and don't want a high tool price to be a disincentive for
people to think about using their chip).  Ten years later, it's a
market requirement to have a well-supported GNU compiler for any new
chip that hopes to break into the embedded market.  All of these
improvements came out to the public as free software.

So if you want to start a free software company, find a niche where
the current proprietary vendors are fat and lazy, overcharging for
poor technology.  Write a solid free version using modern technology
(the GNU coding standards, e.g. no limits on object sizes, are a good
start).  Kick your code out onto the net where people will find and
use it.  Partner with people who know how to market and sell, but rein
them in so they don't try to take your code proprietary, which will
always be their first instinct.  You will find companies who depend on
your tools, and others who want to pay you to make slightly different
tools.  There are plenty of markets available where you can "do well
by doing good".

	John Gilmore