In this episode of Dirk & Swap: Conversations on Open Source, we talk about Open Core. What is it? How different is it from Open Source or Closed Source software? What are the pros and cons of Open Core? Is it better than proprietary software as at least something is open there? How to do Open Core in the right way (if there is one)… We tackle many such complicated questions in this show. I hope you will enjoy it. We have also published a transcript of the recording so you can read it if you want to!  

Guest: Dirk Hohndel
Company: VMware
Show Name: Conversations On Open Source

Here is a rough and unedited transcript of the interview.

Swapnil Bhartiya: Welcome to another episode of Dirk & Swap Conversation on Open Source. And once again, as expected, we have with us Dirk Hohndel, VP and Chief Open Source Officer at VMware. And today’s topic is open core. According to you, what exactly is open core and how different it is from open source?

Dirk Hohndel: I think open core is something that is talked about a lot, and there’s a lot of confusion about how it works. And so let’s start at the basics. Open core uses an open source license. So companies that are based on open core have a core of their product that is based on an open source license. And we actually see a wide variety of open source licenses. We see things as simple as MIT, we see Apache V2, we see GPL based ones; those are typically then dual licensed. But we see a core of their product that is an open source based solution. And then they offer an extension of that that is not separate, that is simply the same thing released again under a proprietary license with more features.

So the difference between standard open source projects and open core projects is that in an open core project, there’s typically one strong owner, a single company behind the technology, and there is typically an implicit or explicit limit on the things that are available in the open source implementation, and there is this magical line where suddenly above that line, beyond deadline, features and capabilities are only available in the paid version of the software. And that’s why it’s called open core. The core of it is open source. But beyond that, you require a license.

Swapnil Bhartiya: What are the reasons why companies choose open core over vanilla open source?

Dirk Hohndel: So typically the idea is that open core makes it really simple to create a monetization framework around an open source project. So if you design your open core project or your open core product, what the open source component provides is useful for the amateur; for the occasional user. But if you want to use this in a commercial environment, in an enterprise environment, in a production environment, you end up needing to pay for the paid version. And there are different ways to do that. You can either have the license set up so that using it in a commercial environment is really cumbersome. So we see this with some of the GPL based open core systems. Simply look at Qt, for example. Using the open source version of Qt is really hard if you’re a proprietary software company, or if you are just a normal product company, because you’re required to have all the components under open source. So for an open source project, this works, but for a product that you’re trying to build, you really need to have a license in order to do a normal product development workflow.

In other instances, it is certain logging features, it is certain availability features, it is backup features. It’s all these things that are needed in an enterprise environment, in a production environment that suddenly aren’t available in the open source version, and are only available in the paid version. And this is what I said earlier. There is this magic line where the open source project then no longer accepts improvements. If you remember back, Docker, another typical open core company, Docker would refuse any contributions that would touch on their vision of how enterprise orchestration should work. And in a way by doing so, Docker seeded the market for something like Kubernetes to come into existence, because the orchestration couldn’t be done as part of the Docker project, because they refused such contributions. So the community created a separate project that would do this.

But the logic here is, if you create an open core based company, the monetization model is easy to explain to your VCs. It is very straightforward to explain to your customers what they’re paying for. And it is reasonably honest to your community. You say, “Hey, we are happy to work on this, to this line.” We’ve talked in previous conversations about the challenges that typically companies have, that have a single vendor open source model. And open core, by definition, is almost always… Actually, I can’t think of a counter example, it’s one company that controls the source code. There’s almost always a CLA often with a copyright assignment, but certainly a very asymmetrical CLA involved, and this one company sets the rules.

And we talked in other conversations about how that is problematic for the community, how this can be problematic even for a user of that project, because you’re putting yourself at the mercy of the decisions of this one company. And you are in a situation where, as a community, your ability to influence the direction of the project, is obviously very much hampered. But from a business model perspective, it’s easy, it’s clean, it’s obvious. It seems to make perfect sense.

Swapnil Bhartiya: So, of course the community, if there is one, does not have much say or influence on that project. How are these projects seen? If you look at the broader open source communities, there are projects which have community and there are projects where I’d see some friction. But what have you seen there?

