Free for All, Peter Wayner [my miracle luna book free read .TXT] 📗

Law." That is, eventually some programmer would start printing and using the Internet at the same time. After the system crashed a few times, some programmer would care enough about the problem to dig into the free source, poke around, and spot the problem. Eventually somebody would come along with the time and the energy and the commitment to diagnose the problem. Raymond named this "Linus's Law" after Linus Torvalds. Raymond is a great admirer of Torvalds and thinks that Torvalds's true genius was organizing an army to work on Linux. The coding itself was a distant second.

Of course, waiting for a user to find the bugs depended on there being someone with enough time and commitment. Most users aren't talented programmers, and most have day jobs. Raymond and the rest of the free source community acknowledge this limitation, but point out that the right person often comes along if the bug occurs often enough to be a real problem. If the bug is serious enough, a non-programmer may even hire a programmer to poke into the source code.

Waiting for the bug and the programmer to find each other is like waiting for Arthur to find the sword in the stone. But Raymond and the rest of the free source community have even turned this limitation on its head and touted it as an advantage. Relying on users to scratch itches means that problems only get addressed if they have real constituencies with a big enough population to generate the one true believer with enough time on his hands. It's sort of a free market in people's time for fixing bugs. If the demand is there, the solution will be created. It's Say's Law recast for software development: "the supply of bugs creates the talent for fixes."

Corporate development, on the other hand, has long been obsessed with adding more and more features to programs to give people enough reason to buy the upgrade. Managers have long known that it's better to put more time into adding more doohickeys and widgets to a program than into fixing its bugs. That's why Microsoft Word can do so many different things with the headers and footers of documents but can't stop a Word Macro virus from reproducing. The folks at Microsoft know that when the corporate managers sit down to decide whether to spend the thousands of dollars to upgrade their machines, they'll need a set of new compelling features. People don't like to pay for bug fixes.

Of course, corporations also have some advantages. Money makes sure that someone is actively trying to solve the bugs in the program. The same free market vision guarantees that the companies that consistently disappoint their customers will go out of business. This developer has the advantage of studying the same source code day in and day out. Eventually he'll learn enough about the guts of the Source to be much more effective than the guy with the jammed printer and modem. He should be able to nab the bug 10 times more quickly then the free source hobbyist just because he's an expert in the system.

Raymond acknowledges this problem but proposes that the free source model can still be more effective despite the inexperience of the people who are forced to scratch an itch. Again he taps the world of libertarian philosophy and suggests that the free software world is like a bazaar filled with many different merchants offering their wares. Corporate development, on the other hand, is structured like the religious syndicates that built the medieval cathedrals. The bazaars offered plenty of competition but no order. The cathedrals were run by central teams of priests who tapped the wealth of the town to build the vision of one architect.

The differences between the two were pretty simple. The cathedral team could produce a great work of art if the architect was talented, the funding team was successful, and the management was able to keep everyone focused on doing their jobs. If not, it never got that far. The bazaar, on the other hand, consisted of many small merchants trying to outstrip each other. The best cooks ended up with the most customers. The others soon went out of business.

The comparison to software was simple. Corporations gathered the tithes, employed a central architect with a grand vision, managed the team of programmers, and shipped a product every once and a bit. The Linux world, however, let everyone touch the Source. People would try to fix things or add new features. The best solutions would be adopted by oth ers and the mediocre would fall by the wayside. Many different Linux versions would proliferate, but over time the marketplace of software would coalesce around the best standard version.

"In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect," Raymond said.

"In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena--or, at least, that they turn shallow pretty quick when exposed to a thousand eager code-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door."

11.2 THEY PUT A GIANT ARROW ON THE PROBLEM

..........................................

This bazaar can be a powerful influence on solving problems. Sure, it isn't guided by a talented architect and teams of priests, but it is a great free-for-all. It is quite unlikely, for instance, that the guy with the overloaded printer and modem line will also be a talented programmer with a grand vision to solve the problem. Someone named Arthur only stumbles across the right stone with the right sword every once and a bit. But if the frustrated user can do a good job characterizing it and reporting it, then someone else can solve it.

