4. Making Commercial OSS: Participating in external projects
12/27/2013 10:56 AM
This post is the fifth in a series that will explore why businesses should become active participants in open source communities. We’ll explore what open source is, the economics of OSS (open source software), who uses it, how to make projects successful, and how to participate in external projects. It will also taken a deep dive into more complex topics such as the commercialization of FOSS, community vs customers, managing inbound IP, licenses, software hygiene, and when NOT to publish a project.
Read the previous post: Making OSS: the considerations around a projects success
Start from the beginning: Intro. What is it?
Commercial Considerations in Producing OSS
In the last section we talked about the motivations for making open source software. We started with the need for software to seed the discussion, the need for clear motivation as to why to publish as open source software, and then the structural requirements to build a community (license choice, collaboration platform or forge, and governance considerations). Contributions are the lifeblood of any community, so lastly we talked about the need to build an onramp to encourage users that will hopefully become contributors, and the additional onramp needed to make it easy to contribute.
This previous discussion was a very general set of steps to consider, applying regardless of whether the maker of an open source project was an individual or a larger organization. Now we will look at the additional considerations needed if the maker is a company. We have seen the economics discussion as a major motivation, but now we need to dig down deeper.
We have two types of making to consider:
- A company can contribute to an open source project that already exists.
- A company can create a new open source project (either by publishing existing software or creating new).
Producing Commercial OSS (Part 1 - Participating)
If we consider a company making contributions to an “outside” project then we should do so from the perspective that this is an advanced case of collaboration where the open source project is being used in a product or service the company offers to customers for sale. Think Red Hat and using Linux to deliver Red Hat Advanced Server. Otherwise, contributing to a project that is used strictly in-house pretty much looks like the earlier discussion – it’s about engineering economics and shared innovation and living on a fork gets expensive over time unless it can be balanced against the costs of maintaining a business advantage through secrecy (e.g. the way Google used Linux in the early days).
Participating in an external open source licensed project is a case of expanding traditional corporate thinking of “build” versus “buy” to include “borrow” and “share”. It’s about time-to-solution if a company uses the project in-house and about time-to-market if the project is used to develop a product or provide a service to customers for sale. One needs to remember as a company using open source licensed software in a product or service that the company exists to solve a problem and create a marketplace around the solution.
The interesting problems when using an externally developed open source project as a company are in understanding the flow of ownership of the intellectual property with respect to the software. There are a couple of predominant concerns:
- What legal risks are possible that need to be managed against a company’s risk profile. This should not be taken lightly. Companies are more interesting legal targets than individuals. Even if a company is using the software internally rather than in a product or service, there is still a risk profile to consider. The risk is no greater than purchasing a proprietary software solution from a vendor but one needs to feel comfortable that the externally run open source project has appropriate IP management safeguards in place.
- Who is contributing what intellectual property to whom. Again, companies are often uncomfortable contributing their own hard won R&D investment to others (even partners) without crisply understanding the return and the ownership.
- Who owns the software copyright is a risk as well. This doesn’t simply apply from the perspective of using the software, but also from the perspective of whether the project owners can change the licensing terms, and whether this forces the company using the software to fork the software and pay the cost of living on the fork.
As a company each of these legal concerns comes with additional legal responsibilities. As will be discussed, open source software foundations provide solutions to these problems by providing neutral non-profit space in which companies can collaborate together, and backing the space with proper IP management practices. The Apache Software Foundation, the Eclipse Foundation, the Linux Foundation (né OSDL) and the Outercurve Foundation were all created to manage the software ownership neutrality, and the risk around these software IP problems.
Commercial participation in external OSS projects comes with well-understood risks, and the benefits likely outweigh the risks, and can obviously be managed as evidenced by the continued growth of FOSS in all aspects of software creation and use, from Red Hat’s use of Linux to IBM’s use of Apache.
Read the next post: Making Commercial OSS: Creating your own projects