SNIA chairman denies friction with Aperi

Sun Microsystems last month pulled out of the IBM-led open-source storage group Aperi, and said it would back an older SMI-S storage management software standardization effort being championed by the Storage Networking Industry Association (SNIA). After Sun's move, Aperi said it would place itself under the auspices of the vendor-neutral Eclipse Foundation. With that backdrop, Wayne Adams, chairman of SNIA's board of directors, recently spoke with Computerworld about friction between SNIA members who support the Aperi/Eclipse open source project -- and those who don't.

Excerpts from that interview follow:

Vendors such as HP and Sun have been critical of Aperi and have taken sides on the open-source issue. Has that created internal turmoil at the SNIA? There's no turmoil taking place inside SNIA. A lot of companies that founded Aperi are also members of the board and technical counsel of SNIA. What we've been working on inside SNIA is finding a way to do more software development in-house with our current governance document. The balance of it is that if SNIA was to do software development, under what licensing terms could that be done and what types of effort would be required by companies to make it successful.

That's the same thing the Eclipse Foundation also has to have -- a value proposition out there so there's a licensing model, and there's a cost of operations and a membership fee model and so on.

How does Aperi's move toward the Eclipse organization affect the situation? In the case of Aperi, they're working on a couple [of] different components ascribed to the SNIA: a storage management framework, an SMI-S client implementation and some type of work-around graphical user interface. So this is all about coded implementation of software, and one of those components is SMI-S. And it would be done in a fashion that is consistent to the norms of open-source development.

So is SNIA going forward with its own open-source effort, which competes with Aperi? At the moment, there is no software development in place that would be considered open source by SNIA. On 6-22, a group of vendors, which included [Hitachi Data Systems], Symantec, HP, Sun and EMC made a statement that they planned to make a reference implementation of SMI-S. That would be a set of software for the membership of SNIA to use as an example of how the specification should be implemented. It's an example or interpretation of the specification and includes all the feature sets. My understanding of Aperi is that they're only working SMI-S from a client (server) standpoint and there's an assumption that there will be a vendor community that will continue to provide SMI-S in their (storage) products.

But it still doesn't sound like you're working in conjunction with Aperi to help develop its open-source software. Is that true? It's been stated by Aperi that if they come up with new extensions to SMI-S or new interfaces that are specific to storage, they'd bring that to SNIA for consideration for technical specification standards work to get started around that. There's a lot of ifs and wills in what I'm saying. Until SNIA has a document in hand, it can only talk in the future tense.

You mentioned Aperi is working on a couple different components with SNIA, but how much of a real joint effort is this? Is this really just unilateral effort by Aperi? First of all, they are all speaking with SNIA. You're looking at a group of companies that are already members of SNIA and that are also members of the Aperi group. These are all companies that have current implementations of SMI-S. Most of these companies have made very strong contributions to SMI-S specification work.

What changes here? Instead of each company's engineering department building its own implementation of SMI-S..., they want to build it as a collective community of companies and somehow consume that into their product lines and offer that back to the industry. [Some believe] through open source that you can get more functionality coded up and available faster [as a group] than any one company could do it.

So has SNIA started working on any software implementations of SMI-S itself? The answer is no. It's been working on specification work to date. There's a plain intent to have a relationship with the Eclipse foundation, specifically the Aperi group, so that there's a cohesive, bilateral movement of information about the SMI-S specification back and forth between the groups.

How is Aperi's work going to help the user in the long run? That's a tough one to assess. It's all going to be based on what vendors make a business model around. You could say, 'What value has Red Hat brought to the market versus what value has SUSE brought to the market, versus what did they both bring that's different from what HP or IBM bring with AIX or HP-UX?' Is it price? Is it functionality? Is it capability? Is it high-end? Is it low-end?

It will find a niche in the market and it may not be everything to everyone, just as Linux isn't everything to everyone. Open-source storage management software will have a place in the market, but is it something for everyone? That's not known yet.

Do you see any friction between the Aperi and SMI-S efforts? I know that there are a lot of people that like to see conflict in the industry because it makes the news. But the Aperi and SNIA groups have been in discussion for several months and we've talked about how this will all work out and what's the exact relationship that we need to ensure both groups are successful. Neither group wants to have competing standards out there in the market. That's why there's a commitment by Aperi to have SMI-S be the first major storage management specification out there achieve this mission and goal.

Even with SMI-S, there seems to be competition between SNIA members to be the first to implement it and all its functionality. Is that hurting internal collaboration? I don't want it to sound like it's an IBM/HP type of argument here. It's an industry philosophy that open source is about coding first and then -- once the code settles down -- trying to sift out of it what could be a specification. Then there's a different group in the industry that believes it's better to write the specification and then write the code to that. What you're hearing is different philosophies from one group of vendors who believe that, before you code to some type of capability and begin to adopt it, you should write it down as a specification and then code and test to it.

And you don't see vendors like Sun that make public statements against Aperi as a sign of friction between the groups? I'll have to defer to Sun to explain their position.

So you're still actively meeting with members of Aperi, even though it's now under Eclipse? We will be. We haven't met actively yet, but we've been meeting up to the week of their announcements. So we just haven't laid out a timetable.

Are there internal leadership issues within SNIA that is causing the SMI-S standard effort to bog down? There are no leadership issues going on. This is all about creating end product for end users. And, how often can the data center do major up revs of its software? The industry norm is one to two times a year. All the specification work is based on one to two times a year. So there's a lot of functionality inside of SMI-S and the balance of speed to implementation rests on vendors to decide on when they want to code that functionality in there. Most of what you're hearing about in terms of speed of implementation has to do with how fast do vendors want to code this capability into their products.

In terms of where the criticism comes that SMI-S isn't moving fast enough, there's never been a standard that's ever been created in the industry that's been faster than proprietary innovation.