GNUPro

We decided that we needed to achieve economies of scale before burnout became a real problem. And, thinking like engineers, we decided that the fastest way to achieve these economies of scale was to ruthlessly focus on the smallest set of open-source technology that we could reasonably sell as a useful solution. The smaller the focus, we reasoned, the easier it would be to achieve some concept of scale.

First, establish a firm base.

Sun Tzu

Throwing away plans to support shell tools, file utilities, source code control software, and even plans to write a free kernel for the Intel 386, we settled on selling the GNU compiler and debugger as a shrink-wrapped product. There were a dozen or so companies that sold third-party 32-bit compilers, and there were another dozen internal compiler groups at companies like Sun, HP, IBM, etc. Adding up the numbers, we felt that if we could take over the 32-bit compiler market, we'd be big enough to do all the other cool things we had envisioned from the outset (a full-on Open Source play, analogous to the EDS outsourcing model for IBM systems).

The GNU compiler already supported dozens of host environments and over a dozen target architectures (I had written six of the ports myself ), making it one of the most widely ported compilers of its time. The GNU debugger ran on about five native platforms, and several people had adapted it to support embedded systems as well. We naively assumed that making a shrink-wrapped product was a mere matter of collecting bits onto a single distribution, writing a README, adding an install script, getting some product collateral, testing it, and shipping it. The reality was far more challenging.

First, GCC was in the process of transitioning from Version 1.42 to Version 2.0. While GCC Version 1 was good enough to beat most compilers on CISC machines like the m68k and the VAX, lots of new optimizations were needed to make it competitive on RISC platforms. When I did the first GCC port to the SPARC in 1988, GCC was 20% slower than Sun's compiler. I wrote an instruction scheduler in 1989 that narrowed the gap to 10%, and I worked on a branch scheduler that same year that, with the instruction scheduler, got GCC to within 5% of Sun's compiler. With the world transitioning from CISC to RISC, we went from having hands-down the best compiler in almost every regard to a more complex set of tradeoffs the customer would have to evaluate. It was no longer a simple, straightforward sell.

Second, GNU C++ was falling behind. I wrote GNU C++ in the fall of 1987, making it the first native-code C++ compiler in the world. C++ was a much more complex language than C, and it was still evolving when we started Cygnus. In 1990, several new, even more complex features became ``standard,'' and with all the distractions of Cygnus, I had no time to keep GNU C++ current.

Third, GDB was all over the map. While GCC and G++ had remained reasonably coherent, with regular releases being made from a central location, GDB suffered fragmentation. Open-source opponents will argue that a benefit of proprietary software is that there's only one ``true'' version, whereas open-source software can fragment into a million out-of-sync releases, not one of them a legitimate ``standard.'' Because there was no strong maintainer of GDB, it fragmented, with hundreds of people around the world making their own versions to meet their own needs.

Fourth, we did not in fact have a complete toolchain: we had an assembler, linker, and other binary utilities (a.k.a. binutils) that worked on some, but not most, of the platforms supported by GCC and GDB. By the time you took the platforms that GCC supported, intersected that with GDB's supported platforms, intersected with GAS, GLD, and so forth, there were exactly zero platforms that worked from a common source base.

Fifth, we had no C library, which was not a problem for native platforms like the Sun or HP, but a Big Deal for embedded systems developers who needed its functionality for their standalone applications.

Sixth, while our competitors had nothing that could match our just-in-time engineering feats, each of them had already-complete products that they sold very effectively in their respective niches. By building and selling a shrink-wrapped product, we were changing our attack plan from an elaborate flanking maneuver to a frontal assault against companies that had 10 to 100 times our revenues.

And finally, there was the matter of our own confidence. The nice thing about being the integrators of many quickly evolving tools is that the need for your services is so obvious. Skeptics challenged the very notion of a shrink-wrapped Open Source product by claiming that as soon as we produced anything of passing quality, there would be no need for our support business, and we'd be out of business in six months. It was a challenge to our business I would hear for the next four years.

The world is full of insurmountable opportunities.

Yogi Berra

There was nothing to do but to go for it, and with an initial estimate of 6 months to do the work, we all agreed to ``double up'' and make it happen. I was tasked with growing the top line by day, and helping complete the work for GCC 2.0 and G++ by night. David Henkel-Wallace (a.k.a. Gumby), the second Cygnus founder, took on the so-called binutils and the library in addition to his duties as CFO and Director of Support. And John Gilmore, the third Cygnus founder, took on GDB. We hired some new people to help us (1) put the whole works into CVS (an open-source source code control system), (2) write configuration and installation scripts that could handle the hundreds of possible platforms our shrink-wrapped product might work on, (3) automate our testing procedures, and (4) help us with the heavy lifting on the new development contracts that we were closing at an accelerating rate.

Six months later, the job had inexplicably grown, and some people had grown bored with our strict (some would say restrictive) product focus. While the GNU product was the bulk of our sales and engineering efforts, we sold contracts for other technology, such as Kerberos (network security software), Emacs, and even our bug tracking and test framework software (which was still under development at that time).

John had sent a message to the Net saying essentially ``I'm going to be the new GDB maintainer. If you want the features you've implemented in GDB to be maintained in the next version, send me your complete GDB sources and I'll figure out how to integrate them.'' In six weeks, he collected 137 versions of GDB (mostly hacks to Version 3.5), all of which had one or more features that needed to be integrated. John began designing the architecture for GDB 4.0 to support all of these features. Who was I to argue that it couldn't be done?

Gumby had decided that all the binary file utilities should use a common library that described all known object file and debugging formats. The reason behind this decision was clear when one looked at the functionality of the various tools that sit behind the compiler:

