The rise of the opensource movement a few years ago prompted the release of quite a few books that attempted to explain the seemingly revolutionary phenomenon. The Hacker Ethic, Free As In Freedom, Just For Fun and Under The Radar all did their best (among others) to explain what this new movement was all about. Yet, in all those other cases I got the feeling that their authors had missed something. Well, not in this case. Moody's book certainly is very ambitious in its scope, and therefore cannot study any of the main topics in-depth, but if you are looking for an overall analysis of the opensource movement, this is your best bet. Unlike other analysis, Rebel Code does not limit itself to Linux, and it goes much further, telling us about the GNU and FSF revolution, BSD UNIX, Apache, Sendmail, BIND, Mozilla, KDE, GNOME, Perl, Tcl, XFree86, the main Linux distributions... it truly is a tour (albeit a very quick and short one) through most of what opensource has to offer. Luckily, one also feels that Moody, unlike so many journalists who write pieces for mainstream newspapers and magazines, gets it. He has defnitelt done his homework and spent quite some time researching this book, and it shows. I could not find any major error or misinterpretation, which is definitely much more than I can say about most of those articles I was referring to. Even when he tries to explain technical concepts in plain language, the outcome appears to be correct in spite of the obviously needed simplification.

Unlike so many other people these days, Moody does not ignore the origins of opensource in Richard Stallman's GNU project. Yes, Stallman is quite stubborn. Yes, he is not the type willing to give in a little bit in the name of reaching a working agreement. Sure, he gets on people's nerves too easily. However, as he himself states in the book,

The only reason we have a wholly free operating system is because of the movement that said we want an operating system that's wholly free, not 90 percent free (...). If you don't have freedom as a principle, you can never see a reason not to make an exception.

(p. 29)

It is definitely some food for thought, even though (for the record) I side myself with the more pragmatic camp led by people like Linus Torvalds himself. Still, Stallman is right. Without his stubborness we would not be able to enjoy a free operating system today.

