16. Corporations

Many movies about teenagers follow a time-proven formula: once the magic summer is over, the gang is going to split up and it will never be the same again. Bob's going to college; Rick is getting married; and Harry is going to be stuck in the old town forever. Right now, the free software world is playing out the same emotions and dramas as the greater world discovers open source software. In the fall, the corporations are coming and the old, cool world of late-night hackfests fueled by pizza and Jolt are in danger. Some people in the realm of free source software are going to grow up, get educated, and join the establishment; some will get married; and some will get left behind wondering why the old game isn't as cool anymore.

The free source world is suffering from an acute case of success. Many of the great projects like Apache and Sendmail are growing up and being taken over by corporations with balance sheets. Well, not exactly taken over, but the corporations will exist and they'll try to shepherd development. Other corporations like Apple, Sun, and Netscape are experimenting with open source licenses and trying to make money while sharing code. Some quaint open source companies like Red Hat are growing wealthy by floating IPOs to raise some money and maybe buy a few Porsches for their stakeholders. There's a lot of coming of age going on.

On the face of it, none of this rampant corporatization should scare the guys who built the free software world in their spare cycles. The corporations are coming to free source because it's a success. They want to grab some of the open software mojo and use it to drive their own companies. The suits on the plane are all tuning into Slashdot, buying T-shirts, and reading Eric Raymond's essay “The Cathedral and the Bazaar” in the hopes of glomming on to a great idea. The suits have given up their usual quid pro quo: be a good nerd, keep the code running, and we'll let you wear a T-shirt in your basement office. Now they want to try to move in and live the life, too. If Eric Raymond were selling Kool-Aid, they would be fighting to drink it.

The talk is serious, and it's affecting many of the old-line companies as well. Netscape started the game by releasing the source code to a development version of their browser in March of 1998. Apple and Sun followed and began giving away the source code to part of their OS. Of course, Apple got part of the core of their OS from the open source world, but that's sort of beside the point. They're still sharing some of their new, Apple-only code. Some, not all. But that's a lot more than they shared before. Sun is even sharing the source code to their Java system. If you sign the right papers or click the right buttons, you can download the code right now. Its license is more restrictive, but they're joining the club, getting religion, and hopping on the bandwagon.

Most of the true devotees are nervous about all of this attention. The free software world was easy to understand when it was just late-night hackfests and endless railing against AT&T and UNIX. It was simple when it was just messing around with grungy code that did way cool things. It was a great, he-man, Windoze-hating clubhouse back then.

Well, the truth is that some of the free software world is going to go off to college, graduate with a business degree, and turn respectable. Eric Allman, for instance, is trying to build a commercial version of his popular free package Sendmail. The free version will still be free, but you can get a nicer interface and some cooler features for managing accounts if you buy in. If things work out, some of the folks with the free version will want all of the extra features he's tacking on and they'll pay him. No one knows what this will do to the long-term development of Sendmail, of course. Will he only make new improvements in the proprietary code? Will other folks stop contributing to the project because they see a company involved? There's some evidence that Allman's not the same guy who hung around the pizza joint. When I contacted him for an interview, he passed me along to his public relations expert, who wrote back wanting to “make sure this is a profitable way to spend Eric's time.” For all we know, Eric may have even been wearing a suit when he hired a corporate PR team.

Some of the other free software folks are going to get married. The Apache group has leveraged its success with small server organizations into connections with the best companies selling high-powered products. IBM is now a firm supporter of Apache, and they run it on many of their systems. Brian Behlendorf still schedules his own appointments, jokes often, and speaks freely about his vision for Apache, but he's as serious as any married man with several kids to support. It's not just about serving up a few web pages filled with song lyrics or Star Wars trivia. People are using Apache for business--serious business. There can still be fun, but Apache needs to be even more certain that they're not screwing up.

