The kitchen is the receptionist at Collab.net, a software start-up in the South of Market neighborhood of San Francisco. No one is present to greet an inquisitive visitor walking through the open door on the fourth floor of a nondescript building -- just stacked cases of Snapple fruit juice and giant bags of pretzels; a refrigerator and a sink; a coffee machine and a water dispenser.
The ambience screams of youthful coder necessities. On top of the refrigerator, huge boxes of Trix and Cap'n Crunch line up like crates of ammunition. Next to the sink sits a large jar of Twizzlers. From the large, open room stretching beyond the kitchen, a seductive slither of spooky trance music pulses -- inviting, and yet at the same time a little intimidating. People who work in this kind of environment are almost too cool.
A few concessions are made to the sensitivities of the less hip -- the potential investors or clients from the old world of computing who might drop by, looking to dump a million bucks here or there. Along one wall stands a free-standing rack packed with hundreds of issues of business/high tech magazines -- The Industry Standard, Business 2.0, Red Herring, Fortune.
The magazines may not make good marketing material right now. Collab.net, the brainchild of open-source star Brian Behlendorf,* aims to make a business out of, he says, "distilling the principles of open source." But at least half of the covers of these new-economy bibles are screaming dire, boldface warnings about the current dot-com meltdown, including Wall Street's sharp turn away from Linux-related stocks in the spring and summer.
It's a good thing the office tunes are soothing, because jangled nerves are suddenly everywhere in that strange land where free software and dot-com start-ups mix. In the summer of 1999, Red Hat's IPO, occurring right in the middle of a packed LinuxWorld convention, sent attendees into a dither of delight. But in mid-August, no less an authority than the New York Times takes advantage of another LinuxWorld convention to declaim about how Wall Street is souring on Linux.
The Gray Lady is a bit late to the story -- the trade press has been hooting about declining valuations since early in the spring, and competitors have long become adept at using the stock price declines of companies like Red Hat and VA Linux as evidence that the open-source upstarts don't pose a threat to established, proprietary software enterprises. Critics of free software are also muttering about continuing delays pushing back the release of the next version of Linux, and the failure of Netscape's Mozilla project to release a usable browser.
But the Times may also be a bit overeager: Barely one week after August's LinuxWorld, Linux companies like Caldera and VA Linux handily beat analyst estimates and watch their stock prices surge. Linux investors suddenly rejoice.
And yet, those who take heart in a one-day surge are just as guilty of overeagerness. Both cynics and Pollyannas are like marks suckered into a New York huckster's game of three-card monte. While they busily stare, striving to follow the movements of the dealer's hand, they never notice that Times Square around them is meanwhile being transformed from pimp heaven into Disneyland. Sure, companies in the business of selling Linux may have questionable prospects -- but the open-source revolution is still in full effect, rebuilding the software industry from top to bottom, forcing everyone to adapt.
Corporations involved in the software industry are exploring open-source software, some with the enthusiasm of bodysurfers losing themselves in the roaring surf, others with the timidity of diffident waders in a lagoon full of sharks. They are by no means unified in their approach as an industry sector, or even internally within a single company. But there are executives and engineers at all of these companies who believe that an extraordinarily clear business case can be made for open-source software: Figure out how to make it your friend, before it starts dancing on your grave.
To see this process in action, you don't need to look further than the computer industry's venerable giant, IBM -- which has become perhaps the best corporate friend open-source software has ever had.
The morning of Dec. 16, 1999, started out as it usually did for Linas Vepstas. Warming himself against the Austin, Texas, winter cold seeping through his drafty, unheated house, he settled down to read his e-mail and drink his coffee. Sometimes the ritual was a relaxing way to ease into the day; other times, the caffeine and the messages would combine to get him bouncing off the walls. Like most hackers, Vepstas lived his life via e-mail -- his main hobby, at the moment, involved coordinating a major Linux project via online communiques with an international band of similarly dedicated coders.
But his e-mail on this winter morning was neither soothing nor invigorating. It was paralyzing. In just a few lines, all the work he had done for the last year and a half evaporated.
The message came from Alan Cox,* a man widely considered to be the second most influential hacker in the Linux community, after Linus Torvalds. From his home in Swansea, Wales, Cox -- his independent contractor's salary paid by Red Hat -- fulfilled an extraordinarily important role as maintainer of the Linux kernel.* While Torvalds was off working on the next version, Cox spent much of his time consolidating bug fixes and patches to older versions -- keeping the kernel up to date and secure, extending its ability to interface with new kinds of hardware.
The message read as follows:
They finally delivered code. A decent-looking SMP kernel, console and some networking stuff. Glibc, gcc, binutils, gdb patches.
The kernel stuff is in 2.2.14pre14. I'll forward you the other patches if you want.
Alan
"They" meant IBM. And the "code" was a package of extensions and patches to the Linux kernel and other associated free programs, created by a team of IBM programmers in Böblingen, Germany, near Stuttgart. The additions made it possible to run Linux-based operating systems on IBM's top-of-the-line mainframe computer, the System 390.
Vepstas stared at the message from Cox in shock.
I tried to read a few more e-mails," he says, "but found I couldn't concentrate. I bit my lip, I bit my tongue. I'd long ago learned the lesson of regretting one's words, and wasn't about to regress. A measured response would come later."
Vepstas was irritated for several reasons. He had heard rumors about the Böblingen "skunk works,"* but nothing definitive, nothing as impossible to ignore as the actual delivery of code. He felt he should have been better informed. At the very least, he thought he deserved first notice of IBM's official efforts.
For the better part of two years, Vepstas and a small cadre of programmers had been writing their own version of Linux capable of running on the 390. The project was called Bigfoot, and it had attracted a fair amount of admiring -- even if somewhat perplexed -- attention from the Linux community. Mainframes were "big iron," the biggest, most powerful and expensive computers available this side of a supercomputer -- the kind of computers that a bank or an airline would use to run its operations.
Once upon a time, mainframes had ruled the computer roost. But toward the close of the 20th century, mainframes had lost some of their grand allure. During the '90s, the network came of age, and scampering, decentralized agglomerations of PCs made lumbering mainframes seem like evolutionary losers. Heck, all you needed was a cheap PC, a Linux-based operating system and the Apache Web server, and you could host your own Web site, right?
Right, and wrong. By the end of the '90s, mainframes, much to the surprise of some observers, were back in favor. Only now they were being called "servers." The reasons for their comeback? Running Web sites had become big business for many companies, including a significant portion of IBM's traditional Fortune 500 customers. The pure processing power and ironclad reliability of the monster mainframe was once again beginning to look attractive, as the Web increasingly became part of an infrastructure channeling massive quantities of mission-critical data in torrents that would drown even the mightiest of PCs.
Vepstas wasn't particularly interested in the resurgence of the mainframe market; he wanted to hone his technical chops. To get Linux to run on a killer machine like the 390 would be a nice hack indeed -- he would have to write his own compiler and assembler and master the tricky job of porting an entire kernel to a new hardware architecture. As Vepstas notes, the 390 had "a fabled, legendary status as a computer design, and I figured it was damned high time I learned it."
But Linux had originally been designed to run on cheap Intel PC hardware. And the 390 already had two different proprietary-to-IBM operating systems designed just for it, considered by many IBM engineers to be the culmination of decades of the best work of IBM research and development talent. Getting Linux to run on an IBM mainframe was not only technically challenging, but also seemingly pointless -- like using a cheap, tinny transistor radio as the sound system in your brand new BMW.
As it turned out, IBM had very good reasons for wanting Linux running smoothly on the 390 -- as well as for keeping the project quiet while it was still incomplete. But on the morning of Dec. 16, nothing could have prevented Vepstas' shock from quickly turning to anger. As he wrote to the Linux/390 mailing list on Dec. 18, after IBM announced to the world what it had demonstrated to Cox two days earlier:
"I personally have spent many evenings and weekends working on this project, without pay, for just the glory of it," wrote Vepstas. "Although I cannot speak for others, others have also invested their time. I am not happy; I take IBM's actions to be a personal affront."
Eight months later, Vepstas has let his grudges subside -- he's immersed in a new project, GNUCash, a free personal-finance management program. He's moved on. But at the time, Vepstas could be excused for feeling slighted. One of the motivating forces fueling free software hackers is the reputation game -- the better the hack, the more cred you get in your community. But by obliterating his project, IBM had eviscerated his chance for such cred. His own background as a programmer who had worked for IBM for 10 years made the blow hit especially hard.
Hurt feelings were only one part of Vepstas' discontent. Of larger concern was the fundamental contradiction between a "skunk works" project -- carried out in secrecy, not only from the rest of the world, but also from the rest of IBM -- and the basic philosophy of open-source software. Ideally, open-source software involves the coordination of large numbers of programmers, thus reducing unnecessary duplication of work and improving the chances for peer review. Even more fundamentally, open source is open: Everyone gets to look at the code. But IBM's programmers had done their work in private. Was the company attempting to gain the advantages of Linux without allowing the collective participation essential to a smoothly functioning (and ideologically correct) open-source effort?
"Without conversations and communications, development cannot be coordinated," Vepstas declared to the list. "We could have gotten more done, been further along. Due to bad management decisions within IBM, time was wasted and money was wasted. I believe that these bad decisions were made because the managers do not understand the open-source development process. This is why I write this screed."
"Lack of transparency and secretive development leads to other problems besides just wasted and duplicated effort," continued Vepstas. "It directly harms the open-source community, and directly harms the corporate image and credibility of IBM. I have a four-year-old son who has recently learned the phrase 'trust me.' He says 'trust me,' and then, minutes later, is doing something bad again. We are trying to reason with him: 'You know that is a bad thing to do. Why did you do it? Next time, think before you act. Do the right thing. If you always do the right thing, then we can trust you.' (Unfortunately, the only effect this has had is that he's stopped saying 'trust me.')"
Perhaps the most incongruous aspect of Vepstas' unfortunate experience with IBM was its context. IBM boasts a reputation for playing by open-source rules that surpasses that of any other major computing corporation. Even Richard Stallman, a man utterly unafraid of castigating the high and mighty, has little negative to say about Big Blue. Indeed, the eyebrow-raising announcement, in the summer of 1998, that IBM was basing its WebSphere family of e-business products on the Apache Web server program did more to create a relationship between the world of open source and the established corporate software industry than any other single act.
Today, IBM executives like to portray the Linux-for- the-390 effort as part of a coherent strategy aimed at coming to grips with vast changes overtaking the software landscape, changes it saw coming way back in 1998. As Bill Zeitler, the general manager of the Enterprise Servers division, declaims -- "It is in IBM's strategic interest to work as closely with the open source community as we can... This is not a fad -- this is a profound disruptive change in the way that software will be developed and deployed." So Linux for the 390 is not only the crown jewel in a current initiative to support Linux on every level of IBM hardware, from Thinkpads to mainframes, but is also the logical conclusion to a three-year journey of rapprochement with the world of free software.
The truth is a little more complicated.
The story of how IBM made friends with free software hackers, from the early days when it dipped its toes into the Apache Project to its current headfirst plunge into Linux, is not the story of a carefully executed strategy. It is instead a tale of contingency, luck, a few committed engineers and a few canny executives. Its twists and turns hinge on the results of combating agendas, political maneuvering and software ambition. At its most mundane, it is a story that hints at how the battle for dominance over new software markets will be waged over the next few years. At its most metaphysical, it is a story that illuminates the contradictions inherent in the very concept of a "corporation."
It's all too easy to see a company like IBM, or Sun, or even Microsoft, in the terms of the legal fiction that is represented by the word "corporation," to anthropomorphize it as a "body" and give it attributes -- evil, good, brilliant, stupid, spunky, lumbering. But the modern corporation is far too fragmented and balkanized to personify in such simple, unitary terms.
The 390 Project provides a perfect example. The engineers responsible, a group of young Germans, wanted to, in the words of team leader Boas Betzler, "do something totally strange. We were just a group of techies that wanted to find out how smart we were."
"In the beginning, we really did not think about how big an impact we could make," says Betzler. "We always wanted to demonstrate the power and capability of the mainframe and then give it to someone who would know Linux and see the machine and use it and say 'Wow, that's a really big Linux.'"
A higher tier of engineers, those who defended the project in turf wars within IBM (or hid knowledge of it from competing factions), saw a chance to make a strategic move that would help boost 390 sales -- by ensuring that the 390 would be a platform comfortable with the vast array of Unix/Linux applications available. Even further up, executives jockeying their way up the corporate ladder placed bets on Linux as a means of gaining advantage in the never-ending political warfare that exists in any large company. And at the top, even CEO Lou Gerstner played a role, determined that if IBM was going to support open source, it wouldn't do so in a halfhearted manner.
Even Linas Vepstas, after his initial rage had subsided, acknowledges that IBM's internal politics made it impossible to allow the Burblingen team to interact with the wider open-source software community.
"I think many people don't realize how much the social dynamics inside of large companies [such as IBM] resemble that of the open-source community," says Vepstas. "It's just that within large corporations the cooperation and the bickering are hidden from public view. The Linux/390 guys within IBM were stepping on all sorts of land mines internally."
The huge importance of the 390 mainframe within IBM -- both symbolically and strategically -- ensured that the executives with the most knowledge about Betzler's activities kept them quiet. But at just about the same time Betzler got started -- the spring of 1998 -- other groups at IBM were reaching out to the open-source world with open arms.
On the corner of Third Street and Bryant, in the South of Market neighborhood of San Francisco, there is a restaurant known as the Big Tomato. Its real name is Vine e Cucina, but the local clientele are too busy programming or otherwise online-obsessed to be bothered with its actual name, and just refer to it by the unavoidable sign out front.
In 1998, the Big Tomato enjoyed a fortuitous propinquity to one of the world's most thriving physical nodes of Internet culture and business. Countless Web-related start-ups clustered in the buildings nearby. Organic Online, the high-end Web production studio that employed open-source star Brian Behlendorf as its chief technical officer, was just a few feet away. So were the offices of Wired magazine, for which Behlendorf, at the tender age of 19, had brought Wired's online adjunct, HotWired, onto the Net. Behlendorf still hasn't strayed far -- Collab.net, his current startup, is just another long block away.
So when people came to visit Behlendorf in his own neighborhood, there was a good chance that the Big Tomato was where they would end up -- which explains why one spring evening in 1998, he had dinner there with two representatives of IBM, James Barry and Yen-ping Shan.
In retrospect, the meeting was a dramatic turning point, the moment when the old world and new world of computing met to shake hands. At the time, though, unless you were a very close follower of the nascent open-source scene, you might have been excused for wondering what reason Big Blue could have for setting up a powwow with a ponytailed 24-year-old who split his time between Organic Online and rave DJing.
By that summer, Linux-based operating systems had already attracted a huge following, and earlier that spring Netscape had made the dramatic announcement that it would be releasing the source code to its Navigator Web browser. But the traditional corporate world, at least from a managerial standpoint, still didn't seem to know what to make of this hacker frenzy. Software engineers everywhere were already gung-ho, but the suits were a step or two behind.
James Barry and Yen-ping Shan weren't your ordinary IBM suits, however. Barry, the product manager for WebSphere, a set of closely related e-business programs, was a jeans-in-the-office kind of guy, and had been employed by IBM for little more than a year. Shan, IBM's chief architect for e-business tools, came from an engineering background. The two men were complementary halves to the same coin. Barry was a gregarious and jovial 43-year-old who in 1998 already had years of experience in online affairs, dating back to a bulletin board he had operated in Boulder, Colo., in the early '90s. He recalls, "Shan was the technical guy who knew a lot about marketing, while I was the marketing guy who knew a lot about the technology."
Both men were certain of one thing: It was in IBM's interest to support the Apache Web server, a program developed by a loose group of volunteer programmers led by -- or, more accurately, coordinated by -- Brian Behlendorf. But just getting as far as this meeting had required mastering an internecine political process at IBM that defied ordinary mortal comprehension. Engineers at IBM had been fans of Apache since at least 1996, when it was used as the Web server platform underlying IBM's Web-based front end to the Atlanta Summer Olympic Games. But IBM also owned Lotus software, which had its own Web server program: Domino Go. IBM software executives kept squashing engineering's Apache enthusiasm, tracing their mandate all the way back to the CEO, Lou Gerstner. You've got to eat your own dog food; if IBM had a Web server product, it should be pushing that product and using it for its own servers.
The only problem was, practically no one besides IBM itself was using Domino Go, which made it rather unwise to rely on the program as a first step for penetrating other Internet software markets. For months, Barry and Shan had been working to persuade IBM of Apache's strategic advantage.
First, Apache was what people were using. Shortly after Barry had been hired, initially as a consultant to evaluate IBM's "middleware"* offerings, he had lectured IBM managers on the fact that Apache was the most popular Web server program on the Internet -- and the single most widely used piece of software for the hosting of Web sites. Even in the Fortune 500, IBM's home territory, more companies were running their Web sites on Apache than on Domino Go. (Though, to be fair, some of those high-profile corporate sites, such as those belonging to Nike and Levi's, were actually being hosted by Organic Online.)
Second, although Apache dominated the statistics for publicly accessible Web servers, owning more than 50 percent of a hotly contested market, Microsoft's share was also growing steadily. And again, that growth was occurring in the well-heeled market sector that IBM most lusted after. Apache owned the low end of the market, but Microsoft was gunning for where the money was. If IBM wanted to prevent Microsoft from claiming yet another software market, it needed to join forces with Apache.
Third, since so many sites were using Apache, a vast amount of software tools had been created that would work with Apache. And since Apache was both open-source and conformed as closely as possible to all public Internet standards, it was easy to adapt those tools to different software platforms. According to Barry, if IBM came up with a set of software services that worked on top of Domino Go, it took a good deal of code rewriting to get that software to work with either Apache or Microsoft's IIS Web server. By making Domino Go the center of IBM's strategy, it was, in effect, handcuffing itself.
For a year and a half -- much of which, say his friends, was spent in the air traveling from IBM office to IBM office -- Barry pushed the open-source strategic imperative to anyone who would listen. If IBM was interested in fending off Microsoft, if it cared at all about creating the widest possible pool of customers for all the fancy e-business services that IBM wanted to offer its customers, then it must get with the real program -- the open-source program, the Apache program.
There was just one niggling problem, even after Barry and Shan finally won over higher levels of IBM management: IBM wanted Apache, but did Apache want IBM?
Certainly, Brian Behlendorf was cautious. He describes his own state of mind at The Big Tomato that night as "guardedly thrilled." Behlendorf is not by nature a suspicious man, but he was wary. He might still have appeared to be a wet-behind-the-ears Internet hacker, but he knew IBM. His parents had actually met each other while they both worked at IBM -- if anyone had grown up steeped in the culture of the computing industry's most dominant enterprise, it was Behlendorf. IBM had a way of swallowing its collaborators, of overwhelming smaller companies with its phalanxes of sales shock troops and mind-numbing invasions of managers. As a representative of not just the Apache Group, but all of emergent Net culture, Behlendorf couldn't help being restrained in the face of outreach from one of the world's biggest corporations.
Behlendorf did not "run" Apache. No one did. Instead, he helped coordinate the efforts of a group of programmers, all of whom for one reason or another needed a good Web server program to help them carry out their day job or hobby, to improve the existing publicly available Web server technology. The original base of code came from the University of Illinois, developed by the same team of programmers that had created Mosaic.
But those programmers had moved on en masse to Netscape, which -- at the time of Apache's emergence in the mid-'90s -- was developing, slowly, its own high-priced, proprietary Web server. Meanwhile, as the Web expanded at phenomenal speed, there was a drastic need for improvements to the existing freely available Web server code. All across the Net, webmasters were hacking their own patches* to the code, quick fixes that would help them respond to their daily needs. Finally, a group of these programmers got together, collated all the patches and created "a patchy server" -- Apache.
Behlendorf's influence came through his calming presence on Apache-related mailing lists, as the systems administrator for the Apache Web site and as the maintainer of the Apache "source tree"* -- the code base for Apache to which the core group of some 20 programmers had access. His interest always was, and still is, to devise technological means of enhancing collaboration. Lacking the ideology of a Stallman, or the programming skills of a Linus Torvalds (he is quick to say of himself, with a self-deprecating smile, that "I am not a very good programmer"), his motivation has always been to create things that work, that get the job done.
Apache got the job done. It wasn't necessarily the best Web server, the fastest, the most powerful or the most secure. But it was still the most widely used, in large part because it handled, simply and effectively (and freely), the tasks that most people needed handling.
Of course, IBM had a different set of motivations -- generating revenue being chief among them. So when James Barry told Brian Behlendorf that IBM wanted to use Apache as part of its own family of e-business products, and that it wanted to start contributing to the Apache project, Behlendorf's first reaction, recalls Barry, was defensive. The Apache group did not want a giant corporation to come in suddenly and take over. Yen-ping Shan hastened to sooth him.
"I told him," recalls Shan, "that we are going to play by your rules, because we believe that your structure and practice actually works."
Shan added that IBM's support could only strengthen Apache. "There are multiple ways IBM is going to help," Shan remembers saying, "not just technologically but as an endorsement that will solidify Apache in the IT [information technology] world. IBM will announce enterprise-level support."
Fine. If IBM was going to play by Apache's rules, then that's what it would have to do to win the Apache group's support. To do that would require something a bit more substantive than taking Behlendorf out to dinner.
It would require code.
IBM had to become a contributor. And it would have to prove itself the way any Apache contributor did, by submitting patches that were accepted by the core as valuable improvements to the Apache code base. And it had to do so in a sensitive way. Behlendorf did not want to see hundreds of patches appearing from scores of IBM engineers. He didn't want IBM to suddenly dominate the open discourse of existing Apache programmers. If IBM wanted one of its employees to become a member of the Apache core (which Barry and Shan's boss had set forth as an essential requirement before greenlighting their mission to Apache), then that employee would have to earn his or her way there like anybody else, by merit, through the quality of his or her hacking.
Barry and Shan agreed. It wouldn't be easy. The very concept of an IBM employee contributing code to a project that wasn't owned by IBM raised hackles on legions of IBM lawyers. Traditional software industry policy held that an employer owned everything an employee did, even to the extent of idle thoughts the employee might linger over while showering in the comfort of home. There was also the sticky question of patents -- what if a contribution of code from an IBM engineer included concepts or techniques that had been patented by IBM -- what would happen to those patents if they became part of the public domain? What about liability issues?
Barry recalls with a pained grimace the months of meetings that had to be undergone in order to work out such issues. But, credit must be given to IBM's legal team. The issues were worked out. A single programmer, Bill Stoddard, was given the job of being the connection between IBM and Apache -- if any of IBM's programmers came up with a patch, Stoddard reviewed it first, and then he personally submitted to the Apache group.
And in the Apache group, good code always won the day. Stoddard's contributions were accepted. IBM was accepted. IBM endorsed Apache, and gave open source an entree into the land of the suits. And Apache endorsed IBM, proving that hackers could work with the biz guys. The announcement of the agreement generated some 1,000 media stories -- which, more than any other fact, Barry recalls with a rueful grin, sealed the deal for upper management. That kind of positive press was by definition a successful strategic move.
Today, all three representatives at that meeting have moved on to new jobs. Yen-ping Shan is the chief technical officer at the largest payments-processing firm in the United States. Brian Behlendorf is CTO of Collab.net. And James Barry works a desk about 30 feet from Behlendorf. He is now Collab.net's vice president of strategic development.
The summer and fall of 1998 saw one open-source-related announcement after another from Big Blue. IBM joined the Apache Project in June. In mid-July, two researchers named David Shields and Philippe Charles announced the release of a version of their JIKES Java compiler for Linux. By September they had open-sourced JIKES. At the same time, a Toronto researcher named Gary Valentin had completed his own skunk works project, porting IBM's db2 database software to Linux. Meanwhile, that spring, Boas Betzler and his Burblingen cohorts had begun work on their 390 port.
But there was still no companywide strategy. In various corners of the IBM empire, individual researchers like Shields or strategists like Barry (who met and became friends through an open-source mailing list started by Barry for IBM employees) were doing their own thing, but as a company, IBM was hardly united. Shields does recall one key meeting of the IBM Academy of Technology, a grouping of 300 of IBM's most distinguished scientists in October 1998, at which both he and Barry spoke, as crucial. The Academy declared Linux to be an "earthquake" (as it had earlier declared Unix and the Internet) and petitioned Lou Gerstner to review their findings.
But even though Gerstner formed a task force to study Linux, the struggle over policy at lower levels still raged without cohesion. Barry recalls how plans to write a version of WebSphere 3.0 for Linux were spiked by an IBM executive who gave a speech at IBM's research lab in Raleigh, North Carolina, declaring that Linux was "going nowhere." That executive, he notes now, without hiding his satisfaction, is currently in charge of an IBM division devoted to Linux.
The task force recommendations, says Barry, were watered down and "milquetoasted." IBM seemed lost at sea.
Then came the morning of Dec. 14, 1998.
That day, John Markoff, the lead technology reporter for the New York Times, wrote a short piece entitled "Sharing Software, IBM to Release Mail Program Blueprint." In it, Markoff detailed how IBM was planning to release a mail program called Secure Mailer, developed by a programmer named Wietse Venema, as open source. What the article didn't say was that the program had been something that Venema had created before joining IBM, that it had always been open source, and that IBM was only now acknowledging that Venema could keep working on it as an open-source project.
But that didn't matter. All that counted was that IBM CEO Lou Gerstner read the article, and, according to legend, immediately became apoplectic. As far as he knew, IBM already had a mail program -- it was part of the Lotus Notes package. And if IBM was endorsing open-source software as a worthwhile strategy, then Gerstner wanted to know about it.
James Barry says that Gerstner didn't care one way or another about open source as a software methodology. Barry says that Gerstner frequently liked to note, "I am not a technologist." What he cared about was strategy. Did IBM have an open-source strategy? And if so, what was it?
Gerstner started making phone calls. First he called his chief of software, who called his subordinate, who in turn called his. The conference call kept expanding, until it made its way down to the research director who managed Venema. By the end of day, Gerstner had his answer. There was no clear strategy. Or at least there hadn't been up to that point.
"There was that one morning in December of 1998, and by that afternoon the open-source strategy had jumped into the runway," says Dan Frye, IBM's program director for open source and Linux. "We talked to everyone in the industry. The answer we came back with was that open source was good for us."
As a result, Linux got the green light. The skunks could come out of the woodwork.
Of course, it still wasn't easy.
"Internally, the battles were amazing, and you could understand why," says Jeff Nick, chief architect for the System 390. "A lot of the [IBM] technical community was very incredulous about this. You grow up in an OS/390 [the operating system designed for the 390] community, and there is great passion and pride in the heritage of OS/390 and the integration of its capabilities into the hardware platform. To suggest that there is a value proposition for running an open-source, not controlled, Unix platform on our hardware, and to propose that Unix applications might be better suited for running on Linux on the 390, than on OS/390. I was almost seen in my own technical community, particularly in the system 390 design council, as antichrist. There were multiple painful meetings with my technical peers across IBM on the OS/390 platform. They were saying, you must be out of your mind, why would you want to do this, we need to protect the OS/390 environment."
"It was a huge risk," says Nick. "And the reason we were ultimately successful was that we could show that by supporting middle-tier Unix applications that are collaborative in a distributed environment with the 390 back end and by running that entire heterogeneous workload on our platform, we would actually in the end be providing a bigger platform for our customers than we would if we forced everything to be on OS/390. There's a huge risk in that statement, but we are banking on the power of open source."
Huh? Just what exactly is Nick trying to communicate here, in that mix of techno-jargon?
In essence, pretty much the same thing that James Barry and Yen-ping Shan were saying when they pushed Apache. There is a whole world of people using Linux-based operating systems and the vast ecology of programs that run on those operating systems right now. An enormous amount of work is being done using a set of tools that have a Unix heritage and are currently at home on Linux-based systems.
The Linux generation is in some ways the heart and soul of the Net, and its numbers, according to Nick, are surging. An entire generation of programmers has adopted Linux. It doesn't matter whether they are doing this because they hate Microsoft, or think Linux-based systems are technically superior, or just like to hack on free software. The fact is, it's happening. Market share for Linux-based operating systems -- and mind share for Linux among developers -- is continuing to rise.
By ensuring that Linux will run on the 390, IBM would ensure that its mainframes would be an attractive environment for all those programmers and system administrators to work in. A bank could use its mainframe to handle its massive data-processing needs, and at the same time allow its Linux-skilled programmers to do whatever they needed to do -- in particular, to make use of all the middle-tier software applications that have been developed to get things done in an open, Internet environment. By expanding the possibilities, IBM would be able to expand its own market penetration.
The break with tradition represented by IBM's decision to open up the mainframe to non-IBM software is hard to overstate. For decades, IBM banked on selling customers the entire "vertical" package. From the hardware to the software to the support, it was all Big Blue, all the way. But now, by acknowledging that it made strategic sense to -- paraphrasing Chairman Mao -- let a hundred software programs bloom on the mainframe, IBM was signaling that it knew it could no longer call the shots in the mainframe marketplace.
Again, it just doesn't matter, from this perspective, whether Linux-based operating systems might actually be technically inferior to their Windows NT or Sun Solaris competitors in certain aspects. I asked Nick why, if it made so much sense to try and take advantage of all those people with Linux skills, wouldn't it also be prudent to attempt the same with NT, and gain access to that huge world as well?
"It would be great if you could do that," says Nick. "But the difference is that because Linux is open source, which allows it to be worked on by a large collaborative set of developers, it has also been built to be platform agnostic. It's got what we call horizontal layering of function, so you can easily port the OS to multiple machine architectures and platforms. This is not true of NT and this is not true of most Unixes -- where each operating system has grown up tied to its machine architecture. "
In other words, Linux, even if it may have started out as a hack to run Unix on a cheap Intel processor, has since evolved into the ultimate protean operating system. Over the years, its functions have been streamlined and compartmentalized to the point where it has become relatively easy to adapt it to different systems.
As such, Linux-based operating systems (as well as BSD operating systems, although they represent a much smaller percentage of the current OS marketplace) are the true heirs of what one programmer once immortalized as the "worse is better" paradigm.
In the 1980s, a programmer named Dick Gabriel wrote a paper about the programming language C++ and the operating system Unix called "Worse is Better." His argument was that simple systems that get most of the job done are better at surviving, over the long run, than complex systems designed to do everything perfectly. Complex systems are hard to adapt to new situations, and can break down easily. Simple systems can be fixed quickly, and mutate even faster.
Today, Gabriel is the main open-source evangelist at Sun Microsystems, and C++ and Unix are the building blocks out of which the Internet has been constructed. Linux is just the newest all-purpose building material.
There's a "virtuous cycle" here that feeds voraciously on itself. As Linux is ported to an ever-increasing number of hardware platforms, an ever-increasing number of programmers gain the opportunity to work on code that benefits everyone. Which in turn makes Linux-based systems even more attractive.
And that's the business case for open source. At first listen, "worse is better" sounds like Orwellian doublespeak, a phrase designed more to confuse than enlighten. But in practice, "worse is better" is an actual evolutionary success strategy -- and nothing exemplifies its principles better than open source.
- - - - - - - - - - - -
Read Chapter One of the Free Software Project
Join the discussion on this chapter
Next installment: The Sun also rises on open-source software -- how Sun Microsystems, with a little help from Collab.net, is learning from its mistakes and joining the world of open source.
Shares