The free software movement started like many other movements: A group of bright, spirited people felt controlled by a greater power and rose up and took matters into their own hands.

It’s not that different from the American Revolution. The colonists were tired of being controlled by Great Britain, so they declared their independence and started building their own system of government and military, and creating their own cultures. The revolutionaries’ methods were disorganized and improvised, but they ultimately proved to be effective. Same goes for the software revolutionaries.

And the way those revolutionaries leveraged the power of openness has serious implications for today’s organizations—whatever the industry.

Here’s how it all went down.

The founding fathers

The free software movement dates back to 1968 when Ken Thompson, a heavy-set fellow with long hair, a scraggly beard, and big glasses, built the UNIX operating system.

Thompson built UNIX while working for Bell Labs. Throughout the 1970s Bell Labs distributed UNIX’s source code. Research labs, universities, and computer scientists all over the world contributed greatly to UNIX. UNIX was “free” software, out there to be adapted to any communication need.

But in 1979 AT&T then owned Bell Labs, and, claiming its copyright on UNIX, restricted access to the source code and charged money for it.

Programmers weren’t happy about that. UNIX had been a collaborative effort. They claimed that source code should be “free” and available—after all, they’d helped build it.

Richard Stallman, an MIT computer researcher with a hippie demeanor, first became interested in free software when the manufacturer of his printer refused to provide him with its source code to help him make it work. From then on, Stallman made “free software” his passion, becoming a vocal leader. In 1985 he started The Free Software Foundation in Boston, which still thrives today.

Stallman and other computer programmers started writing code to compete with UNIX and called this project “GNU” (short for “GNU is Not UNIX”). He distributed its code using “copyleft”—a play on the word, “copyright.” Copyleft enabled users to modify existing work and preserve it for public use. Computer programmers around the world participated in the GNU and other free software projects.

Proprietary software companies like Microsoft and IBM also built operating systems to compete with UNIX. But their operating system didn’t offer user-control, nor did they have features to assist the “can-we-build-a-version-of-Unix-ourselves collaboratively?” movement.

During the 1980s the collaborative efforts to build a better operating system lacked a key element: a “unifying kernel.” The kernel enables computers to link and multi-task and is part of the core software.

But in 1991 while working on a personal project, twenty-one-year-old Finnish student, Linus Torvalds, invented that unifying kernel. Months later he released it under a GPL (General Public License) and called it “Linux.” Programmers combined Torvald’s Linux kernel with existing GPL code and the entire operating system became known as Linux.

After that, most of Linux development took place under the radar (also the name of Red Hat co-founder Bob Young’s great book on the subject.) The only people who took it seriously were geeks and computers wizzes. They collaborated to solve each other’s problems, much like University professors collaborating on their research to shortcut the process and the time needed to institute their project—and also to lower costs. They improved Linux by creating applications and fixes.

Some of the early Linux programmers worked for big companies, but their managers mostly ignored their work. When business-minded executives occasionally did become aware of “free software,” they didn’t know what to do with it because it was foreign to them, too esoteric, even arcane. They typically considered it “research and development” of some kind—and dismissed it.

“This is headed nowhere”

In 1992, the scrappy entrepreneur Bob Young started publishing The Linux Journal after he’d sold his computer leasing business. Bob wasn’t a programmer, and, at the time, he was one of only a few business-minded entrepreneurs aware of Linux’s growing popularity.

“The journalists working for the big magazines in California were oblivious to it,” Bob says. “Or, if they knew about it at all, their reaction was exactly the same as my reaction in ’92 when I saw this stuff: ‘This is headed nowhere.’”

Bob assumed the programmers working on Linux were setting up a big corporation to take advantage of their work.

“When I asked them where this free software was coming from, they would use lines like, ‘You know, it’s from engineers according to their skill, to engineers according to their need.’”

Right. Thank you, Karl Marx.

“I thought, ‘Collaborative models don’t work. We are all altruistic people and that’s an important part of who we are as human beings, but for the purpose of deploying sophisticated technology across corporate users, altruism doesn’t work,’” Bob says. “Corporations need a wringable neck. They need to know there’s a 1-800 number standing behind their bright kids who are deploying this stuff. And the people have to be able to pay their mortgages if they’re going to continue to work on this. There was no corporation behind this free software stuff to pay their salaries.

“So, I knew, I just knew in ’92 when I first saw this stuff that IBM’s OS 2 or Microsoft’s Windows NT, or maybe UNIX or one of the commercial vendors was going to take over this opportunity,” Bob says. “I thought that it was a fun little experiment. Let these guys have their fun! But they’re just setting up the market for Microsoft to be successful.”

But what would proprietary software makers do about Linux? They had no real answer—somewhat like what the British monarchy’s dilemma with the revolutionaries.

The proprietary software makers’ business models were based upon keeping their source code proprietary. That stringent value kept corporate innovators pretty passive. So they mostly ignored Linux and didn’t seem threatened by it. They were busy trying to build their own operating systems.

