BLOG

Making Commercial Open Source Software

Dec 18

Written by: Stephen Walli
12/18/2012 3:05 AM  RssIcon

I recently blogged about making open source software, and the high level steps for how to think about the process.  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 life blood 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. 

Rory MacDonald (@technocreative) challenged in the comments that there are substantial commercial motivations for a company to develop open source projects that go beyond a desire for collaboration, and provided a number of examples.  I completely agree, and I’d like to build on these ideas. 

Why as a company (rather than as an individual) would you want to “make” open source? 

Again 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).

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 discussion in the previous post -- 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.  This is all about Levitt’s observations about solving customer problems (“needing a 1/4 inch hole”) over selling products (“the drill”).  Red Hat wasn’t “selling a Linux distro” but rather providing a professionally maintained and supported low cost PC-based server replacement for expensive proprietary UNIX systems on expensive proprietary hardware.

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.  It’s not that the risk is greater than purchasing a proprietary software solution from a vendor but one needs to feel comfortable that the externally run open source licensed project has appropriate IP management safeguards in place.
  • What intellectual property is being contributed to whom.  Again, companies are often uncomfortable contributing their own hard won R&D investment to others (even partners) without crisply understanding the return. 

As a company each of these legal concerns comes with additional legal responsibilities.  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 risk around these software IP problems. 

The discussion becomes interesting when a company considers creating its own open source licensed projects.  Rory’s examples speak to benefits.  Let’s start with the motivation again.   People are often very good at understanding their “gut” motivation for doing something.  The larger a company becomes the more thought and documentation needs to go into such decisions, especially once a company goes public. 

If the project to be published under an open source license is “infrastructure” for the company, then the motivations are all based on shared innovation and distributed engineering economics.  This is what we see with data centre-centric projects created by the likes of Amazon, Yahoo, Google, Twitter, Netflix, or the Facebook Open Hardware Initiative.  The company starting the project is sharing work in which they have invested time and energy in the hopes that others will join the project, use it in new ways thereby hardening the software and contributing at the very least bug reports, but also hopefully extending and evolving it. 

When this is the motivation, all the discussion in the previous article comes into play around making open source.  Essentially, one needs:

  • Useful software as a base around which to build a community.
  • Motivation to share, credible expertise in the problem to be solved, and an understanding of the software structure to anchor the open source community. 
  • The project needs to have the structural issues of license, forge, and governance decided, even if governance becomes an evolving discussion in a growing community.
  • The community needs to build a solid onramp to encourage use, and a second onramp for users to become contributors.  The sooner this happens in a project’s life, the faster it can build a community.

The additional consideration to encourage corporate participation and contribution needs to be software ownership, legal risk, and IP management around the contributions.  This is where considering using existing open source software foundations comes into play.  Corporations are far more likely to contribute their software to a neutral non-profit for mutual benefit.

But as Rory points out, there are business motivations for creating open source projects as well.  A company’s executives want to “increase business” but does that mean increase leads in the sales pipeline?  Or build a community of evangelists that firmly anchor the company’s products and services while providing proof points and expertise to potential new leads.  

Using free and open source software in a commercial setting doesn’t change the nature of running a business.   One needs to clearly understand that customers buy solutions to problems and what problem the company is solving.  Geoffrey Moore demonstrated some time ago that companies offering the best “whole” solution win, i.e. a core product or service and all its complementing products and services around a more complete ecosystem. This has a lot to do with shaping a “complete” solution to account for the subtle differences that customers perceive they have around the problem space.  Successful companies essentially offer a portfolio of products and services and as long as the sum of the costs of delivering the portfolio is less than the sum of the revenues (spend less than you earn), the company is profitable.  Taking a portfolio approach allows a company to play with their pricing models and differentiate themselves for customers against similar competitors.

Open source software can play a number of roles in such a portfolio approach.  A company can:

  • Sell support, upgrades, customization, training and “stability” to a product that is otherwise provided as an open source project.  The best example is probably Red Hat “selling Linux” when it doesn’t own the core IP.  The “product” isn’t the software.  JBoss tried several of these approaches before their Red Hat acquisition.
  • Sell a core product (licensed as proprietary or open source) while encouraging an ecosystem of complements from partners around open source licensed projects.
  • Allow customers to try the “product” in its simplest form as a set of unsupported unwarranted binaries for “free”, i.e. downloading the community/developer editions, to self-qualify themselves in the sales pipeline.  (This was very much how MySQL built both its businesses.)

These items all speak to the delivery of the product and the pipeline.  A company can also develop a community of users of the open source project that act as a source of expertise and experience for potential customers.

