Free for All by Peter Wayner (great books to read .txt) 📖

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