So they turn their attention to trying to understand the phenomenon, and the results they get are very interesting, often surprising, and sometimes startling. They find that open source has its own logic, albeit one that is sometimes very different from standard assumptions. They find that the concept of open source and the production model it enables is being leveraged in diverse areas outside software development, such as in the automotive and pharmaceutical industries. It is from this body of research that I approach these questions in this article. I will attempt to make sense of Sybase’s involvement in the Eclipse Data Tools Platform (DTP) project for the past two years and extract lessons from the mix. In doing so, I believe a clearer picture for why, and to what extent, companies can benefit from participation in open source projects will emerge.

If It’s Free, Where’s the Money?
People often stumble over the idea that open source software is free. This single idea causes a great deal of the confusion surrounding open source, and it’s not helped by the Free Software Foundation (FSF) and its slogan: “Free as in freedom, not free beer.” So, if the software is free, how do you make money (or get a return on your investment building the software)? The essence of the FSF slogan is that open source brings the freedom to modify and redistribute the software, but doesn’t preclude the ability to charge fees in doing so. The key point is that any fee charged must be incidental: it can’t be an intrinsic part of obtaining, modifying, or redistributing the software. (Of course, these liberties vary to some extent depending on the license applied.) So, compelling fees charged around open source software will have to do with the complementary goods or services associated with it, but not the software. This explains why companies like Red Hat can charge for, and actually get people to pay for, “free” Linux: they provide packaging, bundling, support, and training services as a complement to the software.

This is little comfort to most companies, especially those trying to sell software products. It seems that, if you step over the open source line, you forfeit any compensation you can extract from the software. Since most substantial software products are extremely costly to produce in the first place, and the marginal costs promise high returns once the initial development cost is incurred, giving away software into open source seems to be a very bad idea. And, thought of in this narrow focus, it is. Looking at the larger picture, however, gives a very different result.

It’s a mistake to concentrate solely on the value assumed to exist in the software. Software alone is of limited value. Software bundled in a solution from a trusted source is what compels customers to invest. Don’t ask the simple narrow question: Why should I give my software away? Instead, open source drives us to ask the more complex, but also more realistic question: How best to extract value (return) from my software development investment?

Here the answers aren’t so simple. You might be able to extract a certain value if the software is sold only in a proprietary fashion. Yet, you might be able to extract a higher value either by partially or fully using an open source model. In particular, value could come from:

• Driving interest in complementary products you offer where the margin is higher
• Building mind share in a key community
• Reinforcing brands and a reputation for leadership in an area
• Encouraging collaboration with lead users, to identify potential future market trends
• Encouraging contributions, in a variety of ways, based on the open source software
• Driving media interest
• Creating presentation opportunities in conferences and other forums that typically don’t accept commercial-only material
• Fostering a de facto standard around your open source components

The question is now more complex and subtle. We can no longer simply look at the development cost and direct return from software sales (cf., problems with the cost-based pricing of software), but rather have to pay attention to many factors to determine the highest likely return on the development investment.

The Privilege of Working for Us
There are a lot of open source projects. At Eclipse alone, there are 10 top-level projects and dozens of sub-projects within them. Popular hosting sites such as Sourceforge are even more crowded: in early 2007, it contained an estimated 100,000 projects. Finally, there are numerous other sites hosting open source projects, so clearly there’s no shortage of initiatives in this area. Among this vast universe of projects, however, relatively few are consistently active, and even fewer inspire the confidence of commercial adopters.

Yet even for the most popular open source projects, numerous studies have found that only a small core of key developers does most of the work, with a somewhat larger ring of occasional contributions by others. This might strike you as a bit strange: the projects are open source, so anyone can study the source code. So why do so few people contribute to development? Shouldn’t it be expected that many developers would try to build a reputation by making valuable contributions, especially to high-profile open source projects?

These questions have bothered the open source community for a long time. Newcomers to open source are often puzzled about why developers aren’t attracted to their projects. Worse yet, companies typically start open source initiatives with high hopes of attracting “free work” by top-notch open source developers and are sorely disappointed when such contributions don’t materialize. On the other hand, popular open source projects soon find no shortage in users willing to give advice, ask for enhancements, and yell about bugs. For many this situation is a rude awakening: instead of a free army of developers, a demanding mob appears.

Within the collective knowledge of the open source community, there are a few commonly accepted reasons why it’s hard to attract committed developers to a project. The first has to do with expertise: substantial projects typically require developers with very specific skill sets, and hence this limits the pool of potential contributors. Worse, the more specialized and valuable the skills required, the more likely such developers are fully employed without any time to work on open source projects. Next, there’s the sheer number of projects. There are only so many developers who are willing to work on open source projects, and there are a lot of projects to choose from. Finally, if you’re working essentially for free, there’s a strong incentive to strike out on your own and not follow the lead of an established open source project.

These reasons are compelling, yet they fly in the face of experience, having worked on open source. Within the DTP project, for example, there has been a steady stream of developers offering their services. Perhaps this is to be expected during the formative days of a project when people are staking out boundaries, but DTP has consistently gotten such offers. To date only one (NEC Soft) other than the “founding members” of the DTP project has resulted in actual developer contributions, let alone long-term sustained work. Part of this gap is no doubt due to misunderstandings about what’s actually involved in working on open source: once the terms of participation (many dictated by Eclipse Foundation policies) are explained, many potential developers withdraw. Yet, there have still been candidates (often associated with companies willing to work on DTP) for whom the conditions were acceptable and yet participation was not secured. Why is there such a low closing rate?