This is the last article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
You have made your core technology available for licensing. Because you followed the recommendations, your first SDK has been very successful on market. Licensees praised it for its easiness of use and quick integration, its features and robustness. However your product contains more than just the core technology – you have your support libraries, the rendering engine, a driver. And unexpectedly, your licensees start asking you to make available those other technologies as well. You may wonder, why? After all, creating a driver, or a rendering engine should be an easy task comparing to creating your core technology. And if someone doesn’t want to do this, it is available from other companies – there are even free, open-source versions! So why do the licensees ask for that?
The reason is that a licensee wants to quickly boost up the offered functionality of their product. They follow the same logic as they had when licensing your SDK in the first place – they have no time to design, develop and test those features. They would rather pay someone who has already done that – someone like you – and be faster on a market.
It may be less obvious why they came to you instead of using a possibly cheaper (even free!) 3rd party component. There are two reasons.
First reason: they have already experienced the quality of your technology offering, and they assume that your other technologies would be of the same quality. Thus they are confident the integration would be fast and painless – and this might not be the case if they choose a 3rd party solution.
Second reason: it helps them to avoid the vendor finger pointing nightmare. This happens when you use together the technologies from vendors A and B, and your product breaks. Vendor A debugs the issue, and tells you “our code works correctly, the problem is in B’s code”. B picks up the problem, and guess what – their code works fine, the problem then should be in A‘s code. Here both vendors would be right: for example, if your code calls a function in A which calls function in B using the argument you passed to A, the problem may actually be in your code. But this would take days to find out, and during this time your engineers are mostly forwarding emails between companies. This gets even more difficult if for some reason you don’t want Vendor A to know you’re using Vendor B or vice versa – as now all emails and debugging information has to be scrubbed before being forwarded, adding more useless work. No surprise that most licensees prefer to get everything from one vendor, so they only deal with a single company when things go wrong.
Thus you decided to provide the second SDK. What are things to watch out, besides what we have already discussed?
- Make sure your SDKs works well together. Your SDKs should obviously be tested separately, but then an extra testing, with two SDKs working together, is needed too as it is possible that they interact in some way which breaks one of the SDKs, or one SDK impacts the performance of another one (this happens often with anti-virus solutions). On the source code level make sure the definitions do not clash (for example, you do not define CODE_SUCCESS as 1 in one SDK, and as 256 in another SDK).
- Avoid code duplication. For example, when both SDKs use the same driver, the SDK installation routine shall detect this situation and not install an additional driver or uninstall an existing driver. If they both use the same set of libraries, install them separately so both SDKs can use them.
- Implement the necessary functionality in the SDK API. If one SDK can use another SDK directly, it is better to implement this through extra functions in its API. Not only it will make the life of your licensees easier, but it will also serve as implicit hint that there is another SDK they could benefit from.
- Document how and when to use both SDKs together. Your documentation should acknowledge the existence of other SDKs, mention the use cases when the use of the second SDK would be beneficial, and explain how to use it. If two SDKs have to be loaded or initialized in a specific sequence, this also should be documented. An example which uses both SDKs would serve as a good starting point for a relevant licensee.
- Build on past experience. The licensee already learned about your SDK language conventions, so if you follow the same style, it will make it easier for them. For example, having ERROR_MEMORY in one SDK and ERROR_OUT_OF_MEMORY in another one might confuse the users, who might think those are triggered by different conditions. If you follow the same standard in API, documentation and usage rules through all your SDKs, not only your licensees will have easier time, but they will also perceive your SDK as easier.
As a final note, please do not split your SDK in a very granular units. If every licensee would have to use at least the same two of your SDKs, it may make sense to combine them into a single SDK, to make the licensee life easier.