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.
Or does technology licensing work against the company?
In the previous article I mentioned the reasons for licensing the technology. But still one question remains unanswered: if you license technology for financial reasons – to earn money – is it worth it? Or, stated more typically,
Yes, it is good to make extra money, but by licensing our technology, aren’t we just creating or empowering our competitors, who would now directly compete with our own products, and therefore damage our profits?
I’ve been working for the technology licensing units more than ten years, and there seem to be confusion of why companies license technologies to other companies, and from other companies. Isn’t it easier/better/more reliable to develop your own?
And understanding why it happens is very important, because for example when you design the SDK for the licensing, many design decisions would be influenced by this reasoning. Hence this explanation is necessary, so the engineers would understand what is needed.