Dirk Hohndel: The community has influence, as much influence as that company wants to give them. So we have seen open source projects that are part of an open core offering, where the community is healthy and works well, and the community has accepted the rule set that has been put in place. And the community is happy to play within that box they’ve been given, and to deal with the edges where it touches onto the proprietary offerings. And there is healthy, active development, and this is all going well.

Look at Cassandra for example. It’s a super successful Apache license project. And yes, there is an open core company that is building on top of that, and that controls the edges of this project. But the community itself is healthy. But now if we step back and say, the bigger question, how does the broader community view open core. I think, as always, the community is incredibly diverse. It goes from the very far end of the free software movement to the people who are perfectly happy with shared source. And they don’t really care what it is, as long as it solves the problem. So there is never a single answer, “Oh, the community does that.”

But typically around open core, you see a fair amount of skepticism by people who’ve been in and around open source for a long time. Because as I said earlier, there are boundaries; there are artificial limitations of what the community can do. And if the community thinks that they should be able to expand in this direction and add this feature, then very often they’re being shut down. And again, Docker being the perfect example here. There are different models in which you can monetize an open source project, and they give a lot more freedom to the community, to other players in the market, and still allow you to extend what you’re doing with that core open source project.

So I would say there is skepticism, there are questions. There are people who are positive, there are people who are very worried about what open core means for the broader infrastructure.

Swapnil Bhartiya: There are a lot of open source products. I’m tempted not to name companies, but let’s say Android, it’s a very good example; Chrome, example. These projects are created by a company. Rally is a good example, SUSE Linux is a good example. These are open source projects. They are not an open core project from their definition, but a company dictates that. But then there is an open source version also where communities have full say. Now, you can also detect how federal community is being governed or how open source community is different. But this is the beauty, that is there is no one set of rules. Different communities, they come up with their own models and they manage and govern their projects. And if it works for them, it works for them.

Dirk Hohndel: I think you’ve made a very important point that I kind of glossed over earlier when I described the broad set of communities I think about. Because there’s a massive difference between what is the user community of an open source project, which often, if the project is part of a software stack, there is still a community of developers, but they’re developing somewhere else in the stack. And so to them, this is almost a black box, or this is a component that they use. And then there is a developer community off the project itself. And one of the things that I believe, is really the difference here, is that in an open core project, very often that community that develops the project itself is massively dominated by this one company. And in that community, if someone from the outside comes in and has the desire to change something fairly fundamental, to work for them, for their company, for their product, for their project, there’s often a lot more resistance.

And so when you compare this to the distribution model, that’s kind of different. Because the way the distributions work, is that they take a number of different projects, they make them work together, they do the QA, the release management, the pairing of versions that are compatible with each other. And so the deliverable of a distribution is typically not so much development on the individual projects, but it’s that assembly work.

But if you look at a lot of diverse open source projects, let’s take Kubernetes for an example, there are tons of different companies who all monetize this, who all build products and services around this. And they all work together in this one or this family of open source projects. And they do so collaboratively and on a level playing field. And they’re trying to bring the technology further, make it sustainable, make it enterprise ready. And there is no hard boundary, “Oh, you can’t cross this line.” Versus in most open core projects, that is not how they’re set up. You typically have control by a company usually enshrined in the CLA, but also very much enshrined in the interactions of developers. And to me, that really is that biggest difference.

If I have a project that I want to use as part of my product, part of my services, if I come in and I see, oh. But if I want to add something over here, the company that I’m potentially competing with, the company that controls this project, might say no, or might use this to create an unfair advantage for themselves to not create a level playing field. That would certainly affect my perception of the project, and that would affect my willingness to invest into this community. And as we so often do, we come back to earlier conversations around foundations versus single company controlled projects.

And a lot of the things we discussed back then about how you create something that’s sustainable, that it is safe and reasonable to bet your business on, that plays a role. But I don’t want to seem to imply that open core is a bad thing. If you are a user of a product, if you need a database, the fact that my SQL is, for all intents and purposes, an open core product, where you can only get certain enterprise features in the paid version from Oracle, and what can go into the open source project is limited. If what you’re getting from the open source project is what you need for your product, that’s fine. It’s not a problem to use it. If you’re happy to pay for the proprietary version, the commercial version, and the fact that the technology underlying all this is open source, isn’t really relevant to you, that’s perfect for you. So there are many instances in which open core is a perfectly fine and reasonable and valid approach.