And of course there are thousands of free software projects that are going to get left behind hanging out at the same old pizza joint. There were always going to be thousands left behind. People get excited about new projects, better protocols, and neater code all the time. The old code just sort of withers away. Occasionally someone rediscovers it, but it is usually just forgotten and superseded. But this natural evolution wasn't painful until the successful projects started ending up on the covers of magazines and generating million-dollar deals with venture capitalists. People will always be wondering why their project isn't as big as Linux.

There will also be thousands of almost great projects that just sail on being almost great. All of the distributions come with lots of programs that do some neat things. But there's no way that the spotlight can be bright enough to cover them all. There will be only one Torvalds and everyone is just going to be happy that he's so gracious when he reminds the adoring press that most of the work was done by thousands of other nameless folks.

Most of the teen movies don't bother trying to figure out what happens after that last fateful summer. It's just better to end the movie with a dramatic race or stage show that crystallizes all the unity and passion that built up among this group during their formative years. They sing, they dance, they win the big game, they go to the prom, and then cameras love to freeze the moment at the end of the film. The free software movement, on the other hand, is just too important and powerful to stop this book on a climactic note. It would be fun to just pause the book at the moment in time when Linus Torvalds and Bob Young were all over the magazines. Their big show was a success, but the real question is what will happen when some folks go to school, some folks get married, and some folks are left behind.

To some extent, the influx of money and corporations is old news. Very old news. Richard Stallman faced the same problem in the 1980s when he realized that he needed to find a way to live without a university paycheck. He came up with the clever notion that the software and the source must always be free, but that anyone could charge whatever the market would bear for the copies. The Free Software Foundation itself continues to fund much of its development by creating and selling both CD-ROMs and printed manuals.

This decision to welcome money into the fold didn't wreck free software. If anything, it made it possible for companies like Red Hat to emerge and sell easier-to-use versions of the free software. The companies competed to put out the best distributions and didn't use copyright and other intellectual property laws to constrain each other. This helped attract more good programmers to the realm because most folks would rather spend their time writing code than juggling drivers on their machine. Good distributions like Red Hat, Slackware, Debian, FreeBSD, and SuSE made it possible for everyone to get their machines up and running faster.

There's no reason why the latest push into the mainstream is going to be any different. Sure, Red Hat is charging more and creating better packages, but most of the distribution is still governed by the GPL. Whenever people complain that Red Hat costs too much, Bob Young just points people to the companies that rip off his CDs and charge only $2 or $3 per copy. The GPL keeps many people from straying too far from the ideal.

The source is also still available. Sure, the corporate suits can come in, cut deals, issue press releases, raise venture capital, and do some IPOs, but that doesn't change the fact that the source code is now widely distributed. Wasn't that the goal of Stallman's revolution? Didn't he want to be able to get at the guts of software and fix it? The source is now more omnipresent than ever. The corporations are practically begging folks to download it and send in bug fixes.

Of course, access to the source was only half of Stallman's battle. A cynic might growl that the corporations seem to be begging folks to do their research, testing, and development work for them. They're looking for free beers. Stallman wanted freedom to do whatever he wanted with the source and many of the companies aren't ready to throw away all of their control.

Apple sells its brand, and it was careful not to open up the source code to its classic desktop interface. They kept that locked away. Most of the source code that Apple released is from its next version of the operating system, Mac OS X, which came from the folks at NeXT when Apple acquired that company. Where did that code come from? Large portions came from the various free versions of BSD like NetBSD or Mach. It's easy to be generous when you only wrote a fraction of the code.

Ernest Prabhakar, the project manager for Apple's first open source effort known as Darwin, describes the tack he took to get Apple's management to embrace this small core version of the BSD operating system tuned to the Macintosh hardware platform.

“The first catalysts were the universities. There were a lot of universities like MIT and University of Michigan that had some specialized network infrastructure needs,” he said.

"We realized that the pieces they're most interested in are the most commoditized. There wasn't really any proprietary technology added that we had to worry about them copying. There are people who know them better than we do like the BSD community. We started making the case, if we really want to partner with the universities we should just open the source code and release it as a complete BSD-style operating system.

“We wanted people to use this in classes, really embed it in the whole educational process without constraining teaching to fit some corporate model,” he finishes.

