Building a Successful SDK

Software Development Kits are a big part of what we do at Authentium.


For more than a decade, we have packaged and released system-level tool kits, including Linux and Windows-based antivirus SDKs, personal firewall SDKs, and system-level file-hardening tools.

These tool kits have been used by many industry leaders in the security, SAAS-based managed services, and telecommunications industries to create new products and services.

Based on this experience, we have learned a lot about what tool kits need to offer engineering teams. But first, let's start with a proper definition.

Software Development Kits (SDKs) should enable developers outside of the distributing organization to access and utilize the code/intellectual property in a way that clearly defines both the scope of the intellectual property (IP), and the scope of what is allowed to be done with it.

The commercial model needs to closely match the scope of the toolkit. If your toolkit effectively allows other companies to compete with you, or includes some significant ongoing service commitments (both these are true with respect to anti-virus tool kits, for example), then your model needs to take into account the need to price using a "co-opetition" model and fund the ongoing service costs.

SDKs by definition also need to be well-documented, starting with the licensing schema.

It is extremely important to let developers know up-front what can and can't be done with the code. In my opinion, Firefox does an excellent job of explaining what is covered under general public license (GPL) and what is owned by the third party developer. Knowing what the tool kit owner owns, and what you could potentially own, based on your use of the kit, is important when licensing in code.

Documents designed to inform engineers are the next step. There is nothing worse than "snobby" or badly-written documentation. Engineers face deadlines and have limited time to learn your code. They need to know that your engineers are dedicated to bringing them up to speed and helping them make this deadline - the quality of your documentation reflects this better than anything else.

For me, the first step in testing your documentation should be to ask someone that has never tried your toolkit to build something with it. Does the documentation clearly enable the engineer to create something using your toolkit, without resorting to calling the manufacturer? If the answer is yes, and your legal agreement is clear, proceed.

Features found in the product that a toolkit is based on are often not included in the SDK. In my view, this is wrong - rather than force your partners to "reinvent the wheel" you should present them with features as part of your commercial model. Include them in the code and value them correctly - that way, everyone wins.

The final thing any decent open platform code-base or SDK needs is good support, provided by people who are proud of the code and willing to help. SDK need to be supported either by an interactive, wiki-based community, such as is the case with Linux, PayPal or Firefox, or by a dedicated team of engineers prepared to answer questions from other developers.

In summary, SDKs need precise legal and commercial definitions, an appropriate and understandable commercial model, great documentation, cool features, and solid support. If you have all these, your SDK should be successful.

Note: My thanks to Vladimir Dubovik at US Bank for asking the question that led to this post.