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.
For the last twelve years I have been working as an “SDK tsar” in several different companies. This usually meant the company had a technology or technologies which it would like to offer for licensing. The majority of those technologies were excellent quality products and services, incorporating genius ideas and brilliant engineering solution. Unfortunately the way some of them were presented made it much harder for the potential licensee to understand the quality of the technology. As a result, the valuation of the technology suffered, and so did the licensing fees.
On the other hand, some other companies had a much worse technology, which performed significantly poorer. Still they were able to gain significantly more business licensing that technology, even though it was clearly inferior. Why? Because the technology was presented in the right way, which increased its perceived value.
This is a very typical issue when I review a new technology which is going to be licensed. All engineers I have been worked with have been exceptionally skilled individuals, working hard to offer the best technology possible. Unfortunately, what the engineers perceive the best is typically only the best for internal use, and sometime even only within a specific team. This is understanding, as the decisions about API, architecture, documentation are all influenced by the background, education, corporate culture and other things, which create a specific set of values. Each engineering team tends to bring together the people who share those values. The problem is that the potential licensees, who would be evaluating the technology, most likely would have a different education or corporate culture, and thus different values. Thus their expectations of what is “the best” would be different.
Right way is not the best way!
When the technology is presented the right way, it is not presented in the best way as a team developing it would consider. Instead it is presented such as most engineer as a whole would accept it as reasonable, intuitive and obvious. They might still mutter “..We’d name this variable times and not attempts, right Pete?…“, but they would certainly understand the reasons it is presented this way, and would be able to resonate with it.
The technologies I’m working are the SDK libraries and remote services. Hence this article would focus on them exclusively. The same principles might apply to other technologies, however I don’t know much about them (such as hardware technology offerings), so I’ll gladly let others, who’re experts in that area, to speak.
Now, please look again at the goals mentioned in why companies license technology FROM other companies article. The company wants to license technology from you because they want to go to market quickly, and without major engineering effort. Hence it is not enough your technology to be just available – it must be available in a way which would allow the company to fulfill those goals. And unless it was designed like that from the beginning, this would hardly be the case.
The technology presentation design is the most important consideration, as the rest is following. A good design starts with the right mindset, as it should incorporate the following design goals. Each of those goals is explained in a dedicated article:
- SDK Design Goal #1: Design for Quick Integration
- SDK Design Goal #2: Design for Extensibility
- SDK Design Goal #3: Design for Backward Compatibility
- SDK Design Goal #4: Design for Future Portability
- SDK Design Goal #5: Design for Extra Functionality
- SDK Design Goal #6: Design for Purpose
- SDK Design Goal #7: Design for Troubleshooting
- SDK Design Goal #8: Design for Synergy