Open Source Software: Who Gives And Who Takes
Chase Phillips used to spend up to 100 hours a week writing code for the Firefox browser. Bruce Momjian, a former teacher, manages the E-mail list for contributors to the PostgreSQL database. Brian McCallister spends evenings and weekends working on projects for the Apache Software Foundation. Swedish engineer Peter Lundblad labors over Subversion, a change management system for distributed development, at night "when the children are sleeping and my wife watches TV."
This spirit of volunteerism is alive and well in the world of open source software. Thousands of people donate their time and expertise to the benefit of all. But not everyone is giving as much as they're getting. Large companies, those with the greatest wherewithal to help, are surprisingly minor players in the roll-up-your-sleeves work of open source development.
Big companies are "great consumers of open source. They're very good at pushing the limits of what open source code can do," says Carl Drisko, leader of the data center consulting practice at Novell, which distributes SUSE Linux. But when it comes to pounding out code, Drisko says, "they don't have a lot of people contributing back."
That's too bad. Big businesses are among the major beneficiaries of open source, as they increasingly deploy Apache, Eclipse, JBoss, Linux, MySQL, and other open source tools. It stands to reason that corporate America would be doing its share to keep things going. The talented programmers employed by big companies could speed open source projects along and raise their quality.
But contributions from businesses are small, partly because of a cultural divide between the open source crowd and corporate software developers, says Brian Behlendorf, co-founder of the Apache Web Server project and CTO at software company CollabNet. In contrast to the bottom line business world, Behlendorf says, open source developers exhibit a "willingness to challenge authority, the passion to work on an interesting problem well past the end of the workday, and the time and space to be able to build the right solution to a problem rather than just the most expedient."
The folks who write open source tend to fall into two camps. Core contributors generate the creative code: new features and additions that amount to major improvements to a piece of software. These big project programmers generally come from small companies, universities, consulting firms, and government agencies.
Others dabble in the small stuff. They spot bugs, suggest fixes and improvements, and test code for a particular computing environment. There are thousands of these tinkerers. More than 10,000 people have made contributions to Linux alone in the past 10 years. It's here that employees of large companies are usually found.
Laboring In Anonymity
Most of the major contributions come from people like McCallister, one of the heretofore anonymous souls who writes open source without compensation. He has a demanding day job as a software architect for Ning.com, a startup trying to make it easier to construct social applications on the Web. On his own time, McCallister contributes to the Apache Jakarta Project and Apache ActiveMQ, a project that's still in incubation.
The work McCallister and others do will determine how open source evolves. More than 100,000 projects are under way on the SourceForge.net open source site, ranging from the Stellarium desktop planetarium to the Pentaho business intelligence system.
Corporate programmers are more likely to spot open source problems than fix them. "They're good at telling us where they think we're deficient," Novell's Drisko says. Drisko has worked with two companies that have 5,000 programmers between them, but neither is making contributions to the open source process, he says, mainly because the programmers are cranking out proprietary code for their companies.
That highlights one reason some companies aren't contributing to open source: They want to maintain rights to the software they develop, something they must give up under the General Public License that governs the use and distribution of much open source. Any new twist they might bring to an open source application would become available to competitors. The potential for litigation, such as the SCO Group's ongoing lawsuit involving the origins of Linux, also may have scared away some businesses.
Workload is a factor, too. Managers reason that if their IT staffers have time to contribute to an open source project, they don't have enough "real" work to do.
Still, some big companies do make contributions. Morgan Stanley and Bear Stearns over the last two years have regularly submitted bug fixes and tested code for Apache and the Tomcat servlet engine, says Mark Brewer, CEO of Covalent Technologies, which sells technical support for open source code to banks and financial services firms.
And credit is due to individuals who do their part and who also happen to work for large companies. American Express CTO Phil Steitz is a member of the Apache Software Foundation and a former Apache contributor. James McGovern, The Hartford Financial Services Group's enterprise architect, contributes to Apache ServiceMix as part of his interest in service-oriented architecture. McGovern writes test cases from home after work and says his open source work makes him a better IT staffer. "To interact with people in an open way and experience problems as the code is developed, I can't even quantify how powerful that is," he says.
But business participation is the exception rather than the rule. The Open Source Development Lab, one of the leading groups behind Linux, has seen its membership triple to 86 organizations over the past two years. All but 8% of those members come from companies that sell technology or from educational institutions. Among the exceptions are Bank of America, Credit Suisse, Goldman Sachs, and Google.
Boise Cascade, a paper and lumber products manufacturer, has no prohibition against staffers working on open source projects, although it can't sanction such work on company time, says Myron Blaine, an IT architect at the company. "If they have the knack to contribute, it makes them a better developer at work," he says. "I would be inclined to encourage it." Boise uses the Apache Web Server, Apache Tomcat, Linux, and the Alfresco content management system.
Big Names, Low Profiles
The long list of companies using open source includes ABN Amro Bank, Continental Airlines, Nielson Media Research, UPS, and Walt Disney. Many get their software and support from commercial open source suppliers such as Novell and Red Hat, which helps explain their low profile as code contributors. For such companies, open source is merely a different spin on a standard business arrangement. Nothing in the contract calls for altruistic givebacks.
Open source purists may be just as happy that corporate developers are occupied with other things. They worry that too much commercial involvement could distort the focus away from quality code and toward business ends.
MasterCard International isn't the kind of place likely to attract a lot of the kind of IT pros who work on open source projects, says Roy Dunbar, president of the company's global technology and operations unit. Its payment processing systems must execute nearly flawlessly, so MasterCard generally doesn't adopt new technologies until they've been well tested. While the company has great technologists, the kind of person attracted to writing first-version code isn't going to be drawn to working there.
Only a fraction of open source software is written by people paid to write it, usually programmers working for companies that have a direct interest in a project. Hewlett-Packard, IBM, Red Hat, and Sun Microsystems all sponsor such programmers. But they're a tiny minority. Out of 250 contributors to the PostgreSQL open source database, only seven are paid for that work. The Subversion project had about 200 contributors last year, and only 10 were paid to work on the software.
That leaves tens of thousands of volunteers writing code that's going to be torn apart in a public review process by people they've never met. Some are motivated by a passion for writing code or a curiosity for understanding how things work, and others by an idealistic desire to provide an alternative to products sold by multibillion-dollar software vendors. Some seek the camaraderie, the pride of working with others who appreciate the elegance of a well-written line of code. Some see an application that doesn't work as well as it could and can't resist trying to improve it.
For The Love Of The Game
One thing they have in common is enthusiasm. Momjian, 44 and married with four children, has been working on the PostgreSQL database project for 10 years. He has college degrees in history and teaching and taught high school computer science for five years in Philadelphia. One summer, he taught himself the C programming language, then took a job writing custom applications for law firms. He later learned all he could about databases.
That led him to a new job last month as senior database architect at EnterpriseDB, a company that sells a commercial version of PostgreSQL. He's one of the seven paid contributors to PostgreSQL, and he travels to far-off countries like Sri Lanka to speak about the software. He's also manager of the PostgreSQL E-mail list, with 51,000 recipients, and a coordinator of contributors. Momjian says 90% of his 243 annual contributors work for small companies, and they live in Alabama, North Carolina, Pennsylvania, and Texas, as well as England, Germany, the Netherlands, and Scandinavia. Only a few work for large companies, where the pressure to "get things done" can leave little time for outside efforts. While similar pressures exist in small and midsize companies, working for a large company means a lot of an employee's focus "is dictated by the organization," Momjian says. "Open source is more free-wheeling."
That explains why some open source contributors come from colleges and universities. Rex Dieter, a contributor to Fedora, a version of Linux distributed by Red Hat, has been computer manager for the mathematics department at the University of Nebraska for 10 years. His paying job is his top priority. "If I have spare brain cycles afterward, more power to me," he says. When he recently became a member of Fedora's board, his boss, the computer labs professor, shook his hand and congratulated him. "But they're not putting up billboards by the side of the highway," he adds.
In fact, open source contributors say their bosses and co-workers frequently don't know about the work they do on these projects or don't put much value on it. Peter Lundblad, a 29-year-old Swede who's married with three children, lives in Vaxjo and works for Sorman Information and Media, a 250-employee defense contractor. Lundblad is a prolific contributor to Subversion, which his company uses. Because of Sorman's defense work, Lundblad isn't allowed to contribute to the open source project from the office, and his superiors don't want him devoting work hours to it anyway. So he works on Subversion several nights a week at home. Says Lundblad, "They're aware that I contribute but probably not the amount of work I'm doing."
Many contributors say the challenge of developing good code provides all the recognition and satisfaction they need. "I love the fact that I have to post the reasons I think I'm correct in a public place," says Max Spevack, chairman of Red Hat's Fedora Project. "It forces me to defend my opinions."
Open source programmers are scattered geographically and usually do all their communicating online--E-mail, instant messaging, discussion forums--with only the occasional phone call. Their critiques of one another's work come in straightforward and often blunt fashion. Performance is a constant concern, so contributed code that consumes too many CPU cycles will get shredded. "Suddenly, 10 people you've never met are telling you what's wrong with your code," says Garrett Rooney, a coordinator of contributions to the Subversion project.
Such no-holds-barred peer reviews are rare inside companies. McCallister, who contributes to several Apache Software Foundation projects, says those kinds of challenges were critical to his education. He started out as an English teacher and became a systems administrator by teaching himself scripting languages like Perl. He continued his "sideways transition" by becoming a Java programmer and participating in the Object/Relational Bridge, Jakarta, and ActiveMQ projects at Apache.
"Working on the projects was instrumental in turning me from a hobbyist into a professional programmer," he says. He learned by following Apache project discussion groups, studying what were deemed the best practices in submitted code, and offering up his own code for peer review.
The Profit Motive
As open source software becomes more popular, the idealistic community of programmers faces a new challenge: the potential for a monetary wind- fall. There's a growing divide between noncom- mercial open source projects--where the whole trend started--and commercial projects done under the auspices of public companies. JBoss, MySQL AB, and Sleepycat Software, for example, keep tight control over code and hire core contributors, and the payoff can be substantial if these companies go public or are acquired by giants such as Oracle.
True believers have mixed feelings about the rise of a wealthy class within their ranks. "I've worked in academia for 10 years," Dieter says. "I haven't ever envisioned myself in a position like that."
The two models will have to co-exist. Out of 100,000- plus projects, only a handful will ever be acquired for large sums of money. Few open source projects are organized with the idea of making millions for the developers, Dieter says. Joining an open source team with the idea of financial rewards "is like going out for the high school football team with the idea of making it in the NFL," he says.
Open source programmers make their mark "with thoroughness, tenacity, a desire to solve interesting problems, an ability to take criticism, and they communicate well," Momjian says. While such attributes are common in the business world, they don't necessarily exist in the right blend to survive the rigors of an open source project. "Eighty percent of corporate developers won't have the skills," he asserts. Hard criticism, for sure. But the onus is on corporate America to prove him wrong.
The key ingredient is passion. Open source contributors have to become "emotionally involved, committed," Momjian says, but they can't expect much in return. The goals of the project are more important than the goals of individuals or companies.
In business environments, competitive concerns may win out. "I'm aware how difficult it can be to change the mind-set of the establishment to allow intellectual property to flow back out into the community," says Firefox contributor Phillips. "Most large organizations have teams of lawyers that are vigilant when it comes to copyright assignment and licenses. I've seen it take years for such a team to approve just one open source license for exporting code."
It's hard to believe open source wouldn't be better off without more involvement from the big companies that are such enthusiastic consumers. For now, however, conflicting interests mean the coding will be left to others.