16.1 Fat Cats and Alley Cats

Free For All. Go to the Table of Contents. Vist the Gifcom.

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.[^11]

[11]: At this writing, version M13 of Mozilla looks very impressive. It's getting quite close to the proprietary version of Netscape. 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."