* [1]News & Politics
     * [2]Culture
     * [3]Food

   [4]salon logo
     * [5]Science & Health
     * [6]Life Stories
     * [7]Video
     * [8]About

   [9]Newsletter
   [10]Profile Login/Sign Up Sticky Header: Night Mode: [11]Saved Articles [12]Go
   Ad-Free [13]Logout
   Sticky Header [ ] Night Mode [ ]
   Search ____________________ (BUTTON)
   [14]Subscribe

   Help keep Salon independent

   [15]salon logo
   [16]subscribe

How Big Blue fell for Linux

When open-source developers and IBM took gambles on each other, free software showed it
can flourish in the heartland of corporate computing.

By [17]Andrew Leonard

Published September 12, 2000 7:03PM (EDT)

   --

Shares

   Facebook
   Twitter
   Reddit
   Email

   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,[18]* 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,[19]* 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.[20]* 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,"[21]* 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 [22]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, [23]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"[24]* 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[25]* 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"[26]* -- 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 [27]"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 [28]Chapter One of the Free Software Project

   [29]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.

By Andrew Leonard

   [30]Andrew Leonard is a staff writer at Salon. On Twitter, @koxinga21.
   MORE FROM [31]Andrew Leonard
     ____________________________________________________________________________
     ____________________________________________________________________________

Related Topics ------------------------------------------

Related Articles
     ____________________________________________________________________________

   Advertisement:

     * [32]Home
     * [33]About
     * [34]Staff
     * [35]Contact
     * [36]Privacy
     * [37]Terms of Service
     * [38]Archive
     * [39]Go Ad Free

   Copyright © 2024 Salon.com, LLC. Reproduction of material from any Salon pages
   without written permission is strictly prohibited. SALON ® is registered in the
   U.S. Patent and Trademark Office as a trademark of Salon.com, LLC. Associated
   Press articles: Copyright © 2016 The Associated Press. All rights reserved. This
   material may not be published, broadcast, rewritten or redistributed.
   [40]DMCA Policy

   [p?c1=2&c2=38282684&cv=3.6.0&cj=1]

References

   Visible links:
   1. https://www.salon.com/category/news-and-politics
   2. https://www.salon.com/category/culture
   3. https://www.salon.com/category/food
   4. https://www.salon.com/
   5. https://www.salon.com/category/science-and-health
   6. https://www.salon.com/category/life-stories
   7. https://www.salon.com/tv
   8. https://www.salon.com/about
   9. https://www.salon.com/newsletter?source=header-link-desktop-newsletter
  10. https://www.salon.com/profile
  11. https://www.salon.com/profile/saved-articles
  12. https://www.salon.com/premium?source=user-dropdown-link
  13. https://www.salon.com/2000/09/12/chapter_7_part_one/
  14. https://www.salon.com/premium?source=header-link-desktop
  15. https://www.salon.com/
  16. https://www.salon.com/premium?source=header-link-mobile
  17. https://www.salon.com/writer/andrew_leonard
  18. https://www.salon.com/tech/fsp/glossary/index.html#brian_behlendorf
  19. https://www.salon.com/tech/fsp/glossary/index.html#alan_cox
  20. https://www.salon.com/tech/fsp/glossary/index.html#kernel
  21. https://www.salon.com/tech/fsp/glossary/index.html#skunk_works
  22. http://www.marist.edu/htbin/wlvtype?LINUX-VM.471
  23. http://www.gnucash.org/
  24. https://www.salon.com/tech/fsp/glossary/index.html#middleware
  25. https://www.salon.com/tech/fsp/glossary/index.html#patch
  26. https://www.salon.com/tech/fsp/glossary/index.html#source_tree
  27. http://www.jwz.org/doc/worse-is-better.html
  28. https://www.salon.com/tech/fsp/2000/03/06/chapter_one_part_1/index.html
  29. http://fsp.salon.com/webx?13@@.eead9ab
  30. mailto:aleonard@salon.com
  31. https://www.salon.com/writer/andrew_leonard
  32. https://www.salon.com/
  33. https://www.salon.com/about
  34. https://www.salon.com/about/staff
  35. https://www.salon.com/about/contact
  36. https://www.salon.com/about/policy
  37. https://www.salon.com/about/tos
  38. https://www.salon.com/archive
  39. https://www.salon.com/premium?source=footer-link
  40. https://www.salon.com/about/dmca

   Hidden links:
  42. https://twitter.com/Salon
  43. https://www.instagram.com/salonofficial/
  44. https://www.youtube.com/user/SalonDotCom
  45. https://www.facebook.com/salon/
  46. https://www.tiktok.com/@salonofficial
  47. https://www.reddit.com/domain/salon.com/
  48. https://www.linkedin.com/company/salon-media-group/
  49. https://www.salon.com/2000/09/12/chapter_7_part_one/
  50. https://www.salon.com/2000/09/12/chapter_7_part_one/
  51. https://www.salon.com/2000/09/12/chapter_7_part_one/
  52. https://www.salon.com/2000/09/12/chapter_7_part_one/
  53. https://www.twitter.com/koxinga21
  54. https://www.facebook.com/http://www.facebook.com/andrew.leonard.7503
  55. https://www.salon.com/topic/