Tag Archives: GitHub

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.


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.


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.

The CEO as the cultural epicenter
As a former CEO and senior executive, there was a time when I did not quite understand the profound impact a CEO has on the culture of a company, even though I always knew culture was important.

The organization reflects the behavior and characteristics of the CEO and that establishes the culture. Foster an environment of open communication and the organization inherits a culture of open communication. Operationally detailed? The organization becomes operationally detailed. Political? The organization becomes political. Curse a lot? The organization curses. Angry? The organization gets angry. Have a big office? Everyone wants a big office. It doesn’t matter what’s written on a coffee mug or on a “culture” slide, what you do as a CEO, day in and day out, and how you behave will define your company’s culture.

Despite the best intentions, companies often become culturally dysfunctional. This occurs when leadership has a perception about the culture that conflicts with reality, or leadership behaves differently than what might be written down. 

One of the most studied examples of cultural dysfunction occurred at Enron, the former energy-trading giant. The CEO (Ken Skilling) and several top executives were arrested for a pattern of deceit, dishonesty and illegal financial practices. They promoted a culture of dishonesty, self-dealing and self-enrichment that destroyed the company. Ironically, the Enron code of ethics outlined four key principles: communication, respect, integrity and excellence… So, yes, culture matters and the CEO defines it.

Cultural dysfunction is not limited to large companies. When I arrived at XenSource, which was a 50-person company, the culture was dysfunctional, despite the fact that the founding team believed the culture to be awesome and supportive of innovation and collaborative thinking. There were two telltale signs: 1. Employees painted a very different cultural view from the founders and 2. The responses were inconsistent with each other, indicating that the culture was a free-for-all with very little leadership. One clear example of the inconsistency resulted in the organization having two engineering efforts that competed with each other. Here was a company with a supposedly “collaborative, non-political” culture that had engineering teams pitted against each other to see who would win. The competitive activity turned out to be corrosive and undermined the intended culture of the company.

Stemming dysfunction
I often talk about CEO self-awareness as one of the key attributes of corporate success. In the case of XenSource, the leadership espoused and verbalized cultural “intent”, but practiced and allowed something very different in the company. The company almost failed due to a highly dysfunctional culture. Make sure what you believe is what is truly happening in the company. 

Stemming dysfunction requires leadership and taking some simple but important actions: proactively define cultural attributes important to the organization—write them down and let people know what they are, and “walk the talk”. You must practice and exemplify your culture, and have a mechanism to review culture deep within the organization. Ask the following questions:

  • Is the organization’s culture consistent with the defined attributes?
  • Where are the differences?
  • What are we doing right or wrong to keep a strong and consistent cultural backbone in the company?

The Cultural Paradox: I can’t change the culture because that’s not part of our culture
Culture is formed—whether intentionally or not—in the early days of a company’s life. Activities and behaviors are repeated and these become the elements that shape the culture of the company.  Examples of such early practices might be: 1) The founding team always interviews all new people applying to the company; or 2) a product-oriented focus in everything the company does. The accepted and repeated practices become the culture and define how the company operates.

However, what has worked in the early days might not be as effective as the company grows up. As a result, you might be forced to choose between two conflicting cultural attributes.

Take the attribute “the founding team must always interview new people”—a great cultural practice intended to ensure new employees are a perfect fit. Is there a point where growth is hampered because the company can’t interview fast enough and candidates go elsewhere? What part of the culture do you change? Limit growth or change your hiring practice? Changing either impacts culture.

One of the most difficult aspects for technical founders is hiring outside the comfort zone of the founding team. This is evident when hiring sales, marketing and finance people. A good example of this is how a technical founder might apply engineering hiring techniques to a sales organization, which my partner Ben Horowitz recently blogged about here. The fear here is that bringing on non-technical people will destroy the company culture. Do you put engineers in all the non-engineering functions and continue to only hire technical people, or do you augment the culture and integrate new and different organizations into the company? Here again, sticking to the past practice/culture of only hiring technical people might be counter to building a great finance or sales organization.

Steering change
Existing culture can get in the way of future growth and company leadership must steer the transition. Changes to practices and culture should be done by first asking why something is done a certain way and what’s the intended outcome. Preserving the intended outcome should trump the practice. 

Let’s go back to the example, “the founding team shall interview all new applicants”. The intended outcome is to make sure that all new employees are of the acceptable caliber and intelligence, and understand the culture and origins of the organization. The problem is the system does not scale, particularly as candidates are hired around the world and at a pace that far outstrips the capacity for the founders to handle.

A change to the practice might be to empower key employee “ambassadors” who act as a proxy for the founding team. Alternatively, maybe just one of the founders meets all new candidates as opposed to all founders meeting all candidates. If part of the intended outcome is for a candidate to meet the founders and get a feel for the company, then have all new employees meet the founders at a lunch or dinner after they join the company. Developing a strong and scalable interview process and on-boarding/mentoring system will ensure that the intended culture is preserved while steering change from an operational perspective.

Managing culture
The concept of managing culture may seem a bit heavy-handed, particularly in tech companies that pride themselves on being free from overbearing rules and bureaucracy. However, not managing culture can be likened to not managing growth, or not managing expenses, or simply not managing and certainly not leading…


  1. Self-awareness. If you can’t accept self-awareness, you should not be CEO.
  2. What are you trying to accomplish? What’s the end game?
  3. Translate energy to the areas you are least comfortable understanding.

A strong culture is the backbone of any organization and the CEO is the standard bearer and the agent of change. In a recent Fast Company article, GitHub Co-founder and CEO Tom Preston-Werner shares his perspective on how he and his cofounders have thought about and managed the company culture from 10 people to 160. Regardless of age, background and experience, culture is something that evolves with the CEO and the process of creating a great culture requires leadership to routinely and consistently assess and exemplify the core values of the organization.