This is a eights article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
No matter how good your SDK is, and how easy to integrate you made it, some licensees will still encounter issues during the integration. Those issues, ranked by the occurrence rate, would fall in one of the following categories:
- Invalid SDK usage (for example incorrectly installed or configured SDK, invalid API usage, incorrect license used);
- Environment issues (for example, lack of permissions to open the requested file);
- Lack of required system resource issues (lack of memory, disk space);
- Bugs in the SDK triggered by otherwise valid usage;
- Baseline issues (such as hardware issues, corrupted or infected operating system, etc).
There is little you can do for the last two categories. But the rest of the issues the SDK should handle as gracefully as possible. This means the licensee should know not only that the SDK cannot perform the requested operations, but also why the SDK cannot do that.
This is a seventh article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
We already discussed in the previous article, SDK Design Goal #5: Design for Extra Functionality, that when you initially develop your technology to be used internally, usually only the API necessary for the internal use is exposed. Thus you know extra work is needed when the technology is prepared for licensing, and now you are trying to decide which functionality should be available from your SDK.
Here you got a dilemma: Continue reading
A part of this article covers the issues related to C/C++/Java programming languages, and mentions relevant APIs. Feel free to skip those if you’re not familiar with the languages.
This is a sixth article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
When you developed your product, it only needed to work with files. After all, the users only needed to open the image file – or a set of files – and recognizes characters on it. Or to scan them for malware. Or to encode them into a video. Thus your technology operates on files. When you decide to make it available for licensing, this was the only option available to you.
Now you face a dilemma. Shall you take the technology as-is and make it available with its limited functionality? Or shall you spend time and effort, adding more functionality – and potentially more bugs – and delay the time to market? You speak with engineering, and they believe using only the files is good enough. You ask, what if someone wants to handle the data stored in memory? Or in the database blob? They say, this is not likely to happen, but even in this case it shouldn’t be difficult to dump this file into disk for processing. Just four lines of code or so. No big deal, right?
A part of this article covers the issues arising from designing C/C++ interfaces, and assumes basic knowledge of those languages.
This is a fifth article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
The technology you have developed works fine on a 32-bit Microsoft Windows. This is where it has been developed, this is where it has been used internally, and this is the platform it supports. Your marketing team sees no needs to support anything else, because your product already runs on both 32-bit and 64-bit Windows. Developing a separate 64-bit product would require significantly more effort, duplicate QA, and the expected performance gain for a 64-bit version is less than 1%.
Considering this, you decide to limit your SDK to a 32-bit Windows, and the API you created for it cements that. You happily using wchar_t Unicode strings all over the API, and you expect your SetIntValue function to accept pointers as well, because they’re the same size as the integer type on this platform. Your first licensees are also using 32-bit only, and don’t care about it. Everything goes well.
Suddenly Continue reading
This is a fourth article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
This goal works together with the prior one, Design for Extensibility. Let’s assume your SDK has passed the evaluation, the partner has integrated your product and is shipping. They are happy with the SDK quality, and everything goes well.
Then the other team in your organization asks you to extend the SDK just a bit. For example, they want the AV scanning function to return more information about the file. Or the OCR function to notify you about the progress. A pretty simple modification, which requires very slight modification of the API. Of course this would require a slight modification of the code using the SDK, but the internal team is ok with that. After all, they requested them, and they are ready and willing to modify their corresponding code using this SDK. And the modification is very small, so it is not a big real, right?
This is a third article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
So if you followed the Design Goal #1 article, your design is good and you assume you got everything needed for quick integration. Your SDK provides all the functionality you think the customers might ever need, it has every options you think the customer needs, and retrieves all the data you think the customers might ever need.
This is true, and will stay true until you get your first real customer, who’d be using your technology. And what happens next?
This article follows up the How to present the licensed technology the right way? and explains the SDK design goals necessary to present the technology properly. As I promised in that post, it would be followed up by several short posts explaining various design goals, and this is the first one.
The first, and probably one of most important goals, is to design the SDK the way that it could be integrated quickly.
Why is it so important?
During the last few years I had developed several multimedia applications. The applications were open-source, free and cross-platform, and therefore they needed the multimedia frameworks which would be open-source, free and cross-platform. Thus during those years I have used the following frameworks Qt native multimedia framework. First it was Phonon (Qt4) and then QmediaPlayer/Qt5, FFMpeg, and Gstreamer.
In this article I will summarize my personal experience with each framework, as well as provide some guidance where it should and should not be used based on my experience.
and why is it even important??
You may have created a good anti-malware engine, a good OCR engine, a good video encoder or whatever. And your product marketing believes there is market for offering this technology to other companies, and thus asking if the technology is ready to be presented to 3rd parties for the reasons mentioned in the article Why companies license technology from other companies?
Or maybe you have created a good product, which is successful on the market, but which would benefit from being integrated into 3rd party tools or components, for the reasons described in the article Why companies license technology to other companies?
In both cases you already have some code which implements the technology. This code is working, is well-received on market, has few issues and the customers are happy with it. This is all a licensee would need, so you’re ready right away, right?
Unfortunately, this is not enough.
The first built camera was installed in a remote place with no Ethernet connection, so it had to be WiFi-connected.
The second camera, however, would replace an existing outdated IP camera, so there was Ethernet connection. Considering this, I decided to power it through Ethernet.