Last week, we introduced the players on either side of the Aperi battle. Today and next time we'll look at content - what there is of it, anyway.
The Aperi project's stated goal is to create an open and vendor-neutral storage management framework, placing lots of code in the hands of the open source community so it can create complementary interoperable and simply managed products, capabilities, and services around the Aperi framework. IBM and McData are contributing lots of code to get things started off, and have partnered with Brocade, CA, Cisco, Emulex, Fujitsu, Engenio, and NetApp to support the Aperi effort.
HP, EMC, Hitachi, Sun, and Symantec are opposed to Aperi.
As I pointed out last week, most of this alignment seems to be along easily defined party lines, with (mostly) contributors to the IBM ecosystem on one side and competitors (mostly) on the other.
A quick overview of the chronology shows following:
1. In October of 2005, a group of vendors (the pro-Aperi ones mentioned above, plus Sun) announced Aperi and invited other firms to join. (See "IBM leads group to create open source storage software")
2. EMC immediately issued a statement that "We were ... not notified or given the opportunity to engage in this proposed initiative prior to IBM already briefing the media..."
3. On June 21 of this year, Sun withdrew from the Aperi group.
4. On June 22, HP, EMC, Hitachi, Sun, and Symantec issued a press release describing plans to extend the SMI-S standard and to provide a reference architecture.
5. On June 28, the Aperi group announced that development would take place under the aegis of the Eclipse Foundation. Eclipse is an open source group of vendors, universities and individuals. See IBM's Web site for this announcement, and a description of a proposed Aperi architecture.
6. The Aperi group is scheduled to publish a technical roadmap in the third quarter of this year.
At this point, I must remind readers that "open source," while in many cases useful, is in no way the same thing as a standard, and certainly does not mean "free."
First, standards come in two flavors, legislated standards (think the stuff that goes through any standards organization, like SNIA or the IETF), and de facto standards, where a product literally "sets the standard" (alas, think Microsoft Word). If you don't believe me regarding standards, consider what happened to Unix.
Words like "open" and "free" are, sadly, just words. Just how "open" is OpenVMS (the openness of OpenVMS is pretty meaningless if you are not an ally of HP), or just how open was the software from the Open Software Foundation (the answer here, of course, is "not very" - it was a business response to Unix System V r4).
There are good, valid answers for all of this, and all these answers have much to do with politics, economics, business and corporate bottom lines. It is safe to assume that vendors do what they do, including participating in standards development, based on their own self-interest. Shame on them for wanting to reward their investors and pay their employees.
All of which leads to two basic questions.
First, when is a "standard" not a standard? When only a few companies rely on it (the corollary, of course, is "when many companies can ignore it with impunity"). Next: when is "open" not open? When not all companies have credible, equal access.