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
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.
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.
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.
INFORMATION, NO MATTER HOW EXPENSIVE TO CREATE, CAN BE REPLICATED AND SHARED AT LITTLE OR NO COST.
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.
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.
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.
COMMON LAW IS LEGAL CODE THAT IS FREE TO ALL PEOPLE EQUALLY.
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.
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.
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
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.