Archive

Product Development

Open source software powers the world’s technology. In the past decade, there has been an inexorable adoption of open source in most aspects of computing. Without open source, Facebook, Google, Amazon, and nearly every other modern technology company would not exist. Thanks to an amazing community of innovative, top-notch programmers, open source has become the foundation of cloud computing, software-as-a-service, next generation databases, mobile devices, the consumer internet, and even Bitcoin.

Yet, with all that momentum, there’s a vocal segment of software insiders that preach the looming failure of open source software against competition from proprietary software vendors. The future for open source, they argue, is as also-ran software, relegated to niche projects. It’s proprietary software vendors that will handle the really critical stuff.

So which is it? The success of technology companies using open source, and the apparent failure of open source is a head scratcher. Yet both are true, but not for the reasons some would have you believe. The success or failure of open source is not the software itself  – it’s definitely up to the tasks required of it – but in the underlying business model.

It started (and ended) with Red Hat

Red Hat, the Linux operating system company, pioneered the original open source business model. Red Hat gives away open source software for free but charges a support fee to those customers who rely on Red Hat for maintenance, support, and installation. As revenue began to roll into Red Hat, a race began among startups to develop an open source offering for each proprietary software counterpart and then wrap a Red Hat-style service offering around it. Companies such as MySQL, XenSource, SugarCRM, Ubuntu, and Revolution Analytics were born in this rush toward open source.

Red Hat is a fantastic company, and a pioneer in successfully commercializing open source. However, beyond Red Hat the effort has largely been a failure from a business standpoint. Consider that the “support” model has been around for 20 years, and other than Red Hat there are no other public standalone companies that have been able to offer an alternative to their proprietary counterpart. When you compare the market cap and revenue of Red Hat to Microsoft or Amazon or Oracle, even Red Hat starts to look like a lukewarm success. The overwhelming success of Linux is disproportionate to the performance of Red Hat. Great for open source, a little disappointing for Red Hat.

peterlevine1

There are many reasons why the Red Hat model doesn’t work, but its key point of failure is that the business model simply does not enable adequate funding of ongoing investments. The consequence of the model is minimal product differentiation resulting in limited pricing power and corresponding lack of revenue. As shown below, the open source support model generates a fraction of the revenue of other licensing models. For that reason it’s nearly impossible to properly invest in product development, support, or sales the way that companies like Microsoft or Oracle or Amazon can.

peterlevine2

And if that weren’t tough enough, pure open source companies have other factors stacked against them. Product roadmaps and requirements are often left to a distributed group of developers. Unless a company employs a majority of the inventors of a particular open source project, there is a high likelihood that the project never gains traction or another company decides to create a fork of the technology. The complexities of defining and controlling a stable roadmap versus innovating quickly enough to prevent a fork is vicious and complex for small organizations.

To make matters worse, the more successful an open source project, the more large companies want to co-opt the code base. I experienced this first-hand as CEO at XenSource, where every major software and hardware company leveraged our code base with nearly zero revenue coming back to us. We had made the product so easy to use and so important, that we had out-engineered ourselves. Great for the open source community, not so great for us.

If you think this is past history and not relevant, I see a similar situation occurring today with OpenStack, and it is likely happening with many other successful open source projects. As an open source company, you are not only competing with proprietary incumbents, you are competing with the open source community itself. It’s a veritable shit-show.

If you’re lucky and have a super-successful open source project, maybe a large company will pay you a few bucks for one-time support, or ask you to build a “shim” or a “foo” or a “bar.” If you are really lucky (as we were with XenSource), you might be acquired as a “strategic” acquisition. But, most open source companies don’t have that kind of luck, and the chances of going public and creating a large standalone company are pretty darn slim.

Even with all that stacked against them, we still see entrepreneurs pitching their companies as the “next Red Hat of…” Here is the problem with that vision: there has never been a “next Red Hat of…” It’s not to say we won’t see another Red Hat, but the odds are long and the path is littered with the corpses of companies that have tried the support model.

But there is a model that works.

Selling open source as a service

The winning open source model turns open source 1.0 on its head. By packaging open source into a service (as in cloud computing or software-as-a-service) or as a software or hardware appliance, companies can monetize open source with a far more robust and flexible model, encouraging innovation, and on-going investment in software development.

Many of today’s most successful new companies rely on an ecosystem of standardized open source components that are generally re-used and updated by the industry at-large. Companies who use these open source building blocks are more than happy to contribute to their ongoing success. These open source building blocks are the foundation of all modern cloud and SaaS offerings, and they are being monetized beautifully in many cases.

Depending on the company and the product, an organization may develop more open source software specific to their business or build some amount of proprietary software to complete the product offering. Amazon, Facebook, GitHub and scores of others mix open source components with their own proprietary code, and then sell the combination as a service.

