SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
The Many Shades Of Open
Every time I hear a vendor say "We have an open this or that" somewhere in the world, a Richard Stallman acolyte dies. Or that's the way it seems. Vendors have glommed onto "open" as if it is the all-important aspect of their product, whether the product or feature is in fact open or not. It belittles those features/protocols/standards that actually are open, while doing little to characterize what the specific feature is. There is nothing wrong with proprietary features and there are actually a
Mike Fratto
May 21, 2010
4 Min Read
Every time I hear a vendor say "We have an open this or that" somewhere in the world, a Richard Stallman acolyte dies. Or that's the way it seems. Vendors have glommed onto "open" as if it is the all-important aspect of their product, whether the product or feature is in fact open or not. It belittles those features/protocols/standards that actually are open, while doing little to characterize what the specific feature is. There is nothing wrong with proprietary features and there are actually a number of benefits. But let's drop the gratuitous use of open.
Over the years there have been more than a few definitions of open. Here are some:
Open as in open source. The source code is available for download and review, and you are free to copy, modify, link to, and distribute the source and binaries. But, just because your product uses open source software doesn't make your product open--as in open source--nor does it confer all the things that open source implies.
Open as in an open sandbox. Meaning, anyone can play in your sandbox as long as they play by your rules. A vendor can make a proprietary system but expose an API that anyone can integrate with. This is good for the vendor and the customer. Encumbering that "open" API with licenses, fees, non-disclosure agreements and other limitations is not open. It is in fact, closed.
Open as in free. If you give something away, it's not open. It's free. If you make an API that anyone can use, but they can't treat it like open source, then that is not open. Even if you give the API away with a license saying it is free, that doesn't make it open.
Open as in a limited duration trial license that you can freely use for the duration of the trial, but no longer. As in the case of "free," this is not open either; it is closed. This is trial ware. Free for non-commercial use is also not open.
Open as in using open protocols. If your product uses open protocols like XML or HTML, that doesn't make your product open. It makes your product accessible to others, but doesn't make it open. I write in English to make my scintillating thoughts accessible to English speakers, but still closed to all non-English speakers -- that is not open.
Open as in open standards. Standards that are developed openly and are made available to anyone to use and are unencumbered by licensing are open standards. It really doesn't matter which organization created them. The IETF is one example. The IEEE is another. Note that some standards are developed behind closed doors (Trusted Computing Group) but are available to anyone once published.
Open as in de facto standards. De facto standards may or may not be open. In fact, they may require paying a license to some entity or another. These standards, if they are in fact de facto, are simply widely adopted. Like the Graphics Interchange Format or the RSA algorithms prior to September 21st, 2000 when the patents expired. (RSA Security released the algorithms to the public domain two weeks prior. Big whoop.)
I could go on, but it's clear that there is open and there is open and there are shades of open in between. Unless you are talking about open as in open source, then you can only approach open, but not quite get there. Like Zeno's paradox--which states you can move half the distance between two objects infinitely thus never actually reaching your goal--you can't be open and encumber things at the same time. I will call this Fratto's Paradox™ and that is not open. You will have to pay me a license fee (or food) when you use it or something like it.
I know why vendors use the word open so much. Open is good and closed is bad, right? Nobody wants to be closed. Rather, no vendor wants to be perceived as closed, but they all are closed to one degree or another. Nearly every networking vendor talks about their open API to integrate their stuff with everyone elses' stuff, provided that everyone else comes and plays in their sandbox and agrees to their licensing terms and perhaps pays a licensing fee.
How do you know if something is truly open? Well, that is when you have to ask the questions to define what they mean by open or what the open applies to. For example, the nature of open will become increasingly important with public and private cloud computing where a number of different systems need to integrate together. There is standards work being developed in various groups, but the crux of the matter is that the standards, if they are going to take hold, have to be open in the truest sense of the word. And don't get me started on standards.
About the Author
You May Also Like
More Insights
