Open Source and Product Management

[column width=”1/1″ last=”true” title=”” title_type=”single” animation=”none” implicit=”true”]

I was surprised to find out that open-source software goes back all the way to the 1950s and 1960s. I think most people think of Linux when they think of open-source. Linus Torvalds made a big splash when he released Linux in 1991, and in my opinion marks the modern day open-source movement.

I was involved in a very public and successful open-source project with IBM when they donated the Eclipse source code to the community as a co-founder with OTI, Rational, QNX, Merant, Borland, Red Hat, Suse, WebGain and TogetherSoft. I learned a great deal about the strategy and business models associated with open-source during the three years I was with team.

As a product manager contemplating the role of open source, you have a lot to think about in terms of product strategy, market share, what intellectual property (IP) you are willing to share and what you want to keep as trade secret or value add, and ultimately what business model you want to create.

There are three ways to participate in open source:

• User: Your company adopts open source software as a component or platform for use within your company or packaged for resale as part of a larger package.
• Participant: Your company actively works on the open source project in a paid capacity, or in a benevolent capacity for bug fixes or to connect your value-add software. Your company may or may not be a User.
• Originator: Your company is a founder or co-founder of the open source project and helps steer the project to success, recruits others to participate, actively markets the project and builds a brand around the project.

I’m going to focus this article on Originator, as I know some of you reading this are contemplating a business around an open-source project.

Here’s the short version of what you need to know. If you desire more info, read further.

• Define a strategy and a business model. This can be a product requirements document that defines what YOU need to get out of this community for your donation. This can include other benefits such as recruiting, brand recognition, etc.
• Define the processes to support your strategy. How will you release code? How will you deem code ready for a production environment? How will code be delivered into a commercial environment? How supports it? How will you operate the business in tandem with the community?
• Create a marketing plan. You’ve heard the one about the tree that falls in the forest and no-one is around to hear it? Without getting the word out, you are leaving money on the table. Lost revenues. Missed opportunities. Get out there.
• Make absolutely sure you wrap the project in the most ideal license for everyone involved.

Here’s some extra words around the above.

The first thing you need to do is plan a strategy with desired outcomes. You might get lucky by dumping your code out on GitHub and waiting for people to pick it up and run with it, but that’s not likely. Without a plan, two things could happen. 1) No one really notices and the time and effort you put in goes to waste. 2) Someone else steps in, does some heavy lifting, and before you know it, it’s no longer your project. Once the project is out there, you need to own the community and nurture it in the right direction. You can’t “control” it, or people won’t participate for very long. But you need to guide it and stay very active and visible for it to meet your strategy goals.

What are some strategy goals? Let’s say you need to create a pervasive platform that can grow and become stronger by community participation. Your business model is to provide support and services by adopting the appropriate code bases that have been proven and tested. This is what Red Hat does with Linux. This is what IBM did with WebSphere (Apache). There is an alternate business model, which is to give the IP away for free without open sourcing. CloudRail is a universal API service that is attempting to grow a pervasive platform and charge for support. Time will tell if they are successful.

Another strategy that builds upon the pervasive platform thought is to build value-add layers on top of the platform as paid product offerings. IBM does this with their software stacks. They give away the base layer, and every year they give away more of the base layer, while building more value-add layers on top. The free layers are part of various Apache projects in the case of WebSphere Application Server. And the value-add product offerings can run in the 5 and 6 figures.

Why use this strategy? Customers can adopt the technology inexpensively as proof-of-concept projects until they prove a viable model, then they can move onto a paid and supported stack for production. Open-source tends to attract many users outside of the paid user-base, which makes it easier to find talent to work on projects (skills) and more people are familiar with the products, which helps support sales through marketing gravity.

Watch out for licensing. If you are creating or participating in an OS project for commercial purposes, you need to make sure the license agreement allows you and others to create profitable offerings on the source without divulging your IP to the community. Some open source licensing requires that any code built upon the code base be donated back to the open source project free of charge. This may be desirable for you, or it may not, but be very aware of the licensing architecture before committing resources. For more info, go here.

Other factors to consider:

• Quality – The code base will be higher quality due to the vibrant community. However, if participation is low, so will quality.
• Strategy indicators – As the community grows, so will the functionality of the project. Watch what is brought to the community for potential signs of future commercial growth.
• Government use – The government agencies are increasingly, if not demanding, access to the source code for the software they run. This doesn’t mean they want to do everything themselves for free. They will pay for support and production level services. They want the ability to find vulnerabilities and weak points for attack. This ultimately results in more secure code as weaknesses are found.

I hope you found this useful! Let me know how I can help you with your open source efforts!

© Mark Travis – All Rights Reserved      http://www.travis-company.com

[/column]