This recipe – combining open source with a service or appliance model – is producing staggering results across the software landscape. Cloud and SaaS adoption is accelerating at an order of magnitude faster than on-premise deployments, and open source has been the enabler of this transformation.

Beyond SaaS, I would expect there to be future models for Open Source monetization, which is great for the industry.

So what are you waiting for?

Build a big business on top of and around a successful platform by adding something of your own that is both substantial and differentiated. Take, for example, our national road and highway system. If you view it as the transportation platform, you start to see the host of highly differentiated businesses that have been built on top of it, ranging from FedEx to Tesla. The ridesharing service Lyft is building its business on top of that same transportation platform, as well as Amazon’s AWS platform.

If you extend that platform worldview, Red Hat’s support model amounts to selling a slightly better version of the road – in this case, the Linux operating system – which is already good enough for most people.

Sure, when you first launch a business built using open source components, it’s important to grow the size of the platform and cater to your early adopters to drive initial success. So you might start off looking a little like Red Hat. But if all goes well, you’ll start to more resemble Facebook, GitHub, Amazon or Cumulus Networks as you layer in your own special something on top of the platform and deliver it as a service, or package it as an appliance. Becoming the next Red Hat is an admirable goal, but when you look at the trends today, maybe even Red Hat should think about becoming the next Amazon.

SpiderNet has been planning to release version 1.0 of its product in Q2 of this year. However, after the new VP of Engineering looks into the schedule and deliverables, he informs you that the product will be delayed, possibly by six to nine months, due to stability and feature completeness.

In your discussion with the team, you determine that there are two options: release on time with reduced features or delay by six to nine months with the full 1.0 feature set. The company co-founder/CTO is adamant that eliminating any of the v1.0 features will result in an uncompetitive product and releasing “a piece of crap” will undermine the credibility of the company.

Product management advocates releasing something in Q2 provided that the next release follows within nine months. Prior to now, everyone agreed that product management is responsible for release decisions. Your CTO team wants to make an exception to the rule, claiming that this is a strategic decision and can’t possibly be left solely to product management.

According to product management, while the first release will fall short of what was promised, the three most important customer-facing features are able to be released on time. In his view, the minimum viable feature set has been met and getting something out sooner is the best approach.

SpiderNet still has about a year of cash in the bank, so could theoretically weather the delay, but getting any sort of customer traction before requiring additional funding will be very difficult. Do you side with your co-founder/CTO and wait six months or do you press the company to release a minimally viable product by the end of Q2?

What Now?

There’s not a technical team on the planet that does not wish to build the greatest product known to humankind—a product that has more features than all the incumbents, will truly revolutionize the market, and be released sooner rather than later to catch the impending market demand for the technology. Rarely do such wishes come true.

The reality is that building and releasing a market-ready software product takes time and iteration to get right. Whether SaaS or on-premise, the learning curve to get the feature set correct, understand the ideal customer, and teach the company how to launch a product takes time and it is extremely rare for a company to go from no product to ideal product in one grand motion.

While it is easy to advise a stepwise approach, the reality is much more difficult. Engineering teams want to release great and complete products, you don’t want the company to be embarrassed with a half-assed attempt, and the company vision often dictates a much more robust offering than you have the time or money to produce.

The Minimally Viable Product

I am a huge advocate of the MVP. Having barely lived through the alternative—the uber, world-eating product that never releases—creating a viable yet less grandiose product of value along the path to something larger is a far more prudent approach. Releasing an MVP puts a product in the user’s hands for feedback, teaches the company how to release a product (which goes far beyond simply finishing the bits), and starts to create a value proposition within a targeted market segment. Two cases in point: Dropbox’s approach to product development and Zynga’s release of FarmVille. To the extent a company tries to build the grand vision upfront, the result is often a broken Swiss army knife of features that never gets traction because the product doesn’t work completely and can’t compete effectively.

That said, the MVP only works if the following conditions prove true:

  1. The product actually contains the top three to five compelling features required
  2. The product is bomb-proof and has the highest attention to quality.

Fewer features yet higher quality usually wins. Low quality loses in all cases, regardless of the feature set.

SpiderNet

In the SpiderNet case, I would thus advocate taking the MVP approach despite possibly upsetting the CTO. For all the reasons mentioned above, getting something out the door is important and critical for the company’s success: important for feedback, important for the company, and important for SpiderNet to raise another round of funding. Furthermore, the six- to nine-month delay might turn into a year or longer given the unknowns. That said, the CTO is absolutely correct in that the company must not release an embarrassing “piece of crap”. Therefore, I’d want to make sure that the three to five features are really the ones required by the customer and then, as a team, pick a release date that the company strives to meet. Full steam ahead.