A community of developers and users is an essential piece of the whole solution.  Some companies develop large successful communities without ever publishing their product software.  IBM, Microsoft, Oracle, and SAP have all done this to great success.  This is why community building is so important for your company and why community development is an essential ingredient in your solution pitch to customers.  User and developer communities (regardless of open source):

  • Anchor customers both in an engaged relationship as well as from a technology perspective.
  • Create knowledge, expertise and experience necessary to provide a complete solution for the technology pitch to the customer.  These proof points are invaluable when potential customers are self-qualifying themselves and testing the strength of a solution’s community.
  • Create advocates and evangelists to spread awareness about a solution.
  • Create enormous inertia in the status quo around a technology.

These variations all rely on remembering a couple of related “rules”:

  • An open source licensed project is not a complete product solution for most people.
  • Project community users and developers are not solution customers.  Community members tend to have time to spend on a solution but no money while customers have money and are looking for time-to-solution and certain guarantees.

Creating an open source project can be as simple as publishing software using an open source license, and this gives customers insight into the workings of a solution.  But if you ignore community building activities, you’re losing all the benefits that come from an engaged base of customers and users of your technology. 

Clearly understanding the benefits of using open source licensed software for delivering time-to-market, providing a rich complement ecosystem, and enabling communities to anchor the ecosystem in place allows a company to set its motivations correctly.  One can discuss the investment in effort as a way to understand the motivation.  We can contrast the publication of the software as open source and the effort required to develop the community against the evolution of the commercial product in terms of investment and value returned.

This also allows a company to understand the problems with half measures.  Companies sometimes treat “open source” licensing as marketing pixie dust, instead of rightly understanding its place in the solution portfolio or the need to build genuine community that will lead to solving customer problems, and ultimately delighting said customers which can be measured in profitability.  They try to limit access and only approach community half-heartedly because ultimately they’re unsure of the benefits.  Fully appreciating the benefits allows a company to fully engage with both community and customers to solve problems.

Rory also mentioned the use of open source projects to undermine a competitor’s margins.  This is a level of competitive play by large complex companies in well-established markets that warrants its own blog post.  We save it for another day, and instead stay focused on the commercial positives of making open source software. 

1 comment(s) so far...


Gravatar

Re: Making Commercial Open Source Software

Interesting post, and I broadly agree. But again, I can give you a couple of interesting examples to expand the discussion.

If I start with contributing to an external project:

I think there are a whole layer of development companies, and particularly companies who use technology as a part of a broader service (web development, campaign design, horzontal and vertical business consulting) for whom contributing to an open source product is an extremely effective form of marketing. These are often companies without the scale to develop their own open source product (often in a saturated space). However they can become recognised players in a market leading community.

About a year ago, I gave a presentation on marketing at a well known (single product) association. Stepping in as the slick suited marketing bod (which I do deliberately in order to conform to the sterotype), I told these guys that participating in the community, being active on the community boards, contributing to commits and fixes is marketing. It is one of the best forms of marketing and brand development available to a service business in this space.

If you look at the massive partner ecosystems around many popular open source products, contributing becomes marketing. In my opinion this is great to see.

I can recall two examples (probably best if I don't name them), where a popular open source product has been sold into a large govt/corp customer, by a large partner who was somewhat "On the bandwagon". They were a big name service company, the customer wanted to explore "open source" options, so they bought a relatively well known open source option, through a well known service company.

12 months in, the customer's own in-house team are getting to know the product and the community. They notice that the service provider they initially bought the solution through is nowhere to be seen in the community. When they file a bug, when they look at the really intelligent things being discussed within the community, it becomes apparent that they are dealing with the monkey and not the organ grinder.

They switch all of their future development and support to one of the more visible participants in the community.

Its a beautiful thing to see. It is open source economics at its best. Anyone who thinks open source "suffers" from the free rider problem - assumes the end customer is an idiot and that CIO's cannot read community noticeboards.


By Rory MacDonald on   12/18/2012 4:32 AM

Your name:
Gravatar Preview
Your email:
(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Security Code
CAPTCHA image
Enter the code shown above in the box below
Add Comment   Cancel 

Blog Roll

Indent Example
Sam Ramji
Thoughts from the President of the Board of Directors
Indent Example
Paula Hunter
On the business of OSS and Non Profit Foundations
Indent Example
Stephen Walli
Guest Blogger
Indent Example
Phil Haack
Project leader: NuGet
Indent Example
Bradley Millington
News from the ASP.NET Gallery Manager
Indent Example
Bradley Bartz
WebsitePanel Project Leader
Indent Example
Guest Blogger
Posts from Guest contributors
Indent Example
Spyros
Posts from DLSI Gallery Manager
Indent Example
Rob Mensching
WiX Project Leader
Indent Example
Eric Schultz
Developer Advocate
Indent Example
Bertrand Le Roy
Orchard project updates and news
Indent Example
Staff
Posts from Outercurve Staff