Open Sources

Chapter 6. Future of Cygnus Solutions: An Entrepreneur’s Account

Michael Tiemann

Founded in 1989, Cygnus Solutions was the first, and according to a survey by Forbes magazine in August 1998, is by far the largest Open Source business today. Cygnus has established its primary product, the GNUPro Developers Kit, as both the leading compiler product and the leading debugger product in the embedded software tools market. Cygnus customers include the world’s top microprocessor companies as well as leading consumer-electronics, Internet, telecommunications, office automation, networking, aerospace, and automotive companies. With headquarters in Sunnyvale, CA, and offices in Atlanta (GA), Boston (MA), Cambridge (UK), Tokyo (JP), Toronto (CN), and remote employees working from various locations ranging from Australia to Oregon, Cygnus is the largest privately held company in the embedded software industry, larger than two publicly-held companies and about to overtake the third largest. With a CAGR greater than 65% since 1992, Cygnus has been on the San Jose Business Journal’s Top 100 Fastest Growing Private Companies three years in a row, and now ranks on the Software 500 list (based on revenue of all software businesses in the world).

In this essay, I will describe the Open Source model that provided the blueprint for our success, and how we are revising and enhancing it for our future endeavors.

It wasn’t until November 13th, 1989 that we finally received the letter from the California Department of Corporations informing us that our application had been approved, and that we could deposit our $6,000 startup capital and begin transacting business as “Cygnus Support.” That day was the culmination of a vision that began more than two years earlier, and the beginning of a journey which continues today, almost 10 years later.

The vision began innocently enough. My dad once told me, “If you’re going to read a book, make sure you read it cover to cover.” Like most fatherly advice, I applied it only when it suited me, and in 1987, when I had become bored with my job and interested in GNU software, I decided to read Richard Stallman’s self-published book GNU Emacs Manual cover to cover. (This book was self-published because at that time, no self-respecting publisher would print a book that encouraged people to freely make legal copies of the text. In fact today, it’s still a difficult concept for some publishers to grasp.)

Emacs is a fascinating program. More than a text editor, it has been customized to let you read and respond to email, read and post to newsgroups, start a shell, run compilations and debug the resulting programs, and it even gives you interactive access to the LISP interpreter that drives it. Creative users (or similarly bored hackers) have extended emacs with whimsical features, such as “doctor” mode (a Rogerian psychoanalytic program inspired by John McCarthy’s ELIZA program), “dissociated-press,” which scrambles text in a way that makes for difficult and sometimes hilarious reading, and even a program that will animate the solution of the Towers of Hanoi on a text screen. It was this depth and richness that drove me to want to learn more, to read the GNU Emacs Manual and the GNU Emacs source code.

The last chapter of the book, “The GNU Manifesto,” was a personal answer from the author to the overarching question that nagged throughout my entire reading: why is such a cool program available as freely redistributable software (a.k.a. Open Source)? Stallman answers in the general question:

Why I Must Write GNU

I consider that the golden rule requires that if I like a program I must share it with other people who like it. Software sellers want to divide the users and conquer them, make each user agree not to share with others. I refuse to break solidarity with other users in this way.