Bob was surprised when Linux and the “free software revolution” gained momentum.

“Between ’92 and ’94, instead of free software going away, it kept getting better,” Bob recalls. “And more people were using it, but I was thinking, ‘This doesn’t make any sense. It doesn’t reconcile with my worldview.’ And none of the engineers I talked to about this stuff had any concept that there could be a business model around free software. And if there was no business model, it wasn’t going to succeed.”

Bob was dumbfounded by Linux’s sustainability and growing popularity.

“I decided that there was something going on here,” he says. “Either I had to change my worldview and recognize that altruism does work and is scalable, (which I did not believe) or there was something going on here that the engineers did not understand.”

To figure a way out of this quagmire, Bob went on a “tour” that took him to several Linux experts for answers: Why didn’t Linux programmers patent and sell their code? Why hadn’t technology firms capitalized on Linux?

One stop was the Goddard Space Flight Laboratory in Greenbelt, Maryland, a NASA research facility that was installing Linux. This tour stop was both enlightening for Bob and also instrumental in his creating Red Hat’s unique business model.

Goddard was making a big commitment to Linux—replacing a $5 million supercomputer they had bought three years earlier with $40,000 worth of PC hardware running Linux. Bob visited there with a programmer who was writing new Linux code for Ethernet drivers. His plan was to use the new code at Goddard, but also upload it for free, public consumption. Bob wanted to understand why.

“You’re spending real money on building these sophisticated Ethernet drivers. Why don’t you sell them?” Bob asked Tom Sterling, the programmer’s manager.

“Because in return for giving away our Ethernet driver code, we get a complete operating system with source code under a license that allows me to put it on as many machines as I can get my hands on—all for free,” Tom explained.

“Why are you building supercomputers that run on Linux? I know Sun Microsystems would be happy to give you source code if you would do this on Sun units.”

“Yeah, but if I do it on Sun, I have to get my lawyers involved to find out what I’m allowed to do and what I’m not allowed to do with their source code. If I use Linux, I get it with a license that allows me to do whatever I want!’”

Tom had just given Bob a valuable piece of the puzzle—control was users’ hot button, not features.

“So, what he was articulating was that he was not using Linux because it was better, faster, or cheaper technology,” Bob says. “He was using Linux because it gave him control over the technology. And he had no alternative—not from IBM, not from Microsoft, not from Sun, not from Apple—no commercial vendor would give him that benefit. I’m a sales guy. I don’t sell features. I sell benefits. And he had just articulated a benefit that no one was willing to deliver—control. So by then, the light bulb was flickering, if you like.”

In 1994 Linux was still a barely-talked-about solution for managing a computer’s operating system. Proprietary software firms were ignoring Linux as still being in R&D, so big software firms saw either few possibilities in or threats from Linux. But Linux was quietly gaining momentum, with shipments increasing to 1.5 million units in 1995 from only 100,000 in 1993.

Throughout the 1990s, more and more organizations started adopting open-source solutions. The pathway for open was finally laid. But it didn’t come without years of persistence and open-mindedness from creative minds seeking a better way to solve problems.

Lessons from the story

And that’s the story. Here are its lessons for your own organization:

• Allow your big ideas to slow cook. Collaboration with regards to fixing each other’s software challenges had been taking place since the 1960s, but it wasn’t until the 1990s before the open movement began benefitting a widespread number of organizations. What movements are slow-cooking within your own organization? If they are slow moving, don’t give up on them; instead, remain patient.
• Accept the next movement’s energy instead of fighting against it. Open is a here-to-stay movement. But what will the next movement be? The most successful organizations will embrace the next movement by taking human nature into account: spending patterns, technology trends, and psychological dynamics. The winning strategy is to go with the flow, listen, be alert, and remain balanced. It’s common sense to do so. It’s practical.
• Large organizations have a difficult time changing fast. Consider all the big companies that were aware of the open source movement throughout the 1960s, 1970s, 1980s, and 1990s. Not one of them could readily take advantage of it because their business models were too engrained to change. Can your organization recognize and take advantage of the next movements?
• A few creative, thoughtful people can make a huge difference. To be sure, thousands of people contributed to the open source movement, but a few who were especially open-minded and gritty contributed most. Does your organizations have open-minded and gritty people like Richard Stallman? How do you support them to improve your organization?
• Ask the right questions. Bob Young was a quintessential listener. He had an advantage over industry insiders because he wasn’t too close to industry—enabling him to see the bigger picture. Bob came to realize that listening to customers would be the key to open source’s success. “I saw an opportunity,” Bob says. “I saw the benefit of open source articulated by guys like Thomas Sterling at Goddard. What all the business guys working for Oracle and Sun Microsystems and Microsoft and all the rest didn’t have the opportunity to see because they weren’t asking the questions.”
• Discover your competitive advantage. Many organizations are tempted to push their features instead of their benefits—which are what people really care about. What are your organizations true benefits? Is it control? Is it time-savings?