Of course, Prabhakar suggests that there is some self-interest as well. Apple wants to be a full partner with the BSD community. It wants the code it shares to mingle and cross-pollinate with the code from the BSD trees. In the long run, Apple's Darwin and the BSDs will grow closer together. In an ideal world, both groups will flourish as they avoid duplicating each other's efforts.

Prabhakar says, “This reduces our reintegration costs. The ability to take the standard version of FreeBSD and dump it into our OS was a big win. Prior to doing the open source, we had done a small scale of givebacks.”

This view is echoed by other companies. IBM is a great hardware company and an even greater service company that's never had much luck selling software, at least in the same way that Microsoft sells software. Their OS/2 never got far off the ground. They've sold plenty of software to companies by bundling it with handholding and long-term service, but they've never had great success in the shrink-wrapped software business. Open source gives them the opportunity to cut software development costs and concentrate on providing service and hardware. They get free development help from everyone and the customers get more flexibility.

Sun's Community Source License is also not without some self-interest. The company would like to make sure that Java continues to be “Write Once, Run Anywhere,” and that means carefully controlling the APIs and the code to make sure no idiosyncrasies or other glitches emerge. People and companies that want to be part of the community must abide by Sun's fairly generous, but not complete, gift to the world.

The company's web page points out the restriction Sun places on its source code fairly clearly. “Modified source code cannot be distributed without the express written permission of Sun” and “Binary programs built using modified Java 2 SDK source code may not be distributed, internally or externally, without meeting the compatibility and royalty requirements described in the License Agreement.”

While some see this clause as a pair of manacles, Bill Joy explains that the Community Source License is closer to our definition of a real community. “It's a community in a stronger sense,” he told an audience at Stanford. “If you make improvements, you can own them.” After you negotiate a license with Sun, you can sell them. Joy also points out that Sun's license does require some of the GNU-like sharing by requiring everyone to report bugs.

Some customers may like a dictator demanding complete obeisance to Sun's definition of Java, but some users are chaffing a bit. The freedom to look at the code isn't enough. They want the freedom to add their own features that are best tuned to their own needs, a process that may start to Balkanize the realm by creating more and more slightly different versions of Java. Sun clearly worries that the benefits of all this tuning aren't worth living through the cacophony of having thousands of slightly different versions. Releasing the source code allows all of the users to see more information about the structure of Sun's Java and helps them work off the same page. This is still a great use of the source code, but it isn't as free as the use imagined by Stallman.

Alan Baratz, the former president of Sun's Java division, says that their Community Source License has been a large success. Sure, some folks would like the ability to take the code and fork off their own versions as they might be able to do with software protected by a BSD- or GNU-style license, but Java developers really want the assurance that it's all compatible. As many said, “Microsoft wanted to fork Java so it could destroy it.”

Baratz said, “We now have forty thousand community source licensees. The developers and the systems builders and the users all want the branded Java technology. They want to know that all of the apps are going to be there. That's the number-one reason that developers are writing to the platform.” Their more restrictive license may not make Stallman and other free software devotees happy, but at least Java will run everywhere.

Maybe in this case, the quality and strength of the unity Sun brings to the marketplace is more important than the complete freedom to do whatever you want. There are already several Java clones available, like Kaffe. They were created without the help of Sun, so their creators aren't bound by Sun's licenses. But they also go out of their way to avoid splitting with Sun. Tim Wilkinson, the CEO of Transvirtual, the creators of Kaffe, says that he plans to continue to make Kaffe 100 percent Java compatible without paying royalties or abiding by the Community Source License. If his project or other similar ones continue to thrive and grow, then people will know that the freedom of open source can be as important as blind allegiance to Sun.

These corporate efforts are largely welcomed by the open source world, but the welcome does not come with open arms or a great deal of warmth.

