Degrees of Open

Openness

Neela Jacques shares a few of his thoughts before speaking on a panel at ONS on “Openness.” His panel included Dan Pitt (ONF), Margaret Chiosi (AT&T Labs) Prodip Sen (Verizon), Victor Lin (Google).

Customers of the IT industry have long said that being locked into proprietary platforms has real drawbacks – you are stuck with one vendor’s vision, one product roadmap, and the costs of switching can be high. Not a situation most customers enjoy. More, we have a huge systems integration industry in p​art because of the challenges of getting components from different companies to work with each other.  Finally, a lot of technologies that customers love get left to fade away or are made obsolete when a vendor’s priority changes.

So what’s the option? Go with an open platform. But what is Open? Is it a binary decision? I would argue that it’s not. I like to think of openness on a ten-point scale, with zero being the most closed you can be and ten being totally and completely Open. If you do that you get a map something like this:

0-2 Closed: This was the model 20 years ago, the idea of keeping your secret sauce secret. It’s not surprising that most big databases, ERP systems, operating systems began this way. If you ever hear a vendor suing another one for using a private API, you have a pretty good idea where they stand on the openness scale.

2-4 Mostly Closed: At this point few companies remain in the primary category. Customers just won’t stand for it. Many, though, are only marginally more open, adding limited APIs. Hopefully you have a REST API, but unfortunately too many products have custom, highly limited APIs. These are platforms that you find yourself committed to for a long, long time.

4-6 Open Plus: Proprietary software, built on top open source and/or open standards. MapR and Cloudera are great examples of companies that offer solutions built on top of an open platform (Hadoop) but whose solutions include elements that are quite proprietary. In many cases end users here can experience the best of both worlds – the performance from a highly tuned, controlled piece of software, but the ability to migrate to another member of the ecosystem if technical requirements change. I am seeing many vendors looking to offer such solutions leveraging the OpenDaylight project, and that’s just goodness.

6-8 Mostly Open: Open source commercial distributions take an open source code base and add testing, integration, services and support. You can migrate from one distribution to another, but few people do. Red Hat Enterprise Linux (RHEL) is a great example of this. The vast majority of what you’re getting is the Linux kernel. Most changes are upstreamed back into Linux and most changes/innovations to Linux will flow into RHEL. We have our first commercial distribution of OpenDaylight thanks to Inocybe Technologies. I believe we will see more. In fact I think something that would make a lot of sense is a commercial distribution of OpenStack with OpenDaylight. I believe we will see that also by the end of the year. 

8-10 Fully Open: Here we’re primarily talking about consuming open source in its most raw form. You get the code, you can change the code, you can deploy it, build a product or service around it, etc. etc. etc. The challenge of course is that to consume open source in its most raw form, you better have mad skills. Google does. So does Twitter. Most end users don’t.

So what should you choose? Is more open always better? It depends on your strategy, requirements and skill sets. There are lots of reasons you might value Open but lots of good reasons to also buy proprietary software. We are however seeing a shift in software models. From primarily options at the two ends of the spectrum to more in the middle – what I call Open Plus. I believe this is where the sweet spot lies, a soup that neither too hot nor too cold but just right.

I will leave you with five questions to consider the openness of a solution:

1. Does it integrate with other solutions from other vendors?

2. Does it have an API?

3. Does it follow open standards?

4. Is it based on open source components?

5. Does it upstream to open source projects?

 

Photo found on Flickr under Creative Commons license.

 

Cicking the stars above will update your previous feedback.