It only becomes challenging when an open source project that is part of a large set of software stacks, suddenly becomes open core. So when we see those license changes that have been really common over the last couple of years, and we see more and more projects suddenly say, “Oh, we are no longer under this license, we’re now under that license. And if you want the old license or the rules of the old license, you got to give us some money,” that’s when it becomes complicated. Because suddenly, your assumptions about this project change. The assumptions that you have made of what is possible, how you can use it, how you can interact with it, how you can expand it, have changed.

And so I really like the honesty, being upfront about what you’re trying to do in the project. So a small startup that says, “We are creating this project. We are open core. Here are the lines we are drawing.” To me, that is perfectly fine. That’s perfectly healthy and reasonable, and I have no problem with that. What I worry about is companies that continue to retain ownership of a project, and seem to be pushing for a typical open source model, and they then change the rules on you. And suddenly you find yourself in an open core model, even though you didn’t want to be there. So that’s more complicated. But even if companies are upfront with this, even if you’re going in, know that something is open core.

The biggest challenge both the user and the developer was trying to build around this, is the question, where are these lines that I can’t cross? Where are these lines where the company will say, “No, that’s only in our enterprise product or in our commercial product.” And is there a likelihood that these lines will turn into a problem for me? And this is really why I like to talk about this idea of extensible open source. So you have an open source project at the foundation of what you’re doing. And the project is designed to have extensions, be it plugins, modules, other layers; API driven with a contract of how you can interact, that allow multiple entities to create additional features.

So let’s say there is an enterprise feature around availability, that needs support in the underlying project, and you have a set of APIs that allow that. So you can have an open source solution to this. You can have a solution from company A and from company B. And if this is done on a level playing field, it is most likely to accelerate innovation, to create healthy competition and to create the best possible outcome; versus in open core where a single company says, “No, this is the only way how this can work. We control it, and you don’t get to play with this. If you want this feature, you have to buy our product,” which, in my mind, always creates that risk of stifled innovation.

That’s why I really look into this idea of open extensibility; having an open source project that can freely be extended along API boundaries that make it easy to aggregate different implementation of additional features, versus that ownership model that is implied by open core.

Swapnil Bhartiya: With open core, even if the community has a certain limitation, what we have seen with most projects is a lot of contribution; a lot of innovation happens at the edge of those projects. Even if you pick the Linux Kernel or Kubernetes, not every member of that massive community is investing in the core of Kubernetes or Linux Kernel. They are doing a lot of innovation at the edge. Open core does allow that or not? Because in most cases, nobody’s monetizing for the core project. They are using that project and they are building their own solutions to help the community or the companies.

Dirk Hohndel: And this is actually one of these fascinating things where classifications are evil. Every classification opens the door to prejudice. Because open core is not just one thing. There are many open core projects that have a very narrow definition of what is considered off limits. So they have a certain direction where they say, “This thing over there, that’s what my product does. That’s what my company does. I won’t allow this in the open source version. But in all other ways, feel free to extend, to create solutions around, to innovate on the edges,” as you put it, “to create more value here for the project.”

And on the flip side, there are open core companies who seem to have a very absolute view of saying, “No expansion of the feature set is allowed. You can fix bugs. You can basically do our QA work for us, but anything that expands the space that this project covers is off limits. It’s something that only we, the company, can do.” And in a way, this is a sign of the confidence of the founders; how confident are they that they have picked the right business model that they know where they want to go, and how confident are they that they understand where the value proposition is that they want to provide to their customers.

And the more a company says, “Hands-off, this is mine,” the less it seems open-sourced to me. The more a company says, “I am certainly happy to see you expand what we’re doing here. It’s this direction, this angle, this feature set, this use case, this direction of extension that I claim is mine,” the healthier likely the community will be, and the more comfortable I would be with using that project. And as is so often the case, it’s one of those you know it when you see it. You start engaging with the community, you pay attention to the conversations.

You look at the ratio of single company versus third-party committers or contributors I should say: often committers are just the single company just as a matter of control here. But you look at what type of contributions are being accepted from the outside. You ask yourself, are these contributions all just bug fixes? Are they all within that box that already exists, or are people able to add new APIs, to add new interfaces, to add new features, to expand the scope of how the project can be used. And that really, to me, that line between open core could be a problem; open core could very quickly morph into a source available license. Yes you can look at the sources, but fundamentally you can’t do anything with them; versus is open core just a regular open source project where a certain monetization vector is exclusive to the founding company.