Source code with some restrictions is generally better than no source at all, but there is still a great deal of suspicion. Theo de Raadt, the leader of the OpenBSD project, says, “Is that free? We will not look at Apple source code because we'll have contaminated ourselves.” De Raadt is probably overreacting, but he may have reason to worry. AT&T's USL tied up the BSD project for more than a year with a lawsuit that it eventually lost. Who knows what Apple could do to the folks at OpenBSD if there were a some debate over whether some code should be constrained by the Apple license? It's just easier for everyone at OpenBSD to avoid looking at the Apple code so they can be sure that the Apple license won't give some lawyers a toehold on OpenBSD's code base.

Richard Stallman says, “Sun wants to be thought of as having joined our club, without paying the dues or complying with the public service requirements. They want the users to settle for the fragments of freedom Sun will let them have.”

He continues, “Sun has intentionally rejected the free software community by using a license that is much too restrictive. You are not allowed to redistribute modified versions of Sun's Java software. It is not free software.”

16.1. Fat Cats and Alley Cats

The corporations could also sow discord and grief by creating two different classes: the haves and the have-nots. The people who work at the company and draw a salary would get paid for working on the software while others would get a cheery grin and some thanks. Everyone's code would still be free, but some of the contributors might get much more than others. In the past, everyone was just hanging out on the Net and adding their contributions because it was fun.

This split is already growing. Red Hat software employs some of the major Linux contributors like Alan Cox. They get a salary while the rest of the contributors get nothing. Sun, Apple, and IBM employees get salaries, but folks who work on Apache or the open versions of BSD get nothing but the opportunity to hack cool code.

One employee from Microsoft, who spoke on background, predicted complete and utter disaster. “Those folks are going to see the guys from Red Hat driving around in the Porsches and they're just going to quit writing code. Why help someone else get rich?” he said. I pointed out that jealousy wasn't just a problem for free software projects. Didn't many contract employees from Microsoft gather together and sue to receive stock options? Weren't they locked out, too?

Still, he raises an interesting point. Getting people to join together for the sake of a group is easy to do when no one is getting rich. What will happen when more money starts pouring into some folks' pockets? Will people defect? Will they stop contributing?

Naysayers are quick to point to experiments like Netscape's Mozilla project, which distributed the source code to the next generation of its browser. The project received plenty of hype because it was the first big open source project created by a major company. They set up their own website and built serious tools for keeping track of bugs. Still, the project has not generated any great browser that would allow it to be deemed a success. At this writing, about 15 months after the release, they're still circulating better and better beta versions, but none are as complete or feature-rich as the regular version of Netscape, which remains proprietary. ¹¹

The naysayers like to point out that Netscape never really got much outside help on the Mozilla project. Many of the project's core group were Netscape employees and most of the work was done by Netscape employees. There were some shining examples like Jim Clark (no relation to the founder of Netscape with the same name), who contributed an entire XML parser to the project. David Baron began hacking and testing the Mozilla code when he was a freshman at Harvard. But beyond that, there was no great groundswell of enthusiasm. The masses didn't rise up and write hundreds of thousands of lines of code and save Netscape.

But it's just as easy to cast the project as a success. Mozilla was the first big corporate-sponsored project. Nothing came before it, so it isn't possible to compare it with anything. It is both the best and the worst example. The civilian devotees could just as well be said to have broken the world record for source code contributed to a semi-commercial project. Yes, most of the work was officially done by Netscape employees, but how do you measure work? Many programmers think a good bug report is more valuable than a thousand lines of code. Sure, some folks like Baron spend most of their time testing the source code and looking for incompatibilities, but that's still very valuable. He might not have added new code himself, but his insight may be worth much more to the folks who eventually rely on the product to be bug-free.

It's also important to measure the scope of the project. Mozilla set out to rewrite most of the Netscape code. In the early days, Netscape grew by leaps and bounds as the company struggled to add more and more features to keep ahead of Microsoft. The company often didn't have the time to rebuild and reengineer the product, and many of the new features were not added in the best possible way. The Mozilla team started off by trying to rebuild the code and put it on a stable foundation for the future. This hard-core, structural work often isn't as dramatic. Casual observers just note that the Mozilla browser doesn't have as many features as plain old Netscape. They don't realize that it's completely redesigned inside.

