OpenStack, the open-source cloud infrastructure project, has a lot of community activity. Perhaps too much, as I've argued before.

There are at least two ways to tame the OpenStack community beast. One is to have a dominant vendor step in and orchestrate order. The second is to take a more bottom-up approach.

Mirantis, a pure-play OpenStack vendor that made waves in late 2013 by suggesting OpenStack threatened traditional platform-as-a-service (PaaS) vendors, is behind this latter approach—to wit, a new compatibility testing initiative that could significantly help OpenStack. Though it would also likely undermine Red Hat, the project's de facto dominant vendor, which has its own compatibility certification program.

Given Red Hat's outsized contributions to OpenStack, it's a bold move. Red Hat is OpenStack's top contributor, representing 20% of all code commits; Mirantis comes in fifth place with 6% of commits.

I caught up with Mirantis co-founder and chief marketing officer Boris Renski to find out more.

Opening Up OpenStack

ReadWrite: This new open compatibility testing initiative in OpenStack looks like another controversial move for Mirantis, one aimed pretty clearly at Red Hat. What’s going on here?

Boris Renski: This is not about Red Hat. Historically, most large open source communities like Linux or Apache Hadoop have delegated the job of testing and certification to downstream distribution vendors. For example, Red Hat has a very large ecosystem of partners that have certified their software solutions against Red Hat Enterprise Linux. Cloudera does much the same for Apache Hadoop.

Such certification programs are proprietary to a vendor running the certification and there is little transparency from the customer standpoint. Some vendors actually do go through compatibility testing that ranges from rigorous to little more than a check box exercise. In the worst case, they may just sign a paper and do a press release about a partnership. 

Having each distribution vendor manage their own proprietary certification program may have been relevant 15 years ago when the Internet was just becoming mainstream and tools for collaborative software development - like bug tracking tools, peer review systems and CI tools - were in their infancy and enterprises didn’t understand open source licenses and wanted as many reps and warranties included as possible (beyond certification even).

Today, however, when it comes to open source stacks, there is little reason to run a proprietary certification process other than to create customer lock-in.  

We’re standing today with the OpenStack community to champion an open process for vendor compatibility testing that, I believe, will disrupt the traditional closed certification model. The OpenStack community has produced a standard set of compatibility testing tools. If I am, say, a storage vendor, I can deploy these tools in my internal lab, connect to the upstream OpenStack continuous integration system and, most importantly, expose the results of these compatibility tests via an interactive dashboard that is available to the public. This will give everybody an objective and accurate picture of how well my storage fabric works with a particular release of OpenStack. 

The Death Of Traditional Certification?

RWIn your blog, you claim the traditional vendor certification model used for many years is somehow flawed. Can you talk more about this?

BRThe problem with proprietary certifications is that they are prone to vendor politics. Say, for the sake of a hypothetical example, I am a Linux distribution vendor like Red Hat, Canonical or SUSE—all of whom are important OpenStack backers and code contributors—and I don’t want a small vendor like Inktank or Midokura to run on top of my Linux distribution because it will disrupt some other product in my corporate portfolio.

What would I do?

Well, I can say that I won’t certify or support them on top of my platform. As a result, a customer running a particular platform will be unable to take advantage of innovations from the smaller guys simply because the big guys have a conflicting sales agenda.

I am not accusing anyone in the OpenStack ecosystem of this today, but historically the technology industry is choked with examples. At Mirantis, we believe that the core OpenStack mission is not just about the software that the community produces, but about the wave of infrastructure commoditization that OpenStack has created. To that effect, a new community-driven, open process for testing and certification is key to realizing this mission.  

RW: Who else is supporting the initiative so far? 

BR: The initiative was not our idea. It was a grassroots movement initiated by some of the project technical leads in the OpenStack technical community. We just thought it was such a great idea, and inevitable anyways, so we chose to dedicate Mirantis resources to support it. 

At this point, I have consulted with almost all of the OpenStack Foundation board members as well as the foundation staff about the initiative and everyone is on board. We’ve also attracted support from some of the biggest OpenStack vendors and customers in the world, including AT&T, Dreamhost, HP, Hitachi Data Systems, NetApp, Yahoo! and dozens more. 

Closing Thoughts

This open certification program may work. Enterprises, if they had their druthers, would likely prefer a vendor-neutral certification. But Mirantis has tried to end-run Red Hat's influence before, introducing a professional certification in December 2013 to compete with Red Hat's own previously-announced certification. It's not clear this has been effective.

It's also not clear that enterprises will entrust a neutral but lightly-used certification as opposed to a vendor-dominated certification. In open source, code is currency and she who contributes the most tends to influence the most. Today, Red Hat contributes the most and is therefore in the best position to dictate certification. The OpenStack constellation increasingly revolves around Red Hat. 

To change this fact, Mirantis and others will need to contribute more than a certification process. They'll need to contribute code.

Image courtesy of Shutterstock