The statement that Bill Etherington, Senior Vice President and Group Executive, Sales and Distribution, IBM Corporation made at link_2001, IBM's third annual Supply Chain Management Conference, couldn't have been more unambiguous. As he stood on the stage in the arena at the MGM Grand Hotel in Las Vegas he announced: "Linux is the future." He went on to say that IBM is investing $1-billion in this operating system and has some 1,500 people writing middleware for it. "Proprietary systems are dinosaurs," Etherington, stated, and took a crack at both Microsoft and Sun.
For many of you, Linux is something that you've probably heard of, but don't find to be particularly relevant to your daily computing activities (yet). You may have heard something of the story of the development of the free operating system, something about how a 21-year-old student in Finland, Linus Torvalds, created this system in 1991. As Torvalds was to post on a newsgroup (comp.os.minix) in August of that year:
"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for the 386 (486) AT clones. This has been brewing since April, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat...I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-)"
The point of interest in this is two-fold: One is that here is a guy who is developing something that he knows other people will be using and who invites them to participate in providing him with information relative to what they'd most like. How many companies have to initiate complicated programs in order to find out something about the "voice of the customer"? Torvald's approach is somewhat more efficient, don't you think? The second point of interest is that last clause: "but I won't promise that I'll implement them." It seems that in the drive to become increasingly "consensus oriented," too many people in organizations created a situation wherein decisions are greatly delayed (it takes a long time to get "buy-in") and the outcomes are watered down (getting something satisfactory to plenty leaves little in the way of extremes).
Listen to Glyn Moody in Rebel Code: The Inside Story of Linux and the Open Source Revolution (Perseus Publishing; $27.50): "The Linux movement did not and still does not have a formal hierarchy whereby important tasks . . . can be handed out, an apparent weakness that has proved a strength. A kind of self-selection takes place instead: Anyone who cares enough about developing a particular program is welcome to try. Because those most interested in an area are often the most skillful, they produce high-quality code. If they succeed, their work is taken up. Even if they fail, someone else can build on their work or simply start again." Let's break that down a little: "Anyone who cares enough." "Because those most interested in an area are often the most skillful." "Even if they fail." What we have here are people who are doing something for the right reason (because they feel passionate about it), people who have worked to increase their proficiency, people who understand that they may fail but aren't afraid of it. What better working arrangement can there be than that? I can assure you that the amount that I know about the intricacies of operating systems can be contained in this (), but I must say that in terms of looking at how to create great groups through letting self-organization occur and providing freedom to opt in—or out—Rebel Code is exemplary.
"But we make cars." "But we make ____________." Yes, Linux is different. But no one progressed by just doing the same thing the same way. Just ask the dinosaurs.