One occasionally runs into a company trying to build an open source project out of an existing product. This is a nuanced problem. This is not a company that owns a project published under an open source license trying to also ship a product of the same name (e.g. Docker, MySQL), but the situation shares many of the same problems. Neither is this a company building products out of open source projects to which they contribute but don’t control (e.g. Red Hat’s RHEL). This is a company with an existing product revenue stream trying to create a project out of the product.

To one view, this is the opposite problem to the normal evolution of an ecosystem around a successful well run open source project. An early project starts with working code and a small set of committers, and there are no corporate players yet. If the project is well built, usage grows. If developers can use and modify it to their own needs, then contributions can flow back. This assumes the project is well organized and disciplined and executes well. There then comes a point in the project’s growth and evolution where other companies want to get involved. The project has proven itself robust enough to grow into a new space. Corporate use means products and services, customer expectations, and dedicated resources invested in the project in return. A foundation can solve the IP (intellectual property) risk mitigation issues companies want solved, assuming of course the project committers want to grow in this way.

Linux is the poster child for this sort of growth, but Apache projects have shown similar growth (e.g. httpd, Hadoop), as has the Perl community, Eclipse, and Drupal.

Value of creating an open source project

Taking a product into the open source world needs a different mindset, not least because it is a much more deliberate and less organic practice. Creating an open source project in general creates value around the software itself. This is beyond the value to participants honing hard and soft skills and learning new tools and ways to think about problems.

• It enables innovation around the software as experience grows and new ideas can be contributed.
• A culture of review has been shown to find more bugs than formal testing, if the community is enabled in this direction, and so quality can be improved.
• It allows the software to evolve into other spaces more rapidly without the bottleneck of central planning or centralized investment (i.e. a company making the hard choices about which markets to pursue for growth).
• The software is hardened through use in new environments.
• It creates expertise and experience with the software with people that have the time to learn, and may not have been in a position to buy a solution, and so expands the base of experienced people in the project ecosystem at large.
• People learn how particular software works.

As a company, working to bring value to customers, these are all positive values for your software in return from a community. There’s a nuanced difference here between broadcast developer networks (e.g. MSDN) and the sort of community around an open source project with insight into the code and an ability to contribute. The return for the company is deep community engagement. (If you want to be cynical, it’s inertia as community participants aren’t exploring other vendors’s experiences if they’re spending time in your community.)

Keep products and projects separated

I regularly point out that one needs to keep open source projects and products clearly separate in one’s thinking (if you’re in product management), and to not confuse communities and customers (if you’re in marketing). Let’s try a couple of different ways of trying to illustrate this.

When a software product is new, the team is still on the adrenalin rush of shipping, and the product is proving itself with early customers, folks often mistake the software for the solution itself. It’s hard not to. There was so much effort invested in the delivery. But to quote Theodore Levitt, “People don’t want quarter-inch drills. They want quarter-inch holes.” In general, the tool enables the solution. It isn’t itself the solution.

What’s also true is vendors innovate over time continuously, getting better and better at delivering the solution that customers want. Microsoft’s magic today isn’t based on the source code to the Windows operating system per se. It’s the ability to deliver the executable bundle at a scale few companies can match when you consider the cross-product testing that needs to be done across ten thousand OEMs/ODMs by ten thousand ISVs. Then warrant it, support it, maintain it, secure it, and do it all in a timely manner to the needs of the corporate enterprise. That is the value for which customers pay. Not the source code.

You can see this more clearly in successful companies that deliver products from open source components they don’t directly control or own:

• Red Hat delivers RHEL (Red Hat Enterprise Linux) as a binary, supported, warranted, maintained, secured product. In the early days, RHEL in the datacenter wasn’t about Linux, it was about an inexpensive supported UNIX-like product that ran on PC-class servers instead of Big Expensive UNIX Systems running on Big Expensive Iron. Red Hat knew what its value proposition was. Sun Microsystems is no more. Neither is DEC (Ultrix). AIX HP/UX aren’t really growing their installed base.
• HortonWorks and Cloudera rigorously focus on solving their customers big data problems with robust products and services. Their respective solutions happen to be built from software that is freely available in an Apache community.

This in no way means that there isn’t enormous value in the software, its source code, and its creation. But in many cases that’s the raw materials (complex as they are) for more successful product innovation solving customer problems for money. Open source software is lumber. In some cases, the early projects have all the organic structure of trees.

