OpenStack and "open core"

Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

The "open core" model, where certain features are reserved for an "enterprise edition" that is not open source, is not particularly popular with a large segment of the open-source community. There are certainly businesses that rely on the practice, but the ideas behind open core run counter to the ethos of open source in many ways. The OpenStack community has recently grappled with the definition of open core, which is explicitly disallowed as part of the project's principles (the "Four Opens"). It is not a simple question, as there are clearly gray areas, some of which came up in the discussion.

In early February, OpenStack technical committee (TC) chair Thierry Carrez posted a question to the project's development mailing list: what does "no open core" mean in 2016? The policy was adopted in 2010, when Rackspace was the sole owner of OpenStack, in order to differentiate it from Eucalyptus, which was another open-source cloud platform that was pursuing the open-core strategy. It was meant to send "strong signals that we would never follow such a strategy", which was "essential to form a real community".

But things are far different today, Carrez continued; there is a non-profit foundation at the helm, but there are also components that are proprietary and closed source being sold by member companies in their "enterprise editions". There are "drivers that expose functionality in proprietary components". (That situation led Bradley Kuhn to recently state that he knows of no OpenStack distributions that do not have at least some proprietary pieces.) Those pieces are clearly not a part of the OpenStack project, but how does that all mesh with "no open core"? He gave his view:

My personal take on that is that we can draw a line in the sand for what is acceptable as an official project in the upstream OpenStack open source effort. It should have a fully-functional, production-grade open source implementation. If you need proprietary software or a commercial entity to fully use the functionality of a project or getting serious about it, then it should not be accepted in OpenStack as an official project. It can still live as a non-official project and even be hosted under OpenStack infrastructure, but it should not be part of "OpenStack".

As he and others noted, the definitions of "fully-functional" and "production-grade" are somewhat unclear, but Carrez thought his take might make a reasonable starting point. While he didn't mention it specifically in that post, it became clear in the thread that there is at least one project that may fall outside of those boundaries. Poppy, which is not an official part of OpenStack but is part of the wider ecosystem, provides an interface to content delivery networks (CDNs) so that OpenStack installations can offer CDN-as-a-service. The problem is that there are no viable open-source CDN implementations, which means that it requires "proprietary software or a commercial entity" to use—or even to test.

Interoperating with commercial services is not typically seen as adding open-core functionality, exactly. As TC member Doug Hellmann put it:

The Poppy situation doesn't seem to be a case of open washing anything, or holding back features in order to sell a more advanced version. It happens that for Poppy to be useful, you have to buy another service for it to talk to (and to serve your data), but all of the Poppy code is actually open and there are several services to choose from. There is no "better" version of Poppy available for sale, if you buy a PoppyCDN subscription.

There is a moribund open-source CDN in the OpenCDN project, but a CDN is far more than just code. Ryan Brown pointed that out: "Open source projects aren't usually set up around making big capital expenditures and buying lots of bandwidth, so the lack of a FOSS CDN isn't exactly Poppy's fault." But even if there were an open-source CDN, and Poppy supported it, would that be sufficient? TC member Flavio Percoco raised that question:

When do we start considering a project to be safe from an open source perspective? Because, having support for 1 opensource technology doesn't mean it provides enough (or good) open source ways to deploy the software. If the only supported open solution is *terrible* then deployers would be left with only commercial solutions to choose from.

There was some talk of having Poppy provide some kind of "reference" open-source CDN, but that is not really something that the Poppy project wants to take on. There is no existing project to use, but there is more to it than that, as Poppy project member Amit Gandhi noted:

Also, even if the CDN software itself was open, the true value of a CDN comes from the distributed global network of servers it offers and its performance to serve requests. Not just the features/API offered. Poppy intends to be an abstraction API over the various CDNs available. We do not want to be in the business of building a CDN itself.

But OpenStack projects need to be able to be tested using the umbrella project's infrastructure. That will become problematic without an open-source CDN, as OpenStack Foundation cross-project developer coordinator Mike Perez explained:

If we don't have a solution like OpenCDN, Poppy has to adopt a reference implementation that is a commercial entity, and infra has to also be dependent on it. I get Infra is already dependent on public cloud donations, but if we start opening the door to allow projects to bring in those commercial dependencies, that's not good.

But Hellmann doesn't see Poppy as being all that much different from other OpenStack pieces:

Most of our successful services do the same thing. They abstract another service, but don't replicate it's features in their code base. Nova isn't a hypervisor. Cinder isn't a block device. Trove isn't a database. Neutron isn't an SDN. The *only* difference is that because of the nature of a CDN, running one yourself isn't practical and so there's no significant (or viable) open source implementation.

But without some support for an open-source option, Sean M. Collins argued, Poppy doesn't really fit into the OpenStack project:

I think Poppy would have a lot easier time getting into OpenStack were it to take the steps to build a back-end that would do the required operations to create a CDN - using a multi-region OpenStack cloud. Or even adopting an open source CDN. Something! Anything really! Yes, it's a lot of work, but without that, as I think others have stated - where's the OpenStack part?

Carrez circled back to the more general question of defining open core for OpenStack on February 22. He considered some alternate wordings from his original post, but worried that those left the door open to real open-core services in OpenStack. In the end, he suggested that perhaps it was best left up to the TC to decide what open core means on a case-by-case basis. That idea seems to have won the day—no real opposition to it was heard.

Meanwhile, the Poppy question came up at the TC meeting on February 23 (log). While some were not convinced that Poppy was open core in the true sense of that term, it was still not accepted into the OpenStack project. In a close vote, seven of the thirteen members felt that it still didn't meet the requirements to be included. It can still be hosted using OpenStack infrastructure, but will not be an official part of OpenStack.

That situation may change, especially if Poppy comes up with a way to be tested and tried without requiring proprietary services. It seems clear that the project is not intended to sell any additional OpenStack components—which is a major part of the objections to open core—but it still doesn't quite live up to the "open" in OpenStack.