And while I try not to judge, I also say that my level of comfort certainly goes up the more I feel that extension of the project in and of itself is welcome, is encouraged, and I see track record of this having happened in the past.

Swapnil Bhartiya: You always have that. You are okay with open core as long as there is transparency, as long as it is very clear what you can and cannot do. The problem arises when the lines between open source and open core is targeting blur where companies do approach things in an open source manner, but then over time they change. So I think the point is that, yes of course open source encourages more contribution, it also helps you in moving and making changes or making modifications if you need.

I think the basic idea is trust and transparency, because if there is lack of transparency and you cannot trust the project, it doesn’t really matter whether it’s open source, open core or proprietary. And we had that discussion last time also, where that was a very good discussion about either you do open source or you don’t do open source. There is no middle ground there.

Dirk Hohndel: So I don’t think it’s really important what I like, because I don’t get to make up any rules and I am not the decision maker for other people. To me, it’s something I want to get people to think about what they do. I want to get more people to ask critical questions, and understand where do they put their bets. Because every time you decide to use an open source component, you’re basically placing a bet that this project will be around, will continue to stay relevant, will be maintained, there is a certain security, trust relationship and all that. And as you’re taking these bets, you should inform yourself and you should start figuring out where am I placing bets that likely are safe, and where am I placing bets that potentially are very risky. And that really is what I’m trying to explain here. Understand the risks of what you’re doing.

And lack of transparency, to me, is always a red flag, it’s always a warning signal. And I think we should do one of those conversations about this whole idea of suddenly a project changes its license. What does that mean to me? How do I respond to that? I’ve now built a software stack that uses this project, and things change. But that’s kind of different from open core, because most open core projects start out that way. They may not be upfront about it, but it’s typically in the thought model of the founders of that company that go out with it that says, “Oh, and then we’re doing this thing over there that allows us to create something proprietary, something commercial on top of it.”

So to me, the idea is understand what you’re dealing with, and understand the consequences of what you’re dealing with. If you are using an open source project in a way where you have a vision how your use will grow additional things that you’d want to see from that open source project that you maybe even want to contribute to it and say, “Oh, and then I want to integrate this into this thing over there,” make sure that this integration is actually welcome, and not something that the company behind the project would consider as you crossing the line.

Swapnil Bhartiya: Even if somebody is doing open core, what is the right way of doing open core? As we discussed earlier, there’s no right or wrong way. Open core is right for a lot of people, proprietary right for a lot of people. Because sometimes companies make mistakes not because they want to make mistakes, but sometimes, as you said, they’re a startup, they’re still learning.

Dirk Hohndel: The question of how do you open core write, is an interesting one. Because I kind of alluded to this earlier, being very upfront about this and defining very clearly. And honestly, as narrowly as possible, these are the areas that I want to build my product, my services, my monetization model, and here are the things that I consider off limits to the community; and then ideally create that white space that says, “And all these other things over there are ideas where we, as a community, could expand that.” So invite others in and define where innovation is welcome, where you see opportunities for others to create their business model, their integration model, around your project.

Now, let’s be perfectly blunt here. There are a lot of people in the open core community who would say, “Oh Dirk, but what you’re talking about isn’t open core.” Open core is that I alone control what can happen. And the people are welcome to send me submissions, but I control what can go in. So this is that dictator model that says, there is a single entity that gets to make all decisions. And I understand where they’re coming from. I understand why this field’s comfortable to a VC. I question whether this is a basis on which you can create a healthy community.

And one of the things that is different between my vision of where open source is useful and where it creates value, and some of these narrow open core people, is that to me, the engagement, the existence, the viability of the community of developers, really is a core element of saying open source helps the innovation here. So one of the things that I always push for is, a metric of your success is how many outside contributors you’re going to attract. And metric of your success is, how many people it takes to create, let’s say, half or 70% of your commits; the bus factor that we talked about in the past. How critical is a single company to the health of this project. What is the dependency model on outside forces.