Jeff Bates, an editor at Slashdot, says that Mozilla may have suffered because Netscape was so successful. The Netscape browser was already available for free for Linux. “There wasn't a big itch to scratch,” he says. “We already had Netscape, which was fine for most people. This project interested a smaller group than if we'd not had Netscape-hence why it didn't get as much attention.”

The experiences at other companies like Apple and Sun have been more muted. These two companies also released the source code to their major products, but they did not frame the releases as big barn-raising projects where all of the users would rise up and do the development work for the company. Some people portrayed the Mozilla project as a bit of a failure because Netscape employees continued to do the bulk of code writing. Apple and Sun have done a better job emphasizing the value of having the source available while avoiding the impossible dream of getting the folks who buy the computers to write the OS, too.

Not all interactions between open source projects and corporations involve corporations releasing their source code under a new open source license. Much more code flows from the open source community into corporations. Free things are just as tempting to companies as to people.

In most cases, the flow is not particularly novel. The companies just choose FreeBSD or some version of Linux for their machines like any normal human being. Many web companies use a free OS like Linux or FreeBSD because they're both cheap and reliable. This is going to grow much more common as companies realize they can save a substantial amount of money over buying seat licenses from companies like Microsoft.

In some cases, the interactions between the open source realm and the corporate cubicle farm become fairly novel. When the Apache web server grew popular, the developers at IBM recognized that they had an interesting opportunity at hand. If IBM could get the Apache server to work on its platforms, it might sell more machines. Apache was growing more common, and common software often sold machines. When people came looking for a new web server, the IBM salesmen thought it might be nice to offer something that was well known.

Apache's license is pretty loose. IBM could have taken the Apache code, added some modifications, and simply released it under their own name. The license only required that IBM give some credit by saying the version was derived from Apache itself. This isn't hard to do when you're getting something for free.

Other companies have done the same thing. Brian Behlendorf, one of the Apache core group, says, “There's a company that's taken the Apache code and ported it to Mac. They didn't contribute anything back to the Apache group, but it didn't really hurt us to do that.” He suggested that the karma came back to haunt them because Apple began releasing their own version of Apache with the new OS, effectively limiting the company's market.

IBM is, of course, an old master at creating smooth relationships with customers and suppliers. They chose to build a deeper relationship with Apache by hiring one of the core developers, Ken Coar, and paying him to keep everyone happy.

“My job is multifaceted,” says Coar. “I don't work on the IBM addedvalue stuff. I work on the base Apache code on whatever platforms are available to me. I serve as a liaison between IBM and the Apache group, basically advising IBM on whether the things that they want to do are appropriate. It's an interesting yet unique role. All of my code makes it back into the base Apache code.”

Coar ended up with the job because he helped IBM and Apache negotiate the original relationship. He said there was a considerable amount of uncertainty on both sides. IBM wondered how they could get something without paying for it, and Apache wondered whether IBM would come in and simply absorb Apache.

“There were questions about it from the Apache side that any sort of IBM partnership would make it seem as if IBM had acquired Apache. It was something that Apache didn't want to see happen or seem to see happen,” Coar said.

Today, Coar says IBM tries to participate in the Apache project as a peer. Some of the code IBM develops will flow into the group and other bits may remain proprietary. When the Apache group incorporated, Coar and another IBM employee, Ken Stoddard, were members. This sort of long-term involvement can help ensure that the Apache group doesn't start developing the server in ways that will hurt its performance on IBM's machine. If you pay several guys who contribute frequently to the project, you can be certain that your needs will be heard by the group. It doesn't guarantee anything, but it can buy a substantial amount of goodwill.

Of course, it's important to realize that the Apache group was always fairly business-oriented. Many of the original developers ran web servers and wanted access to the source code. They made money by selling the service of maintaining a website to the customers, not a shrink-wrapped copy of Apache itself. The deal with IBM didn't mean that Apache changed many of its ways; it just started working with some bigger fish.

