Open Source Development Is Smart Business

It’s an interesting question: Why would large, established companies like Adobe and others embrace open source strategies? In some ways, it seems counterproductive. After all, releasing a software application’s source code to the community could be viewed as letting an organization’s competitive advantage walk out the door. However, as anyone involved in the open source community knows, this shortsighted view fails to acknowledge the true benefits of open source development.

I’ve been engaged in free software — which later became “open source” in 1998 — for almost two decades. I understand the community’s skepticism when it comes to corporate approaches to open source. I’ve seen simple open source concepts — such as free distribution, source code that can be modified, open licensing, and others — distorted by companies looking to sell products and recast their image as open. To succeed and truly benefit the open source community, companies need to find a balance between maintaining their competitive advantage and working closely with customers and developers.

From a corporate perspective, there are excellent reasons for adopting an open source strategy:

• There is an increased market demand for open source products.
• Development costs can be reduced by eliminating the need to reinvent existing, proven code.
• Companies can leverage ongoing community development efforts to enhance applications and better engage customers.
• Through an expanded user community, a company can establish broader adoption of its products and reach new markets.

Transforming Software Sales and Development

Open source today is an undeniable force that every technology company has to reckon with. Leading analyst firm IDC views it as one of the most important long-term trends impacting the software industry in the last 20 years. In a study that included more than 5,000 respondents, IDC found that open source software is used by 71 percent of developers worldwide — and already, open source applications are in production use at more than half of the respondents’ companies.

For technology companies, the challenge is balancing developer needs while still generating revenues to support ongoing application development. Fortunately, the two activities are not mutually exclusive. Vendors have adopted approaches to succeed in an open source marketplace, including a stack strategy that includes providing free SDKs and the option to buy libraries, as well as subscription models in which vendors fix bugs and certify an application’s readiness. There are also sales of hybrid products, which are expected to account for 80 percent of software released from the entire industry within the next four years.

One of the main differences for vendors selling applications today versus software sales in previous years is that many customers no longer want locked, shrink-wrapped boxes of software. Instead, they want the chance to further develop the application. It’s a new way of viewing the relationship between vendors — that previously owned and developed the solution — and customers who now have more freedom to deploy a solution tailored to their specific situations.

What Is Open?

With so many ideas about what open means, it is helpful to take a closer look at what “open” actually is. The reality is that openness can exist in many layers. However, for simplicity, I’ll break the discussion into some subsets:

• Programming interfaces: By making the communication conduits and language (values) available, programs can implicitly exchange information and interoperate.
• Specifications: Often you can find specifications that are available without business restrictions, from which you can build a product to manipulate or interchange.
• Standards: The nice thing about standards is there is always one to do what a company wants. The downside is that there are innumerable standards bodies, across industries and regions, covering a multitude of arenas with non-standard ways of determining what and how to create a standard.
• Open source: Obviously the most open way of communicating is to determine both the content and the intent of any message. By allowing view and modification of source, open source delivers a level of openness found in no other layer.

In short, being open really involves allowing access to the information necessary to take an appropriate action, either in implementing from a specification or adapting source code to provide a new solution.

For corporations, one of the first rules of open source development should be a commitment to sharing relevant code and not withholding patent rights. It sounds simple, but it’s not always the case. Corporations have to commit to giving developers access to the same code that is ultimately in the products they sell to the market. At the most basic level, a corporate commitment to open source is about playing fair with products and technology and keeping a dialogue open between a company and the community.

Many developers already feel there are too many open source licenses (as recognized by the Open Source Initiative.) When a company keeps delivering “vanity licenses,” its commitment to true open source development is questionable. Instead, a better corporate strategy — for the long-term viability of a company’s solutions, as well as for the broader development community — is to use open source licenses accepted by the majority of developers.

However, before going into more detail, this is a good time to highlight a common misconception that many still have about open source: that it equates to “free.” For anyone involved in developing open source applications, they know this is not the case. Building a community, maintaining sensible governance, integration expenses, ongoing build cycles, application research, and legal fees are just a few of the costs of corporate open source development. Yet, the costs are well worth the benefits of having a technology that is used and expanded upon by many of the greatest developer minds in the world.

Partnering With Designers and Developers

The reason why large companies embrace open source practices is simple: The market demand for products built with open source technologies is huge. In 1991, no one could foresee, for example, that in less than 20 years the then-unknown Linux operating system would power more than 35 percent of the servers at many of the world’s largest commercial and government organizations — or that it would also run on cell phones, desktop computers and even inside televisions.

No corporate development team gets excited about the idea of a product being in a perpetual beta state, but with open source, that is often the reality. In the past, companies have had the luxury of developing products, releasing them and then controlling future enhancements to the next release. Today, the release of an open source solution is just the beginning. Customers and developers can take a solution in directions that a vendor’s in-house development team never imagined — and then incorporate those discoveries into future releases. This sharing of expertise and building on knowledge is a vital tenet of open source.

Of course, true sharing of open source knowledge succeeds only when reliable specifications are in place. This goes back to the fact that development needs to be done using proven open source applications that adhere to universally accepted standards.

Balancing Risk and Rewards

Open source development has inherent risks and benefits. Regardless of the project, there are some standard rules that any company supporting open source should follow:

• Give credit where credit is due. If anyone uses something, be sure to give credit to the person or organization that created it.
• Return value equivalent to the value received. This does not mean releasing all products as open source, but continue providing open source components to solutions, and supporting open source foundations like the SQLite Consortium.
• Adhere to standards and build on accumulated expertise. Our job is not to tell our partners or customers what to do with the technology or how to do it. Instead, we want to provide the foundation to help them work smarter and achieve their business goals.

When I approach open source with the community — both internal and external developers — I think of it as a conversation. We need to be able to freely exchange information and speak a language we both understand. At the same time, we have to be open to letting people modify that conversation in ways we might not have ever imagined. For companies and for developers, that’s where open source really gets interesting.