The contrasting shapes of the IBM-led Aperi group and the anti-Aperi Group (AAG) have become clearer over the weekend with the publication of a blog by HP's Duncan Campbell.

Campbell heads worldwide marketing for HP's StorageWorks business. Since no other AAG member has stepped forward to say what AAG is up to since Sun joined in last week then we may, for convenience and the time-being, refer to the AAG as an HP-led group.

What is AAG up to? We know Aperi is now going to have some group members, IBM, Fujitsu and Novell for example, submit code to a likely Eclipse Foundation open source project to provide an SMI-compliant code platform on which storage management products can be built and shipped.

The Aperi product will be Linux-based and so could run in a Windows server shop as a Linux appliance. Other Aperi members such as McDATA may well deliver code to the project.

Other members such as NetApp and LSI Logic, have no plans to ship code to Eclipse. It is hard to see what benefits they receive from Aperi other than ensuring that Aperi code supports their products. As they are SNIA members and strong SMI-S supporters and Aperi will support SMI-S then you may conclude that there doesn't seem to be any pressing reason for them to be in Aperi.

The SNIA's European chair, Paul Talbut, stated here that the Aperi group will be actively and supportively involved with the SNIA's SMI-S activities and: "The (SNIA) is developing the specification standard for storage management interoperability i.e. a document, while Aperi aims to create the code."

Against this background HP's Campbell describes what the AAG is going to do and what the current situation regarding SMI-S conformance is.

First of all he says HP is leading the effort. At face value it means we have an HP group facing an IBM group. Then he states: "We'll be enhancing SMI-S with new specifications and programming interfaces for a Web services framework for advanced storage management, and providing the first reference implementation of SMI-S."

I don't know how he can be so confident that the HP-led group will be enhancing SMI with new specifications and APIs. Being pedantic we know that neither HP nor the AAG 'owns' SMI-S. It is owned by the SNIA and members in workgroups decide how it will progress.

A European SNIA newsletter has an article on SMI-S by Frank Bunn, technical chair of the SNI Europe Germany committee, about SMI-S.

He says V1.1 is the current specification and it covers network-attached storage (NAS), iSCSI and tape libraries. The specification for SMI-S 1.2 is being worked upon and will offer increased end-user security and policy management. He foresees v1.3 appearing 2007 and it will address application and database integration, hopefully using XAM.

Any AAG initiatives will have to be grafted on to this structure and agreed by other SNIA members in the relevant workgroups, including, as Talbut has stated, Aperi members: "the development work proposed by these members is expected to be taking place within SNIA's current technical workgroups, committees, and forums as it relates to SMI-S specification work, tool development, and interoperability programs."

Campbell goes on to say that: "(We're) providing the first reference implementation of SMI-S. We're driving this effort through the Storage Networking Industry Association (SNIA), which has hundreds of members representing both IT vendors and users alike. We're leveraging this standards body to oversee Advanced SMI-S work and any reference implementation of SMI-S that results.

Any Aperi group reference implementation has to be approved. In Talbut's words: "The reference implementation, if approved, would be a new project that would fit naturally in SNIA's SMI technical committees, similar to how tools and test suites are created today and offered to our members."

In other words it is not a done deal in any sense.

Campbell asserts that HP's Storage Essentials product is far ahead of the Aperi group in terms of SMI-S support: "HP Storage Essentials has passed all four categories of SMI-S test cases: array, fabric, HBA, and switch.

IBM claims Aperi will work with SNIA to establish its code as a reference implementation of SMI-S. But the code that IBM is donating hasn't even passed the full battery of SMI-S 1.0.2 compliance tests. ... IBM's SRM product has only passed one SMI-S compliance test case.

So the code IBM is donating is not even fully compliant with the released version of SMI-S, never mind the advanced version of the specification that must still be defined by SNIA.

It seems there is a good case to be made that what we are seeing now is good, old-fashioned product development. Both Aperi and Anti-Aperi support the SNIA and aim to work within the SNIA structures. There will be no storage management standard schism.

Both have product: HP's Storage Essentials - presumably going to be happily OEM'd by other AAG members such as Sun; and IBM's Productivity Center, the million plus lines of code apparently destined to be the core of the Aperi product.

HP's product is more SMI-S-compliant than the IBM product. IBM is hoping, we can infer, that the open source development process, overseen by the Eclipse Foundation, will be faster than the HP development process, allowing it to catch up in terms of SMI-S-compliance.

This is good news for end-users as we have two groups now in a race to develop the most SMI-S-compliant storage management product. A downside is that there could be strongly-contested discussions in prospect in the relevant SMI-S committees as members of the two groups seek to advantage their own efforts and disadvantage the others.

Neither group 'owns' the SNIA and neither group has, in the writer's view, the moral high ground advantage from an SMI-S development stance. Open source has its devotees but even IBM uses open source development methods for some software and not for others.

Two sides of the same coin? It appears so with the coin still in development and one side having more definition than the other.