When you work with standards it is hard to differentiate.

Take for example the browser market. Not all browsers are created equal. Taking a look at the 4 major browsers on the market today, and trying to summarize each one in a sentence, this is what you will get:

• Internet Explorer – Largest “customer base”, not adhering to standards
• Firefox – Full of plugins, liked by developers and bloggers, memory hog
• Safari – Fastest browser on the market
• Opera – Great for embedded and mobile platforms, no market on desktops

These browsers provide the same kind of functionality – internet access. Each one of them is a brand of its own, differentiated from the others for better or worse.

As a vendor selling standardized technology and SDKs for other developers to work with, the differentiation issue is important. I have discussed the characteristics of a good protocol stack in the past, and from the impending flame war going on around IE 8 web standards, it got me thinking again – how do we differentiate ourselves? The answer is design and support.

Design

Design deals with all of the issues raised when I mentioned web browsers earlier.

A good SDK must take into account a varied customer base, where each one takes their product in a different direction. It needs to be:

1. Interoperable (Internet Explorer) – Last but not least, as we’re dealing with standards – it should be interoperable
2. Flexible (Firefox) – to allow customer differentiation and innovation to be developed around and on top of the SDK itself
3. Optimized (Firefox) - both for memory use and performance, so it will fit tiny devices and memory/CPU sensitive products
4. Portable (Opera) – to fit as many customer needs as possible, and not only a single niche market or platform. Some customers want to develop an end-to-end solution and will use the SDK on client and server products in parallel. Other customers would rather rely on a single SDK for multiple product lines which are similar (doing VoIP on both WiFi phones and WiFi access points for example)
5. Scalable – otherwise, it can’t fit large scale servers

Support

As these are SDKs going to developers, these products tend to be quite complex. This makes support a crucial issue to customers:

1. Debugging – SDKs should have enough debugging technologies built into them to make the work of those developing products with them easier. These should include flexible logging mechanisms, internal inspection capabilities exposed to developers, etc.
2. Maintenance – Not part of the SDK itself, but a crucial part nonetheless. Developers using SDKs should have a technical point of contact for handling issues arising during their development – be it questions on how to use the APIs, interoperability issues or bugs.
3. Upgrades - Standards don’t live in a vacuum. They evolve, requiring vendors to add more functionality into their own products. To enable this, SDKs should also evolve and allow for easy upgrading with backward compatibility.

In my many years of providing SDKs to customers, I can say that the major design considerations are the factors affecting the purchase decisions of most first time customers, while the support factors are those that in the end make the difference between the vendors for repeat customers.

My suggestion to those of you who are looking for SDKs to work with is to take a look at the SDK vendors and see who gets more repeat customers – these are the vendors to work with.