Tool	Reads	Writes
Compiler	ASCII	ASCII
Assembler	ASCII	Binary
Archiver	Binary	Binary
Linker	Binary	Binary
Size	Binary	Binary
Strip	Binary	Binary
Binary	Binary	Binary
Nm	Binary	Binary
Debugger	Binary	none

Each tool had its own implementation for reading and/or writing binary file formats, and each of these implementations had varying levels of support for each binary format: a.out, b.out, coff, ecoff, xcoff, elf, ieee695, and others. Moreover, when each tool was configured it supported only a single kind of binary file format. A fix to the m68k-a.out assembler might also need to be made in all the other a.out-specific tools, or it might need to propagate as a object file-independent change. Depending on how a utility was written, it might be an a.out-specific change for one tool, and a generic change for another!

By building a single library that supported all functionality from a single source base, it would be possible to achieve economies of scale sooner because everything could be factored and maintained in a consistent fashion. Besides, it would be neat to demonstrate the ability to link a.out object code to a coff library and generate an ieee695 executable! Gumby began designing the library and discussing the design with Stallman. Stallman said that the job was too difficult -- it would require a complete rewrite of all the tools, and it would be too difficult to maintain. Gumby told him it wasn't such a ``Big F*cking Deal'' and hence named this new creation the BFD library. (We explained to our customers that BFD stood for the binary file descriptor library.)

But while John and Gumby hacked, I still had to sell contracts to keep cash coming in. Every quarter I would have new top-line goals that required more resources to fulfill more contracts, and all the best engineers were tied up on this release into which I had no visibility. Tensions rose between sales and engineering while the Open Source model seemed be working in reverse: the more development we did on GNU software, the less we got back from the Net, until we were doing over 50% of all GNU toolchain development.

Neither was this a temporary state of affairs. It would take a year and a half (!) before the first ``Progressive Release'' was finally completed. On that momentous day, I was assured that for the first time, a complete C and C++ development toolkit could be built from a single source base, and that we could support two platforms: the Sun3 and the Sun4. I was dumbfounded. I had written 6 GCC ports, 3 GDB ports, and a native-code C++ compiler and debugger in less time than it took a team of hackers to get two toolchains to work from a single source base!?

There were two mitigating facts: (1) the tools worked better than they ever worked before, with many new and useful features, and (2) because of all the infrastructure work we'd put into the job (not just rewriting the tools, but implementing a configuration script and an automated testing framework), we could expect to support many more host/target combinations in the future, including a virtually unlimited range of embedded system platforms.

We put this framework to the test, and it passed with flying colors:

Date	Release	Native	Embedded	Total
	Name			Platforms
Mar 1992	p1	2	0	2
June 1992	p2	5	0	5
Sep 1992	p3	5	10	15
Dec 1992	p4	5	20	25
Mar 1993	q1	5	30	35
Jun 1993	q2	5	45	50
Sep 1993	q3	7	53	60
Dec 1993	q4	8	67	75
Mar 1994	r1	10	75	85
Jun 1994	r2	10	80	90
Sep 1994	r3	10	85	95
Dec 1994	r4	10	90	100

While the engineers were doing great things to create the GNUPro product, our sales team was working out how to sell it. In 1991, we hired a young business student, recently laid off from Applied Materials, who wanted to learn how to sell software. Though her native language was not English, she picked things up very quickly. By no means a hacker (though she spent some weekends at Cygnus teaching herself to program in C), she nevertheless became a really strong advocate of the Open Source approach. After six months of very successful selling, she invited me to see her make a customer presentation. I was floored. I had always sold Open Source the way a hacker would sell it: focusing mainly on the technical merits. She explained the intrinsic complexity of the job we were doing and the business value of the software we delivered, and this helped us finally explain to customers why they should buy from us instead of trying to do the work with their own people. I was selling the fact that our engineers were somehow better than theirs (not a message most managers want to hear), whereas she could explain how their engineers would benefit from having us do the baseline porting, support, and maintenance work. In the end, the mix of our technical prowess and business benefits led to equally powerful sales accomplishments:

Bookings ($K)	Profitability (%)	Cumulative CAGR
1990: 725	epsilon	N/A
1991: 1500	1	106%
1992: 2800	2	96%
1993: 4800	3	87%
1994: 5700	4	67%

Watson! Come here!

Alexander Graham Bell

Out of this effort has come significant new technologies that have been returned to the Net and become standards in their own right: GNU configure (a generic configuration script that can configure software based on three independent variables: a build platform, a host platform, and a target platform), autoconf (a higher-level script for creating configure scripts), automake (a makefile generator for autoconf-driven environments), DejaGNU (a regression testing framework), GNATS (a problem report management system), and others.

Today, the GNUPro toolkit supports over 175 host/target combinations, a number that is now limited by the actual diversity of the market, not a limitation in our release or configuration technology.

In fact, GNUPro has become so dominant that several of our competitors have announced their intention to sell commercial support for GNU software to compete with us! Fortunately, the Open Source model comes to the rescue again. Unless and until a competitor can match the 100+ engineers we have on staff today, most of whom are primary authors or maintainers of the software we support, they cannot displace us from our position as the ``true GNU'' source (we supply over 80% of all changes made to GCC, GDB, and related utilities). The best they can hope to do is add incremental features that their customers might pay them to add. But because the software is Open Source, whatever value they add comes back to Cygnus as open-source software, for us to integrate if it's good, or ignore if it's not. Unlike proprietary software in which competitors fight in a two-sided win/lose contest, with Open Source it's more like fighting on a Moebius strip, and everything flows to the side of the primary maintainer. So, while our competitors may get some tactical advantage in the ``me-too'' GNU space, Cygnus benefits in the long run. Founded in 1989, our first-mover advantage is ten years ahead of the competition.