- Size Really Does Matter
- It Is Good to Work, But It Is Better to Grow
- A Community That Explodes the Myth of the Antisocial Geek
- The Meaning of Beer
- The Necessity of Community
This chapter is from the book
This chapter is from the book
This chapter is from the book
It Is Good to Work, But It Is Better to Grow
A key element behind the fact that the Open Source world could move so swiftly to produce so many applications in so short a period of time is the size of the community. But the community was not always so large or so proficient. What happened to cause this?
The Free Software Foundation, under the guidance of Richard Stallman, has been laboring since 1984 toward creating free software, including a free operating system. In the 1980s, many people knew of Stallman's desires, but relatively few programmers were involved in the effort. Among computer professionals, the Free Software Foundation was often characterized as a group of radical idealists.
But something happened to change the perception that the task of creating free software was for extreme idealists. In 1991, Linus Torvalds began his work on the Linux kernel, which, when combined with the work done by the FSF and other free-software developers, eventually yielded a working free operating system. Although this accomplishment is often heralded as a great achievement in the history of free software, an equally great accomplishment is often overlooked entirely.
Linus brought free software to the attention of the world. But how did this happen?
Some people make the mistake of believing that this is due to the fact that the existence of a good free kernel made the free operating system usable. They claim that although the GNU project was only a set of utility programs, it was not "sexy" enough to warrant the attention of many technical people. But, with the appearance of the Linux kernel, the resultant coupling of Linux and GNU made a workable system that finally began to attract the attention of the computing world. The argument is that when the code became reasonably complete, the explosion of interest was essentially inevitable.
This perspective—often heard on the lips of people in the free-software movement—misses one absolutely essential ingredient: the reason for the blossoming of the community. The assumption is that the functionality of the code, perhaps coupled with the liberating concept of free software, was sufficient to build the community that has been responsible for the dramatic rise in free software. The community's growth must have been due to the excitement over working code and dedication to the concept of free software.
But this is not the case. Although community growth certainly was aided by functional code, and certain members of the community were attracted by the concept of free software, the coupling of these elements is insufficient to explain the dramatic increase in size of the community during the 1990s. In many ways, the community began growing as the most positive elements of geek culture began to flower. And the person who did the most watering was Linus Torvalds.
When Linus Torvalds began leading the Linux project in 1991, he set a stage that would be ready for community growth. He employed a few simple elements that would cause people to gravitate to the work. And he removed barriers that had repelled some people from working toward free software.
The ingredients employed by Torvalds are so simple that they are often taken for granted by observers who seek to understand the Open Source community. The elements are clearly a product of some common sense applied to knowledge of how geeks think. Yet it was these simple ingredients that would launch the community into a worldwide force capable of developing immense amounts of high-quality free software over a relatively short period of time.
Open Development Cycle
First among the ingredients is openness of the development cycle. In this model, important design decisions are discussed in public forums before their implementation begins. Everyone is given the opportunity to see the code as it is developed. People examining the developer's release of the code will see new portions as they come into being. The new portions may be badly broken, with some new routines missing entirely. The code may not be complete enough to make it through the computer language compiler without generating show-stopping errors.
But that is precisely the beauty of the thing. Other developers can see new, complex code often before it works. This means that the community can see precisely how things are implemented as they are being implemented. It gives the community the opportunity to discuss the merits of using one type of implementation rather than another before anything has been cast in stone. This simple method of providing for ongoing peer review helps to solve problems before they occur. It means that the many eyes of the community can examine things early in the cycle, so many bugs and potential flaws can be handled before new portions of code become too big to be changed easily.
Prior to the beginning of the Linux project, many free-software efforts varied considerably on the openness of the development cycle. Often times, free software was produced much like closed software, where the users only received the code when it was already working (for the most part). Eric Raymond's The Cathedral and the Bazaar describes how the development of the core of the GNU Emacs project fit this model. The open method of access during coding used by the Linux project, however, raised the bar for accessibility to the code during development.
An example of this is the Linux kernel-development model. At any time, there are two trees available: one stable and one in development. New software capabilities are introduced into the development tree. When the code has been thoroughly tested and integrated into the development tree, it might be integrated into the stable tree. Eventually, the entire development tree is stabilized and it becomes the basis of a new stable tree. If someone looks at the development version of the code, he will often find unfinished segments of code, routines needing debugging, or gutless prototypes of routines that need to be written but are not yet in place. The availability of such unfinished work allows other people to point out potential flaws in the implementation strategy before it is completed.
Open Development Team
A second key ingredient used by Linus is inclusion. People from across the world, regardless of status, may examine the code and submit patches. In some other free-software development efforts, the development team was a fairly closed group. A person outside of the team was free to submit patches, but there was a distinct difference between a developer raising an issue and someone outside raising the same issue. There was a line drawn between developers and users.
Under Torvalds's leadership, however, the line between developer and user blurred. Certainly, a core group of developers was relied on to handle certain tasks. But the people outside the core group were also seen as valued contributors to the success of the project. When those outside of the core group made suggestions and submissions, they found that their voices were heard.
This meant that anyone with the desire and talent to try to contribute to the effort was free to do so. And, by contributing, each of these people could develop a sense of ownership for the project. There was no longer a line between the developer and the onlooker. Instead, the community itself began to feel ownership of the project.
Let the Best Code Win
The free-software teams that tended toward closed development groups often seemed to prefer code written by core developers over that submitted by those outside. And, even if that was not the case in actuality, the appearance that it was so was discouraging to those who wanted to contribute. As a player in a game may become discouraged when the rules seem stacked against him, so many of these outsiders began to feel that it almost was not worth submitting code when the work of insiders seemed to be preferred.
But, in the Linux development model, the technical mantra "Let the best code win" ruled the day. It did not matter if the submitter was a core developer or someone who had just begun to look at the code. The only measuring rod used to evaluate submissions was the question, "Is this the best solution to the problem?" This meant that anyone—absolutely anyone—could contribute something of value. The task was to create the best solution possible, and that meant that anyone with a good idea was free to try his hand at contributing to the best solution.
The enthusiasm this generated over time is inestimable. It created a totally level playing field for geeks to compete. It also meant that those who succeeded in having code accepted into the project were enthralled by the success. Geeks who had wanted for years to be appreciated for their technical expertise suddenly had an outlet that electrified them. There were no social norms to uphold. There were no office politics to endure. They could simply contribute on the basis of their long suit—a deep knowledge of programming—and be appreciated for those contributions.
Fast Turnaround
A fourth ingredient is exceptional speed in turnaround. During the early years of Linux kernel development, it was not unusual for Linus to post a new kernel every day—or even more frequently. This meant that people who submitted acceptable patches would often see their code appear in the project within days or hours of submission. This created a tremendously strong positive feedback loop in the development cycle. Because people quickly realized that their contributions were accepted and used, they began to work all that much harder. They felt the gratification of success in real time.
In some other projects, successful patch submissions might not appear in the project's code base for weeks or months. Those projects that used an old-style release cycle of closed development followed by a release of working code did not provide the immediate positive feedback that the Linux project did.
Open Praise
A fifth element is open praise. As basic and simplistic as it might seem, not all projects bothered to give public credit for people who contributed code. Without praise, a programmer might feel gratified that his work was deemed good enough to be accepted into a project. But the lack of credit could leave a lingering sense that appreciation could have been greater.
The willingness of Linus Torvalds to acknowledge the contributions of others by name in public ways was very important to ensuring the success of Linux. The presence of public praise meant that there was a concrete reward for submitting quality code and ideas. It was an honest level of appreciation that geeks had often longed for but never found.
Simple Philosophy
A sixth element is an implicit and pragmatic philosophy. Although often attacked by people in the free-software movement, the simple pragmatism of Linus Torvalds made the subject of free software less a matter of moral imperatives than a issue of practical preferences. The members of the free-software movement often expound on the need to have all software free. All software should be available in source code, for anyone to use or modify, and modifications must remain free as well. Anything less than that is not truly free, and anyone who does not ascribe to all those tenets is not fit to stand as champion of the free-software movement.
Torvalds, however, has not made an issue insisting that all software must be free. Rather, he and his followers have taken a much simpler view: If you create excellent free software, the closed proprietary packages will fail to survive. The task, then, is not to convince people of the moral imperative that all software must be free, but rather to use the combined strength of the community to make sure that the free packages are superior and preferable to their closed counterparts.
The difference in philosophy has had an extremely important effect on the growth of the community. The statement that "all software must be free" is too extreme for most people to embrace. But the notion that free software is a better alternative than proprietary software is a very attractive idea. People have shown themselves willing to work toward creating a superior alternative that is available to everyone.
The difference in philosophy is also a boundary marker between the free-software movement and the Open Source movement. The free-software movement sticks to its basic concept that free software is a moral imperative, whereas the Open Source movement does not insist on making that claim. The Open Source community tends to work with a "big tent" concept: It counts the free-software people as part of its ranks, even if the free-software people do not include the Open Source people in their numbers.
Still, both the free-software people and the Open Source people work side by side creating software. The resulting software and licensing tend to be indistinguishable from one another, with the exception that the free-software people tend to use GNU licenses almost exclusively, whereas Open Source efforts will sometimes employ a different licensing scheme. The major differences between the Open Source and free-software people tend to arise during discussions rather than in code. But the difference in philosophy has been a profound aid to the growth of the Open Source movement. And I suspect that the philosophical change has actually benefited the free-software people as well because the popularity of Open Source has given them a pulpit from which they may seek to teach people about their position.
Fun
The final ingredient is fun, the one ingredient that people tend to overlook entirely. And, as the Open Source movement grows into the areas of business, it is the one ingredient that needs to be labeled as an endangered species.
From the start of his work, Linus Torvalds has repeatedly said that Linux should be fun. It is not a drudgery to endure. It is not even a great moral cause (as the free-software people might contend) It is simply a way to produce better software that would be available to everyone and that people could actually enjoy writing and using. And, in this, Linus succeeded wildly.
Back in 1997, I attended one of the early Linux conferences, the Atlanta Linux Showcase. As Linux was still not very well known in business, the show was quite small. About 500 people gathered on a weekend to attend technical seminars and hear addresses from several people, including Eric Raymond, Jon "maddog" Hall, and even Linus Torvalds himself. Perhaps 20 vendors occupied the exhibit floor outside of the conference rooms.
From a statistical viewpoint, the conference was immaterial. In an era when big computer trade shows would find tens of thousands of people wandering through exhibit halls that spanned multiple buildings, the gathering of 500 people and 20 vendors in three rooms in Atlanta was inconsequential. But the important difference about this show does not appear in the statistics.
The people in attendance were different from those at normal computer shows. They did not show up because their bosses told them to go. They did not attend because they wanted a day off from work (the show was on a weekend, after all). They did not even show up to get freebies and trinkets from the vendors (there were only a few giveaways).
No, the people came because they wanted to be there. They came because they wanted to attend the technical sessions. They came to hear people like Linus, Eric, and maddog speak. And, most of all, they came because it was fun.
I could see it in the faces. I could hear it in their voices. These folks were having a grand time! They were enjoying every minute of it! They were having fun.
The fact that geeks from across the world could work at Linux and have fun while doing so increased the popularity of the Open Source community. Tasks are always easier to do when you enjoy doing them. And the simple truth of this was quite apparent in the early years of the community.
As work progressed, the corporate world began to take an interest in the movement. Many in the community were overjoyed with the growing recognition by business that these projects were producing some truly useful software. But some were afraid that the business world would change the community if the community did not remind itself of its core values.
The community has fought hard to remember its core values. It has fought off the temptation to lose its unique identity. But the sense of fun seems to be waning somewhat under the stress of IPOs, market caps, and business plans. Fun has not disappeared from the map, but it seems that the routes to it are not used nearly as much these days.
Soup Is On!
The combination of these key elements—an open development cycle, an open development team, fairness, fast turnaround, praise, a simple philosophy, and fun—make a potent recipe for a growing community. These ingredients, among others, helped propel the community from a relatively small bunch of idealists into a large body of motivated Open Source developers.