The book takes us then through the exhilarating days when Linus announces his project to Usenet, his online discussions with Andrew Tanenbaum over the excellences of a monolithic kernel versus a microkernel design, the first slow and then explosive growth of the Linux community (to Linus' surprise who, all of a sudden, found himself at the center of the hurricane), etc. Moody even gets into some level of detail about how X, the networking subsystem and NFS among other things were added to the main kernel, and does not show any restraint in detailing the major outbursts that nearly led to forks (or splits) from time to time. We also find some gems that give us insights into the minds of these kernel hackers. For example, Moody explains how Alan Cox turned to a new challenge (SMP) after he was done with the TCP/IP stack:

The equipment was supplied by Caldera as part of its efforts to add more commercial features to Linux. "They sent me the motherboard, two CPUs, and 8 Megs of RAM for it", Cox recalls. "In fact they sent me more memory, but I specifically wanted only 8 Megs for it because you don't find a lot of the bugs unless your machine is actually being hammered hard." In addition, he says, "I used to load it down with everything I could throw at it", in terms of strange peripherals.

(p. 114)

Not only is this interesting in view of more current events like the SCO lawsuit (as it turned out, Caldera was actively involved in the development of the SMP capabilities in the Linux kernel back then, which is precisely one of the areas of the code where they are alleging copyright infringement now), but it also shows the very characteristic mindset of the Linux kernel hacker: instead of testing the code with excellent state-of-the-art systems, they purposedly run it on old machines that are more prone to dig out problems and bugs. In other words, if it runs fine on an older machine, it ought to be even better on a new system. Of course there are certain drawbacks to this approach, but for the most part it works just fine. It could also explain why Linux tends to run much better on older machines than other commercial operating systems, therefore making it an ideal choice for legacy systems, poorer countries and non-profit institutions.

Likewise, we also read some great descriptions that come to sum up what opensource is all about and why it offers a truly revolutionary approach to the world of software:

[Red Hat's Bob] Young had finally realized "that the one unique benefit that was creating this enthusiasm was not that this stuff was better or faster or cheaper, although many will argue that it is all three of those things. The one unique benefit that the customer gets for the first time is control over the technology he's being asked to invest in." Put another way, open source software provides freedom —just as Richard Stallman had planned from the start.

(p. 225)

This is precisely a point that many analysts seem to miss when it comes to writing about the Linux phenomenon, especially when trying to understand its popularity among non-US governments. Its features or price are not nearly as important as the fact that they feel in control, which is not something they get from the traditional commercial vendors. This is all fine and good, but how about the companies? How do they make money out of it? Larry Augustin (ex-CEO of VA Linux which, by the way, was not precisely successful in its attempt to make lots of money ouf of it) has something to say about it.

"A customer comes along and they have a particular feature set they need," Augustin explains. "We can look at this archive of source code that comes from these Internet sites, and say, 'Well, here's an open source piece that's 80 percent of what you want.' We go to the customer and say, 'We can charge the amount of money it will take us to get from 80 percent to 100 percent and it will be all open source.' Our goal is to work with the developers on the Internet sites to actually get that piece of software from 80 percent to 100 percent for that customer."

(p. 250)

It all makes sense, or does it? Yes, most companies do not care much about the actual license behind the software they run. They do care about the functionality, about the application itself, but they could not care any less about the license or the vendor behind the tool. So, a model like this makes perfect sense, right? Not exactly. It does make sense for a large company, a non-profit or a government agency. However, things may be a little bit different when it comes to private interests that need to compete for every single customer. After all, why should a single company pony up the money that will take to take the feature set from 80 percent to 100 percent and then share the product with the competition, who did not pay anything? This still remains a question the open source companies must answer.

After the best exposition of what the open source movement is and where it comes from that I have seen in any book to date, the last chapter, Beyond the Market, reflects a little on the whole thing and manages to come up with a few intriguing questions of its own too. First of all, it is far from clear that commercial interests and the community development process will not collide often:

Tiemann makes an important point in this context: "The technical community sometimes has more patience and tolerance" than a business might have. "If one project is stalling", he says, "an enterprising young hacker may decide to go and work on a different project. But if you've got $10 million of revenue per year that you've got to handle, and you've got a 50 percent-plus growth rate that you're trying to maintain, stalls in the patch process become unacceptable."

(p. 306)

A second, perhaps more pressing issue these days, is the one that questions the legal consistency of the GPL license itself.

Some have suggested that the GNU GPL, the de facto constitution for the entire free-software movement, may not stand up in court. If this happens, it would cast a huge chill over the world of open source because it depends on the GNU GPL to regulate much of its operation.

(pp. 312-313)

Needless to say, SCO is already betting on this. But perhaps it is someone from inside the community itself, Larry McVoy, who is expressing the deepest concerns about the viability of the whole model in the long-run:

"The problem with open source," he explains, "is that the things that meet the Open Source Definition are all focused on rights for the end users, to the detriment of any rights for the vendor." The end result, McVoy believes, is that companies based around open source software can never equal Netscape, Sun, and Microsoft as industry behemoths. McVoy also thinks such companies are laboring under a fundamental misapprehension about the open source development model. "It's easy to do the easy work," he says. "You can have a weekend hack attack, or even a month-long hack attack and do something significant and get a lot of praise from the community." But he points out that after the easy work comes the grind. (...) McVoy doesn't even allow that unpaid hackers will be useful at finding bugs in code written by paid professionals. (...) "There are companies who are betting that part of their development costs will be gone because of the open source model," McVoy says. "And I think they're betting on a failing model." (...) "Red Hat is well on its way to putting [Sun's software division] out of business. Well, that's kind of cool for Red Hat, except for one problem. Red Hat doesn't generate enough revenues to pay for the software that they get —and they actually get some of that software from Sun. This is known in the industry as killing your supplier. It's not a good idea."

(pp. 314-315)

Would it be possible to find enough volunteer hackers who will do the work anyways? Perhaps. Is it not true too that, as open source becomes more and more popular, also more and more commercial vendors will pay their own developers to contribute code? Yes, most likely. Still, we have to acknowledge that McVoy raises some interesting issues here. This story goes on, and we do not know how it will end yet. Perhaps Glyn Moody will write release 2.0 of Rebel Code in a few years.

Entertainment factor: 6/10
Intellectual factor: 5/10