There are many great open source projects that have dedicated developers, users and admirers. But only a few have the possibility of becoming legitimate businesses. The trick is to figure out the market, the business context and the viability of sustained revenue.
I recently went through a successful fundraising effort to build a company around an open source project called Mule, which was developed by my co-founder, Ross Mason. We raised $4 million from Hummer Winblad and Morgenthaler earlier this month.
The takeaways from our experience moving from open source project to open source business may serve as guideposts for other second-generation open source startups.
The origin of Mule
Ross Mason, MuleSource CTO, started the Mule open source project in 2003 after spending several years doing integration “donkey work” at a variety of investment banks in London. The product was designed around the concept of the Enterprise Service Bus (ESB) which is a design that allows simplified connections across disparate systems.
The ESB concept is still core to Mule today, but the product has grown to become a full-scale platform for integrating systems of all types. Over the course of three years, Ross led the development and managed the project. He also took on professional services work to support users worldwide.
It was at this point that we started to contemplate building a company. We asked ourselves several key questions:
- Was there a large enough market to generate sustainable support and services revenue?
- How did the product compare to proprietary alternatives?
- Could we build an organization to continue the development and support customers?
- Could we raise money to do all of the above?
Our research led us to the conclusion that MuleSource could positively answer all of these questions. And in the process, we became far more educated about our market than it seemed anyone ever should be. Essentially, the goal was to prove the hypothesis that this was a good business — or at least a good bet.
Launching an open source business
The venture funding process took approximately two months. And though the investment is fantastic, the most important thing we gained from fundraising was a better knowledge of our product, our market and our competition.
And as we were seeking funding, we knew that however laborious it was going to be to get the funding, we knew that the real work—running the business—was going to be far more intense.
Here is a short list of tips to consider when funding and building an open source business:
1. Irrational exuberance is over-rated
Contrary to popular Silicon Valley myth, very few people walk into their first venture capital meetings and walk out with term sheets. If you are fortunate enough to have that experience, then I suggest you do yourself a favor and take some more meetings.
An over eager VC means one of two things: you really are sitting on a goldmine and your valuation should be even higher; or, the investor is merely chasing a deal and not looking to build a real business.
2. Get your IP in order
If you are even slightly familiar with open source, you likely have some knowledge of the confusion associated with the legal aspects of code ownership, indemnification and open source licensing. From the business (and the investor) perspective, any open source company seeking backing has to be as clean as possible with its code ownership. This means knowing exactly what is in the product it distributes and who wrote it.
Many commercial open source applications rely on other open source components within their own products. Every one of these components has a license associated with it, and not all of them are compliant with each other, or the license that the open source ultimately wishes to distribute its software under.
As a startup, it’s great to have a thriving community with many contributors to your project, but it’s also in your best interest to ask for rights or perpetual licensing to the code for any donations you receive. This is not designed to short the developer but to ensure that the codebase remains legally viable.
The intellectual property aspect is also very important in relation to an acquisition. No one wants to be negotiating terms of a buyout only to find that the code they have based their whole company on is in violation of licensing terms.
3. Leverage the community
After MuleSource received its venture backing, we were very happy. Then we realized that the funding was actually the easy part. Now we had to build a company. In our case this was comprised of two main tasks: hiring and converting users to customers.
One thing working in our favor related to both hiring and converting users is that the Mule project has been around for a few years. This meant that there was a large community to tap for staff, and a large pool of users who might be interested in our service offerings. This is an important point to contemplate when considering the leap from project to business: What is the addressable market, and is it possible to build a business to support it?
Market data is fairly easy to find. Analyst firms such as Gartner and IDC frequently publish data that provide a base for your research. In our case we looked at the broadest market opportunity for our product over the next five years. We were able to determine that the aggregate market was $8.5 billion. Based on comparisons to other software markets this is quite large.
We also ran statistics on the size of our community and how active they were. In our case we had more than 1000 active developers and had message forum activity consistently in the top ten groups of associated technology components.
4. Keep keeping costs down
While open source companies typically rely on low-cost marketing tactics, these methods require a great deal more forethought and commitment. In fact, marketing is the real battleground, but not in the obvious sense; being that open source typically sells for much less than proprietary software, open source vendors have no choice but to spend less money on customer acquisition.
Cost control can be accomplished through a variety of means, including community development and communications programs, but the underlying mission is to keep your cost of goods sold (COGS) very low. If you don’t control your COGS then the whole open source model goes up in smoke.
5. Find the right price
Pricing remains one of the great mysteries of any business. Open source companies tend to look at the cost of their nearest competitor and price their offering at some percentage discount.
While this pricing method is helpful for marketing purposes, it doesn’t build an effective business model. Pricing must be thought through and tested amongst friendly parties who will give honest feedback on the value of the service or software.
6. Get help with the never-ending legal stuff
One aspect that continues to recur is the need for sound legal advice and contracts. Open source is still very unknown to many large and small companies. The best thing an open source business can do is find knowledgeable and trustworthy legal help.
The odds are both corporate guidance and contract development help will be needed. We have found that sometimes both can be done in one firm (or person) and sometimes it’s best to go to the appropriate specialist.
7. Building the board
Board members (which in the early stages typically come from your investors) are key in building your business. In our case we were looking for Directors who had been entrepreneurs and understand the process of building a business from the ground up.
The second generation of open source
I would consider MuleSource to be part of the second generation of open source companies. First, because we compete on product differentiation — competing on features and functionality, not just cost.
And second, because we have been able to watch what other open source companies have gone through over the last few years and learn from their experiences.
The open source companies that come after us will have the advantage of watching further evolution in the market place. And while it’s hard to say what comes next, it’s not that hard to imagine a time when all software comes with source code and allows users to modify and manage their own destiny — not be beholden to monolithic, proprietary vendors.