Dave Hitz was one of the programmers who helped Keith Bostic rewrite UNIX so it could be free of AT&T's copyright. Today, he runs Network Appliance, a company that builds stripped-down file servers that run BSD at their core. He's been writing file systems ever since college, and the free software came in quite handy when he was starting his company. When they started building the big machines, the engineers just reached into the pool of free source code for operating systems and pulled out much of the code that would power his servers. They modified the code heavily, but the body of free software that he helped create was a great starting point.

In his experience, many people would find a bug and patch it with a solution that was good enough for them. Some were just kids in college. Others were programmers who didn't have the time or the energy to read the Source and understand the best way to fix the problem. Some fixed the problem for themselves, but inadvertently created another problem elsewhere. Sorting through all of these problems was hard to do.

But Hitz says, "Even if they fixed it entirely the wrong way, if they found the place where the problem went away, then they put a giant arrow on the problem." Eventually, enough arrows would provide someone with enough information to solve the problem correctly. Many of the new versions written by people may be lost to time, but that doesn't mean that they didn't have an important effect on the evolution of the Source.

"I think it's rarely the case that you get people who make a broad base of source code their life," he said. "There are just a whole bunch of people who are dilettantes. The message is, 'Don't underestimate the dilettantes.'"

11.3 HOW FREE SOFTWARE CAN BE A BAZAAR OR A CATHEDRAL

.....................................................

When Raymond wrote the essay, he was just trying to suss out the differences between several of the camps in the free source world. He noticed that people running free source projects had different ways of sharing. He wanted to explain which free source development method worked better than others. It was only later that the essay began to take on a more serious target when everyone began to realize that Microsoft was perhaps the biggest cathedral-like development team around.

Raymond said, "I think that like everyone else in the culture I wandered back and forth between the two modes as it seemed appropriate because I didn't have a theory or any consciousness."

He saw Richard Stallman and the early years of the GNU projects as an example of cathedral-style development. These teams would often labor for months if not years before sharing their tools with the world. Raymond himself said he behaved the same way with some of the early tools that he wrote and contributed to the GNU project.

Linus Torvalds changed his mind by increasing the speed of sharing, which Raymond characterized as the rule of "release early and often, delegate everything you can, be open to the point of promiscuity." Torvalds ran Linux as openly as possible, and this eventually attracted some good contributors. In the past, the FSF was much more careful about what it embraced and brought into the GNU project. Torvalds took many things into his distributions and they mutated as often as daily. Occasionally, new versions came out twice a day.

Of course, Stallman and Raymond have had tussles in the past. Raymond is careful to praise the man and say he values his friendship, but also tempers it by saying that Stallman is difficult to work with.

In Raymond's case, he says that he once wanted to rewrite much of the Lisp code that was built into GNU Emacs. Stallman's Emacs allowed any user to hook up their own software into Emacs by writing it in a special version of Lisp. Some had written mail readers. Others had added automatic comment-generating code. All of this was written in Lisp.

Raymond says that in 1992, "The Lisp libraries were in bad shape in a number of ways. They were poorly documented. There was a lot of work that had gone on outside the FSF and I wanted to tackle that project."

According to Raymond, Stallman didn't want him to do the work and refused to build it into the distribution. Stallman could do this because he controlled the Free Software Foundation and the distribution of the software. Raymond could have created his own version, but refused because it was too complicated and ultimately bad for everyone if two versions emerged.

For his part, Stallman explains that he was glad to accept parts of Raymond's work, but he didn't want to be forced into accepting them all. Stallman says, "Actually, I accepted a substantial amount of work that Eric had done. He had a number of ideas I liked, but he also had some ideas I thought were mistaken. I was happy to accept his help, as long as I could judge his ideas one by one, accepting some and declining some.

"But subsequently he asked me to make a blanket arrangement in which he would take over the development of a large part of Emacs, operating independently. I felt I should continue to judge his ideas individually, so I said no."

Raymond mixed this experience with his time watching Torvalds's team push the Linux kernel and used them as the basis for his essay on distributing the Source. "Mostly I was trying to pull some factors that I had observed as unconscious folklore so people could take them out and reason about them," he said.

Raymond says, "Somebody pointed out that there's a parallel of politics. Rigid political and social institutions tend to change violently if they change at all, while ones with more play in them tend