At first glance, each of these examples doesn't really suggest that the coming of the corporations is going to change much in the free source world. Many of the changes were made long ago when people realized that some money flowing around made the free software world a much better place. The strongest principles still survive: (1) hackers thrive when the source code is available, and (2) people can create their own versions at will.

The arrival of companies like IBM doesn't change this. The core Apache code is still available and still running smoothly. The modules still plug in and work well. There's no code that requires IBM hardware to run and the committee seems determined to make sure that any IBM takeover doesn't occur. In fact, it still seems to be in everyone's best interest to keep the old development model. The marketplace loves standards, and IBM could sell many machines just offering a standard version of Apache. When the customers walk in looking for a web server, IBM's sales force can just say “This little baby handles X billion hits a day and it runs the industry-leading Apache server.” IBM's arrival isn't much different from the arrival of a straightlaced, no-nonsense guy who strolls in from the Net and wants to contribute to Apache so he can get ahead in his job as a webmaster. In this case, it's just a corporation, not a person.

Many suggest that IBM will gradually try to absorb more and more control over Apache because that's what corporations do. They generate inscrutable contracts and unleash armies of lawyers. This view is shortsighted because it ignores how much IBM gains by maintaining an arm'slength relationship. If Apache is a general program used on machines throughout the industry, then IBM doesn't need to educate customers on how to use it. Many of them learned in college or in their spare time on their home machines. Many of them read books published by third parties, and some took courses offered by others. IBM is effectively offloading much of its education and support costs onto a marketplace of third-party providers.

Would IBM be happier if Apache was both the leading product in the market and completely owned by IBM? Sure, but that's not how it turned out. IBM designed the PC, but they couldn't push OS/2 on everyone. They can make great computers, however, and that's not a bad business to be in. At least Apache isn't controlled by anyone else, and that makes the compromise pretty easy on the ego.

Some worry that there's a greater question left unanswered by the arrival of corporations. In the past, there was a general link between the creator of a product and the consumer. If the creator didn't do a good job, then the consumer could punish the creator by not buying another version. This marketplace would ensure that only the best survived.

Patrick Reilly writes, “In a free market, identifiable manufacturers own the product. They are responsible for product performance, and they can be held liable for inexcusable flaws.”

What happens if a bug emerges in some version of the Linux kernel and it makes it into several distributions? It's not really the fault of the distribution creators, because they were just shipping the latest version of the kernel. And it's not really the kernel creators' fault, because they weren't marketing the kernel as ready for everyone to run. They were just floating some cool software on the Net for free. Who's responsible for the bug? Who gets sued?

Reilly takes the scenario even further. Imagine that one clever distribution company finds a fix for the bug and puts it into their distribution. They get no long-term reward because any of the other distribution companies can come along and grab the bug fix.

He writes, “Consumers concerned about software compatibility would probably purchase the standard versions. But companies would lose profit as other consumers would freely download improved versions of the software from the Internet. Eventually the companies would suffer from widespread confusion over the wide variety of software versions of each product, including standard versions pirated by profiteers.”

There's no doubt that Reilly points toward a true breakdown in the feedback loop that is supposed to keep free markets honest and efficient. Brand names are important, and the free source world is a pretty confusing stew of brand names.

But he also overestimates the quality of the software emerging from proprietary companies that can supposedly be punished by the marketplace. Many users complain frequently about bugs that never get fixed in proprietary code, in part because the proprietary companies are frantically trying to glom on more features so they can convince more people to buy another version of the software. Bugs don't always get fixed in the proprietary model, either.

Richard Stallman understands Reilly's point, but he suggests that the facts don't bear him out. If this feedback loop is so important, why do so many people brag about free software's reliability?

Stallman says, “He has pointed out a theoretical problem, but if you look at the empirical facts, we do not have a real problem. So it is only a problem for the theory, not a problem for the users. Economists may have a challenge explaining why we DO produce such reliable software, but users have no reason to worry.”

16.2. The Return of the Hardware Kings