And to me, that really is the challenge in open core, that the more rigidly defined you say the control of the company is, the less viable it becomes as open source; so the further it moves away from open source. So to come back to your question, if I were running an open core company, first answer is I don’t think I ever will, because that’s unlikely to be in my wheelhouse. It’s not something that I feel I have the right skillset for. Because one of the things that I will always do is I would push to a more open source and less source available model. I would push to a model that more encourages community, more encourages bringing in new thoughts, new idea, outside points of view, which is counter to this underlying idea of open core.

And in a way, I can turn this question around and say, if you look at what Microsoft tried to do 15 years ago with the source available projects that they launched, and you look at why they failed, it’s because they didn’t attract a community. They didn’t attract an ecosystem around them. Because people were understandably leery and concerned about what was going to happen in these projects, and how usage of these projects could become problematic for their business. And in a way, open core is kind of on this spectrum between fully open free software, even an ideology and the philosophy behind it. And shared source on the other end, it’s somewhere in the middle. And where you place this, is, to me in many ways, a core of how I evaluate that project. And how I would want the project to be perceived and to be run, is certainly more on the open source side, which is why I would be a bad choice to run an open core company.

Swapnil Bhartiya: It doesn’t matter how they look at open core. To many, it will sound like, “Hey, you know what, it is still better than a proprietary,” because depending on how you look at community, it has some limitation as compared to a fully open source project, but still you can see the code. You still have some say there, as we discussed. What about that? Is open core still better than proprietary?

Dirk Hohndel: I work in a proprietary software company. So, that value judgment that is kind of inherent in your question, is something that I kind of achieve on. Because, I think proprietary software is also, in a way, very honest about what it does and what it provides, and where the value lies. And so I think open core is much closer to proprietary software in many ways. Because if your contributions aren’t welcome, then access to the source might help you in debugging, but also would you invest the amount of time that it takes to understand the sources so you can effectively debug? If then, your contributions are potentially not welcome.

So I think it’s a very fine line, and it depends what you’re trying to do with that specific component of your software stack. I think there are many areas where proprietary software may actually be the better solution for you. My employer certainly think so. And there are very strong proprietary software products that you and I use every day. We’re doing this interview over Zoom where we are creating a video out of it using proprietary technologies. So I think it’s very dangerous to have this better or worse idea logged with the extremes being proprietary software and free software.

To me, what is valuable about open core is, as it encourages contributions, bug fixing, and expansion of its footprint by other outside entities, this part of open core goes back to the value of open source that I fully believe in, as it improves innovation, it gives more opportunity to create an ecosystem around it. And the parts where it turns into proprietary software… Because really that’s what open core is all about, is that there is a proprietary version of this software that is then hopefully successfully used by customers in that same industry, that’s where it blurs the lines. And I don’t think that blurring of the line can be described as better or worse. It’s just a different approach.

Swapnil Bhartiya: There is no doubt about that. We have to talk about it and I think we should have a dedicated section on just about proprietary software also. You said it all, I don’t have to repeat that, but we all rely on it just as much as we want most, or almost all, of the software to be open source. That is not reality. It boils down to whether it works for you or not. If it does, that’s what counts. Yes it might be ideal, but in some cases… Because open source is not open source for the sake of open source. Open source is more or less about whether there is a community who really wants to… Because there are a lot of open source projects which has only one contributor and everybody is a user. So I really don’t think that open source is the ultimate answer. Ideally it should, but it depends on what the project is all about, what is the community all about, what are the user base all about. There are so many factors.

Sometimes people should be able to use the project. That’s what matters, whether it’s open source or not. What is the point of having a fully open source, complicated, software that nobody can use?

Dirk Hohndel: I want to go back to what I pitched earlier, this idea of extensibility. And fundamentally, whether that thing that is extensible is open source, open core or proprietary, that’s not the point. What matters to you as a user of open source, whether as an end user or as a developer that uses a component in their software stack, is your ability to extend what this thing offers. If there is a feature that is missing, if there’s a use case that is not being understood, if there’s a broader context in which you want to use that, are you able to extend this layer in your software stack, and make it do the thing you want it to do, make it integrate into the infrastructure that you’re building, make it talk to these other components that you rely on. If you’re able to extend this thing, and if this extensibility is not restricted by a third party, then this is likely a project, a product, a component that will help you succeed, and that is sustainable over time.

The moment someone tells me, “Oh, but over here you’re not allowed to extend this,” that’s when I get nervous. And again, this can be either in proprietary or in open core software.