9 Ways To Avoid Open Source Pitfalls

Microsoft recently rather sheepishly said it would open source its Windows 7 USB/DVD Download Tool, a utility that lets users create bootable copies of Windows 7 on flash drives and DVDs. The company didn't really want to do this, but there wasn't much choice once developers discovered that the software was built using open source code protected by licenses based on General Public License v2, which requires that the source code be made available to anyone who receives the object code. Microsoft isn't alone: The Software Freedom Law Center has identified one new GPL violation like this per day since late last summer, says Bradley Kuhn, the center's technical director.

Neither occurrence should be a surprise to anyone who follows open source software. I've been engaged in a wide range of open source software projects and communities, including the Android OpenMoko, and Maemo Linux-based mobile platforms. Violations are commonplace. However, if you follow the nine tips I present here, you can avoid problems, while still benefiting from what the open source software community has to offer.

1. Ask Why, Rather Than Why Not

It's always important to know why you're pursuing a particular course of action, and using open source software is no exception. Far too often, I hear "Why not?" as the answer when asking CIOs their motivations for engaging with open source communities. Using open source software doesn't just affect a company's R&D organization; it touches functions throughout the business as well, so it's vital to have a clear understanding of why leveraging open source software is the right option.

This also helps shape individual actions, provides developers with guidance, and helps the company shape its activities with the open source community.

2. It's Open, Not Free

A common misconception about open source is that it's free. Yes, you can gain access to millions of lines of code at no cost, but that doesn't imply a finished product. Common development tasks such as integration, regression testing, and the development of feature enhancements still need to be performed. And given that everyone--including your competitors--has access to the same code, your challenge is to build a high-value differentiated product with open source code alone.

While leveraging open source lets you redistribute where you spend your development dollars, it typically doesn't reduce that spending. However, it should let you invest more in the innovation and differentiation that you build on top of the open source code, and lower spending on core plumbing and building-block software.

3. A Different Development Model

Leveraging open source software isn't just about finding free code on the Internet and integrating it into your project. It has implications for your overall development model. Instead of traditional waterfall development models widely in use at large companies, open source projects often use Agile or Scrum iterative development methodologies where cross-functional teams collaborate to come up with requirements and solutions.

4. Define A Contribution Strategy

It's important to define a community engagement strategy and contribution policy that says if, when, and how you plan to give something back so you're not viewed as a "free rider." Simply taking and never giving is an open source no-no. Consider whether you'll contribute complete components or bug fixes. Determine whether you'll contribute during development, at service launch, or after launch. You also need to decide if you will provide maintenance and integration support for your contribution--especially if you're seeking to have your code integrated within future baseline releases.

Failure to define a contribution strategy and follow through on it can result in significant costs. For instance, if you're building a Linux-based platform and developing additional components, say a software stack that you know will become standard, then you run the risk that a competitor may contribute if you don't. This can result in core baseline software containing components that are less functional or core APIs that are no longer fully compatible with the components your team has developed. You may then need to make modifications or reintegrate onto each new baseline release, stealing valuable development hours from creating the next great thing for your company.

5. Select Your License With Care

Understanding the licensing models and their implications for your development work can be a challenge. It's worth investing resources to understand which licenses your company should use and which aren't appropriate for your development objectives.

Typically, when coming to open source for the first time, the focus is on GPL or "copyleft" licenses that often require derivative works be licensed under the same terms and conditions, and that source code be made freely available (private use excepted) along with a number of other key requirements. However, not all open source licenses are GPL--two other main categories are License Contracts and Permissive License Notices. These licenses are less restrictive and tend to be easier for commercial product developers to use.

Android, the Linux-based mobile device platform developed by the Open Handset Alliance, uses an Apache 2 license that lets companies use the source code in devices and make modifications without the need to contribute or open source the code, provided they include the license text. It's important to fully understand which licenses can be used in combination, as not all licenses can coexist within a common software block.

6. Don't Contribute Bad Code

It's just as important to test and debug code contributions before releasing them to the community as it is to do that before releasing software internally. Contribute buggy code and you'll quickly be seen as a poor community member and your code may not be integrated into future baseline releases. Buggy code can make it more difficult to attract the right talent to your business, especially if you're hiring from within the open source community. If you're developing internal products for your company, it can also affect the confidence the rest of the company has in the development group and if you're developing commercially, it can affect your overall brand. That said, releasing alpha and beta code is acceptable, provided you make it clear that that's what it is and document known issues. Keep it clean, protect your reputation, and you'll become a respected member of the community.

7. Pick The Right Business Model

A common open source debate is how to make money using open source software in a way that's acceptable to the community. A wide range of valid business models can happily coexist using open source software or even providing support services to those already engaged with the community. A number of companies build full software distributions, usually based on Linux, that include a range of open source software but fully integrate it into a usable platform. They provide consulting, support, maintenance, and adaptation services around these distributions. Other companies provide integration services that take open source components and integrate them in product baselines. Relying on the base open source components to build products with significant additional functionality often isn't realistic, so offering services designed to provide customization and extensions to these components is a perfectly valid business model.

8. Don't Require A Ransom

While there are many valid business models, there are also many that can alienate the open source community. One such model is referred to as "asking people to pay ransoms"--that is, contributing core engines or components to the open source community with the intent of making users dependent upon you for overly expensive customization and extension services. The community will quickly reject this model, and your components will likely be removed from the baseline in favor of alternative contributions. It can be surprising how fast the community can move when faced with being held for ransom.

9. Maintenance Isn't Free

While there are justifications for making open source contributions, expecting free maintenance isn't one of them. Most open source projects and communities rely on the good will of the members, be it their personal time or employer sponsorship. However, you can't contract with these sorts of communities to provide service-level agreements for maintenance support, achieve commitments for defect analysis, fix bugs, or set bug-fix priorities.

Get To Work

Putting tips such as these into practice is the first step in developing an effective and rewarding model for leveraging open source software. The core theme is simple: Plan in advance and consider your overall engagement model with the wider community, as opposed to just determining the software components you want to use. Leveraging open source has ramifications that ultimately touch many, if not all, areas of your business.

Andrew Till is VP of solutions management at Teleca, a mobile technology software provider.