The biggest effect of the free software revolution may be to shift the power between the hardware and software companies. The biggest corporate proponents of open source are IBM, Apple, Netscape/AOL, Sun, and Hewlett-Packard. All except Netscape are major hardware companies that watched Microsoft turn the PC world into a software monopoly that ruled a commodity hardware business.

Free source code changes the equation and shifts power away from software companies like Microsoft. IBM and Hewlett-Packard are no longer as beholden to Microsoft if they can ship machines running a free OS. Apple is borrowing open source software and using it for the core of their new OS. These companies know that the customers come to them looking for a computer that works nicely when it comes from the factory. Who cares whether the software is free or not? If it does what the customer wants, then they can make their money on hardware.

The free software movement pushes software into the public realm, and this makes it easier for the hardware companies to operate. Car companies don't sit around and argue about who owns the locations of the pedals or the position of the dials on the dashboard. Those notions and design solutions are freely available to all car companies equally. The lawyers don't need to get involved in that level of car creation.

Of course, the free software movement could lead to more consolidation in the hardware business. The car business coalesced over the years because the large companies were able to use their economies of scale to push out the small companies. No one had dominion over the idea of putting four wheels on a car or building an engine with pistons, so the most efficient companies grew big.

This is also a threat for the computer business. Microsoft licensed their OS to all companies, big or small, that were willing to prostrate themselves before the master. It was in Microsoft's best interests to foster free competition between the computer companies. Free software takes this one step further. If no company has control over the dominant OS, then competition will shift to the most efficient producers. The same forces that brought GM to the center of the car industry could help aggregate the hardware business.

This vision would be more worrisome if it hadn't happened already. Intel dominates the market for CPU chips and takes home the lion's share of the price of a PC. The marketplace already chose a winner of that battle. Now, free software could unshackle Intel from its need to maintain a partnership with Microsoft by making Intel stronger.

Of course, the free OSs could also weaken Intel by opening it up to competition. Windows 3.1, 95, and 98 always ran only on Intel platforms. This made it easier for Intel to dominate the PC world because the OS that was most in demand would only run on Intel or Intel compatible chips. Microsoft made some attempt to break out of this tight partnership by creating versions of Windows NT that ran on the Alpha chip, but these were never an important part of the market.

The free OS also puts Intel's lion's share up for grabs. Linux runs well on Intel chips, but it also runs on chips made by IBM, Motorola, Compaq, and many others. The NetBSD team loves to brag that its software runs on almost all platforms available and is dedicated to porting it to as many as possible. Someone using Linux or NetBSD doesn't care who made the chip inside because the OS behaves similarly on all of them.

Free source code also threatens one of the traditional ways computer manufacturers differentiated their products. The Apple Macintosh lost market share and potential customers because it was said that there wasn't much software available for it. The software written for the PC would run on the Mac only using a slow program that converted it. Now, if everyone has access to the source code, they can convert the software to run on their machine. In many cases, it's as simple as just recompiling it, a step that takes less than a minute. Someone using an Amiga version of NetBSD could take software running on an Intel chip version and recompile it.

This threat shows that the emergence of the free OSs ensures that hardware companies will also face increased competitive pressure. Sure, they may be able to get Microsoft off their back, but Linux may make things a bit worse.

In the end, the coming of age of free software may be just as big a threat to the old way of life for corporations as it is to the free software community. Sure, the hackers will lose the easy camaraderie of swapping code with others, but the corporations will need to learn to live without complete control. Software companies will be under increasing pressure from free versions, and hardware companies will be shocked to discover that their product will become more of a commodity than it was before. Everyone is going to have to find a way to compete and pay the rent when much of the intellectual property is free.

These are big changes that affect big players. But what will the changes mean to the programmers who stay up late spinning mountains of code? Will they be disenfranchised? Will they quit in despair? Will they move on to open source experiments on the human genome?

“The money flowing in won't turn people off or break up the community, and here's why,” says Eric Raymond. “The demand for programmers has been so high for the last decade that anyone who really cared about money is already gone. We've been selected for artistic passion.”