When a protocol is standardized and adopted multiple vendors as a way to connect systems or subsystems, the following things start to emerge:
- A formal protocol specification
- Web pages describing the protocol
- Books about or with chapters about the protocol
- Example open-source implementations
- Standard interface libraries
- Conformance test suites
- Benchmarking suites
- Protocol analysers and recorders
It's been my observation that the software developers and architects tend to have a major say in the selection of protocols, especially for subsystem interconnects, and that they tend to choose the protocol that makes their life the easiest. Thus, protocols that have all of these resources widely and inexpensively available quickly become the protocol of choice, resulting in a continued upward spiral of adoption, experience, tools and systems.
We're starting to see this with XAM, with #1, #4 and #5 already available, and #2, #6 in progress. And I'm sure that somewhere out there, someone's writing a book about XAM, or at least a chapter about it.
In the cloud storage protocol arena, Amazon's S3 service has such a strong lead in this area with their S3 HTTP protocol that many of these resources have already been built, despite it being a proprietary protocol. While most other cloud storage service providers have built similar HTTP protocols, with the IP ownership restrictions around Amazon's protocol still up in the air, there is a fair bit of uncertainty if their protocol will ever be able to be used with more than S3.
Which leads us back to the need for standardized protocols.