Turning a product into a project

This poses a set of really interesting questions for companies trying to take products in their existing portfolios and expose the underlying components in meaningful ways as open source. Sticking with the physical world lumber example: Imagine taking a house apart back to components. The lumber was cut and shaped into the house. It’s not just standardized lumber any more. And it gets worse with complex software suites that have grown by acquisition and integration where their architectures have been hidden and subverted to simplify customer experience and consistency of UI.

There are two questions that need to be answered if one is to take a product into a project:

• Should the product software be published? If the software really represents the entire value proposition to a customer, then it’s probably not a good idea to publish it. But if that’s the case, such a product will always be under threat of being overtaken by other similar pure software solutions and possibly by companies in much better positions to deliver that customer value.
• Can the product software be legally published? Many products contain third-party licensed software, and many such licenses from third-parties prevent re-licensing or publishing.

Assuming one still wants to turn product into open source project, there’s a set of activities that need to happen, and they build a set of steps that represent the entire process.

1. Publish the source under an OSI-approved license. (The minimal definition of open source.)
2. Publish the software build environment. This would allow other developers to actually build useful executables under certain circumstances.
3. Accept contributions. This is a proof-of-community test.
4. Build a genuine community. This is full community engagement.

(Click to enlarge)

There is work to be done to make software publishable:

• There needs to be consistent robust source management both for products out to projects and the branching inherent in both.
• There needs to be a critical review of the source for obvious “embarrassments” (including political checks).
• There needs to be investment in communications channels from the simplest (wiki) to the more robust (a full community site) depending upon how much community a company is committed to building.
• If the project can be built, then support staff needs crisp tools to determine Franken-products from customers and competitors alike, so they can correctly answer real product support needs.
• There needs to be easy tools to support contributions and clear policy on contribution ownership.

Some of the most important considerations have nothing to do with the software. A company needs crisp and clear messaging when it comes to products and projects. I’ve said before you can’t confuse customers with community, but this has historically been in the direction of the product marketing team thinking the community are customers to be encouraged into the pipeline, or corporate thinking along the lines of “they need to buy something since they’re getting it all for free.”

The first message to understand: NO PRICES NEED TO CHANGE. The product value hasn’t changed. You’ve enabled a project community. You haven’t removed the investment in product delivery. Customers need to understand this difference. And your sales team, marketing team, and product management need to all understand this reality. A customer is welcome to take the software project and build and run their own version. And support it. Warrant it (test it) on their hardware purchases. Maintain it (hopefully not as an extremely expensive fork of the project). Handle security vulnerabilities and patches. All of it. A vendor is under no obligation to support such internal IT projects. Even if they wanted to offer expensive time-and-materials support, that is a different business, it doesn’t scale well, and it needs thoughtful customer messaging.

The reverse situation is equally true in the messaging department. Contributors to the project whom are also customers of the product need to understand the relationship. A company’s product management in such a position needs to work diligently in project community to ensure everyone understands the commitment and the value flows. Get creative. For example, offer comp points on the annual product maintenance charges for contributions to projects. Some customers may always offer more and all customers ultimately gain overall value in the product, but the customers contributing the most see the most direct value and are likely the most valued committed customers from the start. Creating value together improves the relationship and its long term viable. Timing of fixes is important too. A fix contributed by a customer in project community that effects the product as well should have a clearly understood path back into the product whether a patch, a minor, or a major release.

This same care in messaging needs to be carried through into partnerships in community as well. Partners, like customers, are business relationships, contractually bound, and generally with some explicit exchange of value. Partners participating in community need to understand the flow of mutual innovation and shared value creation as much as customers. When you’re taking an existing product into a project community, this is possibly less of an issue. Just as customer pricing shouldn’t change, the terms of a partnership are still bound in the product itself. Nothing needs to change. When a partner begins to offer contributions through a project, have the discussion with how to think about changes in the product space. There could be enormous new opportunities to explore together. At its simplest, the product’s quality continues to improve.

Products and open source projects are not the same thing. Historically products are one aspect of a successful open source project ecosystem. Companies have also launched around tightly held open source licensed projects, some quite successfully. The reverse process of creating open source projects out of products can be made to work. Everyone just needs to understand the message.