Open Adoption Software Interviews: Heptio
Kubernetes, a container-orchestration platform first released by Google in 2014 and since contributed the Cloud-Native Computing Foundation, is shaping up to be one of the most popular open source projects of all time. Recently, two of the project’s creators, Joe Beda and Craig McLuckie, launched their own Kubernetes-based startup call Heptio.
In this interview, McLuckie (Heptio CEO) and Beda (Heptio CTO), discuss the how the company plans to make money from Kubernetes while still respecting the community they helped create. They also share some of their secrets to building a successful open source project, and explain why the co-emergence of Open Adoption Software (OAS) models and cloud-native technologies has created a groundswell of opportunities for enterprise IT startups.
— -
JAKE FLOMENBERG: Tell us about Heptio and where the company is in its OAS evolution — Project, Product or Profit.
JOE BEDA: While Kubernetes, the foundation around which we’re building Heptio, has been around for a while, Heptio is a relatively new company.
The history is that while Craig and I were at Google, we — along with Brendan Burns — started Kubernetes as a way to bring a lot of the ideas that were proven at Google outside of Google. We chose to advocate and get it released as an open source project as way to build a community that would reach beyond what Google was doing currently, and essentially become a pipeline for Google.
It was clear there were opportunities for Kubernetes outside of Google, so Craig and I started Heptio with the goal of taking that to enterprise, essentially starting to transition it into a product. I would say we’re in the transition between the Project and the Product phase. We still have to establish Heptio with respect to the community.
It’s more than just the Craig and Joe show, we have to make sure that our company can play a role in the community. As we move forward from there, we’re going to be working to figure out ways to build a product around Kubernetes that we can then go ahead and sell, and turn into a business.
What role does community play in the development of, the adoption of, and ongoing use of your software? How dominant do you think Google will continue to be in driving that forward, versus people that work at Heptio or elsewhere?
CRAIG McLUCKIE: Kubernetes was initially a Google project, when Joe, Brendan and I worked for Google, but we worked extremely hard to make sure that it wasn’t just a Google project. Right from the very earliest days, we made sure that the community was welcoming of external contributors, and we made sure that there were maintainers from a broad array of places.
For instance, Red Hat was a very early participant and contributor to Kubernetes and remains quite active in the community. As a result, the project was really a fusion of contributions from a number of different like-minded engineers who shared this common objective and were working together to build the technology.
While Kubernetes is certainly something that has a very significant portion of contributions from Google, it’s worth recognizing that Google at this point has not written the majority of the code. It’s actually getting to a point where the broader community has contributed about half of the code base of Kubernetes.
In terms of the future of the project, it quickly became clear that Kubernetes was a hit in the open source community, and that as a commercial product Google Container Engine was really strong, but there were significant gaps in the ecosystem that were holding back the project. Most of the community is really looking for a sort of unfettered version of Kubernetes, the technology. They really want it to work on any cloud, they really want to work on any operating system, they really want to work in any environment.
As I think to the future, we expect to put a lot of resources into the Kubernetes community. Our goal is not to try to look at that community as something we have to get our arms around and pull into Heptio. What we’d rather do is bring additional resources to the community.
We don’t believe we can take out more than we put in, and so our goal is to grow the size of and help the community. We want find people who haven’t necessarily been working with Kubernetes, employ them and bring them to the project, and build it out from there.
I think Google will continue to contribute. They have been excellent stewards of the project. I think Red Hat will continue to contribute, they have been fantastic in this community. Our goal is to bring as much resources there as we can to help make Kubernetes accessible to a new cast of users, to solve new problems that the community isn’t tackling right now, and ultimately to increase the health and size of the community.
Why did you create a foundation for Kubernetes, rather than just release it under an Apache license, for example?
McLUCKIE: There were a lot of reasons the community decided to create the Cloud Native Computing Foundation, within the Linux Foundation. The first was that a lot of organizations were concerned about Google holding the intellectual property and trademark for Kubernetes. We had seen other open source projects where the trademark and IP hadn’t been donated to a general foundation, and it definitely created this unease among folks that were looking to bet on the technology.
At the end of the day, open source is one thing, but a lot of people associate the product with the trademark. It was very important to us that we make it clear from the get-go that Kubernetes was bigger than Google, and to try to hold that trademark back as something that Google controlled didn’t make sense.
The second part of it was a little bit more nuanced. The problem was that while I wanted to promote Kubernetes directly, and saw that as being highly beneficial to Google Container Engine, it didn’t entirely make sense for Google from a business perspective. It was difficult to have a conversation around why would we put marketing resources into an open source project that runs on Amazon or Azure, or anywhere else.
So we took Kubernetes to the Linux Foundation, creating a foundation around it that would be funded at the level of something like the Cloud Foundry Foundation or the OpenStack Foundation. Having all of those resources helps to promote the technology, to make sure that the technology runs well in a variety of other environments, and to create conferences that are vendor-neutral. It was a necessary way to promote the health of the project.
How does Heptio think about making money in OAS, including which features to include in the community and enterprise versions of the product?
BEDA: I think this is one of the trickiest things to get right with this model, but I can outline some of the broad strokes about how we’ve been thinking about it. The first thing is that any business model built on consulting and services, around making up for the fact that the open source project is lacking, is probably due to fail. You create this perverse incentive that as the project gets better and better, it essentially works against your larger business interests.
We didn’t want to put ourselves into a situation where Kubernetes getting more awesome means that we have less of a business. We thought that was anti-community and heading in the wrong direction.
The next thing is that whatever is happening in the open source world, it has to have some level of independent utility. Specifically, you have to be able to take the stuff that’s in the open and use it, and use it in production, and be happy with the use that you have out of it. Otherwise, the project’s really not independent.
Based on those two things, the way we’ve been talking about this is “How can we grow the Kubernetes user base by 10x?” What that means is bringing more perspectives and more users into the fold, and filling in some of the gaps that are not apparent from the current users. This means that the current open source product is appropriate for the folks that are using it right now, but maybe there are things around the edges that are necessary to bring in whole new classes of users, and we can fill in those gaps and perhaps find ways to monetize them.
For example, the needs of a startup in San Francisco are going to be very different from the needs of a financial institution somewhere in the middle of the country. They’re going to have a lot more legacy, they’re going to have a lot more process, and they’re going to have a lot more unique needs that I think aren’t represented from the core of folks that are working on the Kubernetes project right now.
We think that there is going to be a lot more opportunity to integrate Kubernetes into both organizations and the processes — both technical and people — of large companies. This is the type of thing that generally will not make its way into open source. Even if a large enterprise were to actually build out these integrations and tools and open source them, they’re so custom-fit to what the company is doing that they’re very difficult to apply to other situations.
McLUCKIE: But to be clear: We certainly don’t want to preclude ourselves from participating in support and professional services and training — a lot of the other things that are traditionally associated with Open Adoption Software projects where we are right now.
I think it’s really important that we do that to help people start to adopt Kubernetes, and use it and get over the curve, but we can’t focus on that as the primary value that we’re delivering. We see this balancing act, where over time the amount of value that we can deliver through that declines because the project becomes better, but that’s what opens us up for the second phase.
Why do you believe there’s enough commercial opportunity to build a big business around Kubernetes, and why is OAS the right way to go about doing that?
McLUCKIE: I think we’re at a really interesting inflection point. We’re starting to see an amazing amount of disruption happening in the market, as enterprises are starting to adopt open source software wholesale, and all of these cloud-native technologies are taking shape. There’s an unparalleled amount of opportunity to help enterprises make that transition.
Red Hat certainly was very successful in some regards, but I didn’t see its core model translating all that well into the cloud environment. At the same time, a lot of cloud consumers were really concerned with this idea of vendor or cloud-provider lock-in, and they saw open source as being one of the most leverageable ways to avoid lock-in.
I also looked what was being done in the big data space around open source, and it seemed obvious to me that you can’t actually do an infrastructure startup that isn’t grounded in open source today. If you’re not open source, you’re literally precluded from a lot of purchasing decisions.
I don’t think we’ve seen the final shape of open source companies and how they will operate in the cloud space. I’d love to be a part of that. There’s a tremendous, spectacular amount of opportunity as the enterprise is starting to really think about its relationship with these open source projects and companies.
Are there any points you want to help educate the world on, on why OAS is a viable software development methodology, or any misconceptions you want to clear up?
McLUCKIE: There are a couple of things that are really important. The first thing to realize is that the power of OAS is in the O, the openness as associated with these technologies. This is not something that any one company can or should control, and artificially trying to control an open source project defeats the project defeats the purpose. Even for organizations that have been successful in the Project phase, if their productization strategy involves constructing walls around the community, or exerting artificial control on the community, it is going to be very difficult to progress.
Ultimately, the commercial organization will taint and poison the health of that underlying community. You have to live open, you have to be comfortable being open, and you have to accept that a healthy community will have multiple providers and vendors being successful.
Also, a as a vendor, you can’t take out more than you put in. You can’t strip-mine an open source project and try to think about it as a value-extraction exercise. It’s really important to recognize that you can absolutely deliver value by creating high levels of specialization, for example by bringing on board experts that big enterprises could neither afford nor find. I think most enterprises understand that there’s utility in working with someone who has access to people like that.
A lot of enterprises do understand the unique value that this affords. Some of them do want to see providers like us succeed; they are invested in our success and are willing to pay reasonable rates to see us succeed. But the minute we act against the best interests of that open community, that signals the impending demise of the organization, and in some ways creates a lot of problems for the project itself.