There is much more to Stallman’s manifesto—too much to quote here. (A reference is http://www.fsf.org/gnu/manifesto.html.) Suffice it to say that on the surface, it read like a socialist polemic, but I saw something different. I saw a business plan in disguise. The basic idea was simple: Open Source would unify the efforts of programmers around the world, and companies that provided commercial services (customizations, enhancements, bug fixes, support) based on that software could capitalize on the economies of scale and broad appeal of this new kind of software.

Emacs was not the only mind-blowing program to come from the Free Software Foundation. There was the GNU Debugger (GDB), which Stallman had to write because the debuggers from Digital Equipment Corporation (now part of Compaq) and Sun Microsystems were simply not up to the task of debugging something as complex as Emacs. Not only could it handle big tasks, but it handled them elegantly, with commands and extensions that were geared towards programmers. And because GDB was open-source software, programmers began adding more extensions that made GDB even more powerful. This was a kind of scalability that did not exist in proprietary software.

The real bombshell came in June of 1987, when Stallman released the GNU C Compiler (GCC) Version 1.0. I downloaded it immediately, and I used all the tricks I’d read about in the Emacs and GDB manuals to quickly learn its 110,000 lines of code. Stallman’s compiler supported two platforms in its first release: the venerable VAX and the new Sun3 workstation. It handily generated better code on these platforms than the respective vendors’ compilers could muster. In two weeks, I had ported GCC to a new microprocessor (the 32032 from National Semiconductor), and the resulting port was 20% faster than the proprietary compiler supplied by National. With another two weeks of hacking, I had raised the delta to 40%. (It was often said that the reason the National chip faded from existence was because it was supposed to be a 1 MIPS chip, to compete with Motorola’s 68020, but when it was released, it only clocked .75 MIPS on application benchmarks. Note that 140% * 0.75 MIPS = 1.05 MIPS. How much did poor compiler technology cost National?) Compilers, Debuggers, and Editors are the Big 3 tools that programmers use on a day-to-day basis. GCC, GDB, and Emacs were so profoundly better than the proprietary alternatives, I could not help but think about how much money (not to mention economic benefit) there would be in replacing proprietary technology with technology that was not only better, but also getting better faster.

Again, a quote from the GNU Manifesto:

There is nothing wrong with wanting pay for work, or seeking to maximize one’s income, as long as one does not use means that are destructive. But the means customary in the field of software today are based on destruction.

Extracting money from users of a program by restricting their use of it is destructive because the restrictions reduce the amount and the ways that the program can be used. This reduces the amount of wealth that humanity derives from the program. When there is a deliberate choice to restrict, the harmful consequences are deliberate destruction.

The reason a good citizen does not use such destructive means to become wealthier is that, if everyone did so, we would all become poorer from the mutual destructiveness.

Heavy stuff, but the GNU Manifesto is ultimately a rational document. It dissects the nature of software, the nature of programming, the great tradition of academic learning, and concludes that regardless of the monetary consequences, there are ethical and moral imperatives to freely share information that was freely shared with you. I reached a different conclusion, one which Stallman and I have often argued, which was that the freedom to use, distribute, and modify software will prevail against any model that attempts to limit that freedom. It will prevail not for ethical reasons, but for competitive, market-driven reasons.

At first I tried to make my argument the way that Stallman made his: on the merits. I would explain how freedom to share would lead to greater innovation at lower cost, greater economies of scale through more open standards, etc., and people would universally respond “It’s a great idea, but it will never work, because nobody is going to pay money for free software.” After two years of polishing my rhetoric, refining my arguments, and delivering my messages to people who paid for me to fly all over the world, I never got farther than “It’s a great idea, but . . .,” when I had my second insight: if everybody thinks it’s a great idea, it probably is, and if nobody thinks it will work, I’ll have no competition!

-F = -MA

—Isaac Newton

You’ll never see a physics textbook introduce Newton’s law in this way, but mathematically speaking, it is just as valid as “F = ma”. The point of this observation is that if you are careful about what assumptions you turn upside down, you can maintain the validity of your equations, though your result may look surprising. I believed that the model of providing commercial support for open-source software was something that looked impossible because people were so excited about the minus signs that they forgot to count and cancel them.

AN INVASION OF ARMIES CAN BE RESISTED, BUT NOT AN IDEA WHOSE TIME HAS COME.

—Victor Hugo

There was one final (and deeply hypothetical) question I had to answer before I was ready to drop out of the Ph.D. program at Stanford and start a company. Suppose that instead of being nearly broke, I had enough money to buy out any proprietary technology for the purposes of creating a business around that technology. I thought about Sun’s technology. I thought about Digital’s technology. I thought about other technology that I knew about. How long did I think I could make that business successful before somebody else who built their business around GNU would wipe me out? Would I even be able to recover my initial investment? When I realized how unattractive the position to compete with open-source software was, I knew it was an idea whose time had come.

THE DIFFERENCE BETWEEN THEORY AND PRACTICE TENDS TO BE VERY SMALL IN THEORY, BUT IN PRACTICE IT IS VERY LARGE INDEED.

—Anonymous

In this section, I will detail the theory behind the Open Source business model, and ways in which we attempted to make this theory practical.

We begin with a few famous observations:

FREE MARKETS ARE SELF-ORGANIZING, PERMITTING THE MOST EFFICIENT USE OF RESOURCES FOR THE GREATEST CREATION OF VALUE.

—Adam Smith

INFORMATION, NO MATTER HOW EXPENSIVE TO CREATE, CAN BE REPLICATED AND SHARED AT LITTLE OR NO COST.

—Thomas Jefferson

The concept of free market economics is so vast that I often like to joke that each year when it comes time to award the Nobel prize in economics, it goes to the economist who most eloquently paraphrases Adam Smith. But behind that joke lies a kernel of truth: there is untapped and unlimited economic potential waiting to be harnessed by using a more true free market system for software.

In the days of Adam Smith, free market economics went as far as one could travel or trade in person, but larger trades, especially trades between nations, were heavily controlled. When a sufficient number of business people became disenchanted with the prevailing royalty-based system, they revolted and created a new government that was designed to take less interest in their affairs than almost any government that had come before it. Indeed, it was freedom that provided the underlying architecture and vision of the Constitution of the American government, and freedom again that seems to be at the root of every important cause or action in today’s global economic and political arena. What makes freedom so compelling? And what has made freedom so responsible for economic prosperity? We will address these questions shortly.

THE MORE YOU UNDERSTAND WHAT IS WRONG WITH A FIGURE, THE MORE VALUABLE THAT FIGURE BECOMES.

—Lord Kelvin

Clearly, when it came to tools for programmers in 1989, proprietary software was in a dismal state. First, the tools were primitive in the features they offered. Second, the features, when available, often had built-in limitations that tended to break when projects started to get complicated. Third, support from proprietary vendors was terrible; unless you were in the process of buying lots of hardware or renewing a large software site license, and could use the power of the purse to your advantage, you were out of luck when you ran into one of these built-in limitations. And finally, every vendor implemented their own proprietary extensions, so that when you did use the meager features of one platform, you became, imperceptibly at first, then more obviously later, inextricably tied to that platform. All in all, it was quite clear that whatever the merits of free market economics, they were not at work in the software marketplace. The extent to which the proprietary software model was a broken model made the study of that model extremely valuable indeed.

Today, as then, free market economics lives within the walls of proprietary software companies (where competing engineers and product groups vie for funding and favor). Outside their proprietary walls, the use and distribution of that software is heavily controlled by license agreements, patents, and trade secrets. One can only wonder what power, what efficiency is lost by practicing freedom at the micro level, and not at the macro level. By starting a company prepared to support users at the level of source code, we were going to find out.

INVENTION IS 1% INSPIRATION AND 99% PERSPIRATION.

—Thomas Edison

The simplistic view of a software company is that once you’ve created some software that people want to buy, the act of printing copies of that software and distributing it is not unlike printing money: the cost of goods is negligible, and the margin nearly perfect. I believe that one reason software reached such a poor state of affairs in the 1980s was that people focused on perfecting the abstract model of printing money, without concern for what happened once people actually started using the currency. The concept of software support was seen as a degenerate by-product of some flaw in the software product process, and that by minimizing software support investment, one could maximize profits.

This not only frustrated users, but it was bad for the software as well. Features that were easy to implement were often dismissed as “non-strategic.” Without access to source code, features that customers would otherwise be able to implement themselves remained points of speculation and contention. And ultimately vendors (and their marketing departments), not customers, defined the arena of competition with a myriad of useless but easy-to-express features. Free market economics had been turned upside down.

NOBODY HAS A MONOPOLY ON THE TRUTH.

—Anonymous

COMMON LAW IS LEGAL CODE THAT IS FREE TO ALL PEOPLE EQUALLY.

—Michael Tiemann

It is all very well and good to have wonderful theories about how to make the world a better place. It is another thing entirely to get those theories funded to the point that they are self-sustaining. Although service-based companies were rare in the world of software products, there were many cases to study in other areas.

Consider the practice of law in America (or Great Britain). Common law is freely available to all who wish to use it. One need not license a decision such as Roe v. Wade in order to use it for arguments. Indeed, the decisions, once made, and at whatever cost, are free to all. Yet for all this freedom, lawyers are among the most expensive professionals to be found. How can a practice of law, which has no primary proprietary code, command such value?

It is not just the act of prosecuting law that people value so highly. It is also the cumulative value of that prosecution. If you hire a good lawyer, and in the course of the prosecution, a decision is made in your favor, that precedent becomes a new part of the law. Justice is not blind; it is full of history.

This is somewhat analogous to the concept of creating and maintaining standards with open-source software. It is very expensive to create a standard and get it right. But it is far more expensive to work without standards or to try to maintain a standard if the standard is bogus. There is great value in having good people working on software whose precedents will set the standards of tomorrow. We believed at the beginning that people would understand this value proposition, and would value the opportunity to pay us to create high-quality, open-source programs that would become the de facto standard of the software world.

Cygnus in the Early Years

Having mapped out the theory, it was time to put the theory into practice. Creating a service-based business is easy enough, if you know anything about business. Unfortunately, between the three founders of Cygnus, not one had any experience in running a business.

ALWAYS MAKE NEW MISTAKES.

—Esther Dyson

We used books from the Nolo Press to incorporate our business, establish our by-laws, and complete various other formalities. For every penny we saved in the first year, we paid out dollars by the thousands later on down the road. (It’s not clear that we could have done any better hiring professional advice since the first such advice we received cost us hundreds per hour, and still cost us tens of thousands later to fix. For the most part, that still says more about our inability at the time to properly judge the scope of legal/corporate problems and to request the proper advice than it does about the particular incompetence of the many lawyers we tried talking to.)

Having created a completely new business model, we also created our own concepts of finance, accounting, marketing, sales, customer information, and support. Each of these creations served us adequately in the first year of business, where everything was chaotic, and everybody was focused on doing whatever job was necessary to get the business off the ground, but each needed to be completely retooled as the business grew.

CYGNUS—WE MAKE FREE SOFTWARE AFFORDABLE

—John Gilmore

To combat the chaos, we worked hard to make the basic business premise as simple as possible: we were going to provide proven technical support for proven technical software, and we were going to use economies of scale to make it profitable. In our estimation, we were going to provide two to four times the quality of support and development capabilities that in-house people could deliver, and we were going to provide these services for a half to a quarter of the cost. We downplayed all the other stuff about open-source software because it was far too nebulous to sell. We just focused on giving people better tools for less money, and contract by contract, we learned how to do that.

We wrote our first contract in February of 1990, and by the end of April, we had already written over $150,000 worth of contracts. In May, we sent letters to 50 prospects we had identified as possibly interested in our support, and in June, to another 100. Suddenly, the business was real. By the end of the first year, we had written $725,000 worth of support and development contracts, and everywhere we looked, there was more opportunity.

For all this success, we were brewing some serious problems. If we were selling our services for half to a quarter what an internal resource would cost, then were writing contracts that would cost in total between $1.5M to $3M to deliver, yet we only had five people in the whole company: one sales person, one part-time graduate student, and three founders doing everything from Ethernet wiring to letterhead proofing. How big would the business have to be before economies of scale really kicked in? At its current rate of growth, how many more all-nighters would we have to pull to get to that point? Nobody knew, because we didn’t have any financial or operational models.

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 Name	Native	Embedded	Total Platforms
Mar 1992	p1	2	0	2
June1992	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.

Challenges

As can be seen from the chart above, while our growth rate remained impressive, it slowed as we grew. While we tried to sell the merits and value of Open Source software, skeptics and potential customers challenged our model with respect to:

Sanity

Why would a customer pay for a competitor’s advantage?

Scalability

How can a service-based business scale?

Sustainability

Will Cygnus be around when customers need it?

Profitability

How can open-source software be profitable?

Manageability

How can open-source software be managed to deliver quality consistently?

Investibility

How can a company with no software IP ever attract investors?

Can you imagine trying to sell a $10,000 support contract to a manager of five embedded systems programmers, and getting hung up on whether or not Cygnus can go public based on its business model? For all that Open Source was a great way to open doors into the best and most innovative software development groups, it proved to be a major roadblock when selling to the mainstream market. We were about to learn first-hand what Geoffrey Moore meant in his book Crossing the Chasm.

This challenge became absolutely clear when I visited a group of developers who were building wireless communications systems at a Fortune 100 company. As part of their quality process, they not only evaluated their own quality, but the quality of their vendors according to a number of metrics. Of all the different vendors with whom they did business, most ranked “Very Good to Excellent” in most or all of the metrics. Their supplier of embedded tools, however, placed dead last with “Poor or Unacceptable” in all categories for each of the three years this quality monitoring process had been in place. Yet they would not buy our tools because despite our testimonials (from their customers, no less!), superior technical features, and lower price, management did not want to go with an unknown solution. I left wondering why they even bothered to collect data if they’d never use it to act, but that was the wrong question. I should have instead realized that this was typical mainstream behavior, and that the way to fix the problem was not to fault the customer, but to improve our marketing and messaging.

Our problems were not solely external, however. Many customers did not believe that we could hire enough people to scale our support business much beyond whatever we told them was our current state. They were both quite wrong and quite right. When it came to hiring engineers, they were quite wrong. Cygnus was founded by engineers, and our culture, Open Source business model, and the opportunity to join the preeminent Open Source engineering team in the world has always made Cygnus attractive to the developers we’ve wanted to hire. Turnover, compared to the national average (and especially compared to the average in Silicon Valley) is something like a quarter to a tenth what other companies experience.

But when it came to hiring managers, it was another story altogether. Sharing many of the same concerns and prejudices that our mainstream customers expressed, most managers we contacted had no interest in working for Cygnus. Those that did were not attracted to it. Those who were attracted to it were often attracted to it for the wrong reasons. By the time we had two managers in our engineering department, we had over 50 engineers. Communication, process, management controls, and employee satisfaction all declined as managers struggled, often unsuccessfully, to come to grips with what it meant to be and manage an Open Source company.

Ironically enough, we also disqualified managers who could not accept creating a closed-source component to our business. Open Source was a business strategy, not a philosophy, and we did not want to hire managers who were not flexible enough to manage either open or closed source products to meet overall company objectives.

We have come to accept the fact that you cannot expect to hire managers who understand all the implications of open-source software right away. You have to expect them to make mistakes (which means you have to budget for the costs of those mistakes), and they have to be able to learn from those mistakes. Most managers who bring experience with them try to change things to fit that experience—a recipe for failure at Cygnus. It was very hard to find managers who could both manage from, and quickly learn from, experience. And we needed them by the dozens.

The Open Source model, for all its challenges, proved to be remarkably resilient. Though we did occasionally lose customers through poorly set expectations or poor execution, our annual renewal rate has remained roughly 90% by dollar value since 1993, and the number one reason we lose customers is “retirement”: the conclusion of the customer’s project. Two factors helped us survive where other companies would have failed: (1) every person, regardless of title or seniority, recognized the importance of meeting customer commitments (nobody was “above” doing customer support), and (2) when all else failed, the customer was empowered to help themselves (because all customers had source code). Thus, despite amazing amounts of turmoil inside Cygnus in those days, very few customers were ever left holding the bag because the software failed to deliver, a stunning contrast to stories we heard about our proprietary competition as well as people who used unsupported open-source software.

Getting Funded Beyond Open Source—eCos

The reality of the embedded systems world is that there are a relatively small number of companies that make the silicon and there are a relatively small number of Outside Equipment Manufacturers (OEMs) who buy the majority of the silicon for use in their embedded systems products. The rest of the market consists of a large number of small-volume players who build interesting stuff, but they do not drive the volumes necessary to mandate new chip designs or software solutions.

Between the semiconductor vendors and the OEMs there are hundreds of little software companies, all of whom are selling their wares. For example, there are over 120 commercially supported Real Time Operating Systems (RTOSes) in the market today. Not one of these RTOSes has more than a 6% market share, according to IDC. It’s like the Unix world ten years ago, only twenty times more fragmented! This fragmentation leads to all the classic degenerative cases of free market economics: redundancy, incompatibility, price gouging, etc. What the semiconductor vendors and the OEMs wanted were standards that would accelerate TTM (time to money), and the commercial RTOS vendors were either taking too much time, costing too much money, or both.

In the embedded systems market we were the rising star: we were growing twice as fast as the leader in our market, and we were keeping our top four competitors to single-digit growth. Yet we were not treated like, nor did we act like, true market leaders. In 1995, after many conversations with our key customers about what did and did not work in their embedded systems world, we began to understand that our GNUPro compilers and debuggers could only go so far in addressing their problems. What customers needed was a silicon abstraction layer—a layer of software that sat underneath the standard C library or a real-time POSIX API. There was a new opportunity to expand our product offering in a non-trivial way.

We sharpened our pencils and took note of the obvious: 120+ commercial RTOSes and 1000+ in-house RTOSes meant that at the technical level nobody had yet built a sufficiently configurable RTOS to achieve “one size fits all,” and from a business perspective we noted that run-time royalties were killing margins, so the RTOS had to be royalty-free. In other words, to consolidate the market around our solution, we needed to create a completely new, world-class technology, and we needed to give it away. Management kicked the idea around for a year before finally acting on it.

Once we did decide to go forward with this strategy, our management team continued to wrestle with the question “How is it going to make money?” Even as we continued to consolidate the market around GNUPro, it was not obvious to the team how we could repeat that model for an embedded operating system.

We did the smart thing that any business does when faced with a completely inconsistent problem: we made assumptions. Assuming we would figure out how to make money, we asked ourselves what were the N other things we needed to do in order to solve our customers’ problems and become #1 in the market? (1) We needed to develop this whizzy new configuration technology, (2) we needed to build the rest of the system so that people would have something to configure, and (3) we needed to do all of this before the market opportunity evaporated. Software development costs money, and product-oriented software development on a timetable costs lots of money.

When we started Cygnus, we had all assumed that the VCs would never understand what we did, and if they did, it would not be until five or more years down the road, when there was nothing useful they could do for us. Happily, we were wrong on both counts.

Our first outside board member, Philippe Courtot, wasted no time in introducing me to leading VCs in early 1992. I was very open with each of them about our model, technology, and goals for the future, and I was equally open about the fact that we had designed Cygnus to be self-funding and hence did not need their money. Indeed, the fact that we could increase profitability a percentage point per year while growing the company at 80% per year was a pretty good indication (as far as I was concerned) that we were maturing the business nicely. Roger McNamee, a leading software industry analyst for the VC community, said it best when he said “I am both amazed and surprised by your business model. I am amazed at how well it is working, but the more I think about it, the more surprised I am that I didn’t think of it first!”

While it was gratifying to think that we had aced the problem and didn’t need outside funding, the reality was that by 1996, we had created so much opportunity beyond our self-funding GNUPro business that we needed a new plan and new partners.

We found two investors, Greylock Management and August Capital, who understood what we did and how we did it, understood what we could do with the right guidance and discipline, and had access to enough capital to execute our plan. They invested $6.25M, the largest private placement for a software company in the first half of 1997, and the execution began in earnest.

I DO NOT LIKE THEM, SAM-I-AM. I DO NOT LIKE GREEN EGGS AND HAM.

—Dr. Seuss

While the technical team ramped up, the business people continued to thrash on how the money was going to work, because at first we did not see the connection between the architecture of eCos and the business model we could use to commercialize it. On the technical front, we knew that the configurability of the system was key to delivering a “one size fits all” architecture. On the business front, we knew that a “one size fits all” was key to creating a unifying and beneficial standard for embedded systems development. But we still could not figure out who was going to pay for this benefit. The two sides worked on their problem independently for a year and a half. R&D costs mounted. Unable to reconcile the Open Source paradox, many managers didn’t make it.

When the technical people were finally able to demonstrate what they first envisioned, it became clear to the business people what we were actually creating: the world’s first Open Source architecture. To me, it was as exciting as the first time I looked at GCC.

Open Source is all well and good for the hacker, and the way that Open Source can create standards is great for the end user, but there’s a gap between what hackers can do with open-source software and what regular users can do. We wanted eCos to be a product that could be embraced by the mainstream embedded developer, not just the hacker community. Our idea was to empower users with high-level tools that could configure, customize, and perform basic validation of eCos in an automated fashion, replacing the manual steps that in-house RTOS developers perform today. By making the high-level tools control eCos at the source-code level, and by architecting the source code so that it could be managed via these tools, we made it possible for end users to work virtually at the source-code level, without ever needing to read or write a line of C or C++ code. The proof of our success is that eCos can be scaled from 700 bytes (bare minimum silicon abstraction layer) to over 50 Kbytes (full-featured RTOS with Internet stack and filesystem)!

Once we realized that Open Source was not just a feature, but the technical enabler of eCos, and once we proved to ourselves that with this feature, we had a 10x performance advantage over our competition (10x space savings over object-level configurability and 10x-100x programmer efficiency over source-available, but not source-architected RTOSes), we packaged solutions to deliver that performance advantage to the market, and the preliminary response from the market has been extremely positive.

When one considers the past impossibilities of our GNU-based business, one can only imagine the possibilities that eCos will create for Cygnus Solutions and the world.

Reflections and Vision of the Future

Open-source software taps the intrinsic efficiency of the technical free market, but it does so in an organic and unpredictable way. Open Source businesses take on the role of Adam Smith’s “invisible hand,” guiding it to both help the overall market and to achieve their own microeconomic goals. The most successful Open Source businesses will be the ones who can successfully guide technologies that engender the greatest cooperation from the Net community and solve the greatest technical and business challenges of the user community.

Created from open-source software, the Internet has been a fantastic enabler for the development of new open-source software. As people continue to connect on the Internet and through Open Source, we will witness changes in the development and use of software in much the same way that the Renaissance changed how we developed and used academic knowledge. With the freedoms provided by open-source software, I expect nothing less!

HE SET HIS MIND TO WORK ON UNKNOWN ARTS, THEREBY CHANGING THE LAWS OF NATURE.

—James Joyce