4 Key Principles for Creating Truly Open Open-source Projects

Scratch the surface of virtually any business, and you’ll find open-source technologies used for everything from Web servers, to databases, to operating systems for mobile devices. Although cost is often a factor for choosing an open-source solution over a proprietary one, most businesses aren’t just looking for a free solution when they choose open source: They’re usually also interested in the fact that open-source products are often more innovative, more secure and more agile in responding to the needs of the user community than their proprietary counterparts.

Indeed, the most successful open-source projects are built by communities based on principles of inclusion, transparency, meritocracy and an “Upstream first” development philosophy. By adhering to these principles, they can deliver significant value to both device manufacturers and service providers that transcend what’s offered by makers of proprietary platforms.

Open-source Principle No. 1: Inclusion
Inclusion, rather than exclusion, has always been a key tenet of open source. The idea is simple: No matter how many smart people your company employs, there are many, many other smart people in the world -- wouldn’t it be great if you could get them to contribute to your project? Successful open-source projects realize that contributions can come from anywhere and everywhere. By harnessing the capabilities of a larger community, open-source developers can deliver solutions that are often superior to proprietary ones. Contributions range from writing and debugging source code to testing new releases, writing documentation, translating software into another language or helping other uses.

Open-source Principle No. 2: Transparency
For a community development effort to work, members of the community need transparency. They need to know what’s happening at all times. By putting forums in place to encourage public discussions such as mailing lists and IRC, creating open-access problem-tracking databases using tools like Bugzilla and building systems for soliciting requests for new features, open-source developers develop a culture of trust that embraces transparency and tears down barriers -- which can stifle innovation -- between contributors.

For device manufacturers and service providers, this transparency translates directly into their ability to improve their own time-to-market and compete on a level playing field. The “Release early, release often” philosophy that frequently accompanies a transparent culture means they can evaluate new features earlier in the development cycle than they can with proprietary products. They can also provide feedback in time to influence the final release of a product.

In contrast, when a developer withholds source code until final release, those involved in the development process have a built-in time-to-market advantage over those without early access.

Open-source Principle No. 3: Meritocracy
Unlike the hierarchy of a traditional technology firm, the open-source community is one based on merit. Contributors to an open-source product prove themselves through the quality and quantity of their contributions. As their reputation for doing good work grows, so does their influence. This merit-based reward system creates much more stable development environments than those based on seniority, academic pedigree or political connections.

The Linux kernel is probably the best-known open-source project and operates on the principle of meritocracy. Linus Torvalds, founder of the Linux project, and a number of other maintainers coordinate the efforts of thousands of developers to create and test new releases of the Linux kernel. The Linux maintainers have achieved that status as a result of proven contributions to the project over a number of years. Although many of the key Linux maintainers are employed by major corporations, such as Intel and Red Hat, their status is a result of their contribution -- not their company affiliation.

Open-source Principle No. 4: “Upstream First” Philosophy
Finally, open-source developers who take advantage of existing open-source software projects rather than adopting a “Not invented here” attitude tend to be innovation leaders, especially in the fastest-paced markets.

While it is sometimes tempting to simply take source code from a project and modify it for your needs, without worrying about whether or not the original (upstream) project will accept your modifications, this approach typically leads to suboptimal results. First, you will be stuck maintaining this forked version of the project for as long as you need to use it. Second, if everyone adopted this approach, the upstream project would not benefit from the improvements made by others, which defeats one of the key benefits of open source.

So, the most successful projects that rely on components from other upstream projects have adopted an “Upstream first” philosophy, which means that the primary goal is to get the upstream project to adopt any modifications you have made to their source code. With this approach, your platform and other derivative (downstream) projects benefit from those upstream enhancements, and the platform does not incur the maintenance expense associated with maintaining a branched version of the upstream project.

by Derek Speed