This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: PeopleOverProcess.com: Standards Sports
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
While I bookmarked this piece from Jon William Toigo, it's worth taking the blog-space to quote more from it (del.icio.us, sadly, only allows 255 characters). He has a great summary of the problem with what I call "Standards Sports," be it in storage or any other area:
In all honesty, the industry doesn't want heterogeneous storage management. The ability to manage all storage wares dumbs down marketing messages about a vendor's product differentiators. Worse yet, real heterogeneous management opens the door for a competitor's product to be placed in the same infrastructure with yours, all manageable via a single, universal pane of management glass. That is anathema to most hardware vendors we know.
He then points out that the interfaces in the storage market are historically roach motels. With standards, and, more importantly an open source community built around those standards:
Given a miniscule amount of funding and a little encouragement, the maniacal open-sourcers could use the wiles they have built over the years to find ways to circumvent the obstacles. Think about it: Joe writes some code that gets around a lock-out and gives you visibility into the internal workings of one vendor's arrays, which he then shares with the open source community. No longer will the storage management ISVs have to go hat in hand to every hardware vendor on the planet and beg for access to their APIs.
If this sort of "hack the planet" approach to developing a real storage management capability strikes you as unfair to hardware vendors, keep in mind that it has been a long time coming. It is in the nature of the open source community that it will beg, borrow, or invent hacks around any problems that stand in the path to success. That is exactly the chutzpah that will be required to fix storage management.
I, for one, think it is about time. Every other storage management initiative out there is either so proprietary that it will cost more than it saves by the time it is delivered to market, or it is doomed to fail by the proprietary nature of storage today.
As in any drug story, much of it deals with addiction and withdrawal from the drug in question. Here, "smack" as they quaintly call it; the book is from 1973.
In a sense, standardizing a previously proprietary infrastructure is very much like withdrawal: most people won't succeed, there's going to be a lot of pain, and all throughout, you're wondering, "why the hell am I doing this? And who is that three eyed frog that keeps telling me to order more Chinese?"
Your Rude Friend
What you need in such cases, is a friend who's not afraid to smack you around when you start reverting back to cooking up you proprietary code. This is especially true nowadays when so many companies and industry segments are getting and delivering on the standards and open source religion.
Standards
When it comes to standards, I'm starting to think, there are two types:
Emergent Standards - a standard is derived from existing code or code is written in parallel with the standard development. This time, the imagine is of developing mailing lists peppered with posts like "check out how I implemented it on my site." Features and code are delivered in small, but frequent bursts.
The desired end result of both is the same: a documented standard that a group of people agree on and, more importantly pledge to implement in the appropriate software in their realm of control. The biggest goal, of course, is to get wide acceptance of the standard. If a standard is ratified and no one uses it, did it really get ratified?
As you can guess, dear readers, my money is on the second process producing higher quality standards that are more widely used than the first.
Strong Arm Open Source
Creating an open source project, is of course, a good way to see a standard through to completion. But, when you're trying to use a standard to break your own proprietary silo apart, you need several Rude Friends to lead that project.
You may not know it now in your proprietary-induced bliss, eyes heavy with vendor lock-in, but once everything gets in the open, that voice called Revenue in your head is going to start yelling, and you'll be desperate to track down just one more hit to carry you over. I mean, it makes sense, right? We have to get through this next quarter, so we better keep using this sweet, sweet closed model...how else can we finally get open? I promise we'll get to it next quarter. Where's my spoon?
The same applies to open source sports as well, e.g., NetBeans vs. Eclipse. The word from Sun in particular seems to be "Game on! Hut-hut!"
Your Rude Friends are the ones who are there to smack you around when you start having those thoughts. Which, of course, implies that the leads of your open source project or standard are both strong-willed and not addicts. More importantly, you'll listen to them or, at least let them hold you at arm's length long enough for you to snap out of it.
Previous Topic
