SDK Design Goal #5: Design for Extra Functionality

August 9, 2016 George

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?
Continue reading »

SDK tsar , , Comments Off on SDK Design Goal #5: Design for Extra Functionality

SDK Design Goal #4: Design for Future Portability

August 1, 2016 George

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 »

SDK tsar , Comments Off on SDK Design Goal #4: Design for Future Portability

SDK Design Goal #3: Design for Backward Compatibility

July 23, 2016 George

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?

Continue reading »

Uncategorized Comments Off on SDK Design Goal #3: Design for Backward Compatibility

SDK Design Goal #2: Design for Extensibility

July 7, 2016 George

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?

Continue reading »

Uncategorized Comments Off on SDK Design Goal #2: Design for Extensibility

SDK Design Goal #1: Design for Quick Integration

June 30, 2016 George

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?
Continue reading »

SDK tsar Comments Off on SDK Design Goal #1: Design for Quick Integration

QtMultimedia, FFMpeg, Gstreamer: comparing multimedia frameworks

June 16, 2016 George

Update Feb 7, 2019: despite being written ten years ago and last updated three years ago, this article content remains correct, and still describes the actual situation with the multimedia frameworks.

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.

Continue reading »

android, Linux, qt , , , 7 Comments

How to present the licensed technology the right way?

June 14, 2016 George

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.

Continue reading »

licensing, SDK tsar Comments Off on How to present the licensed technology the right way?

Building a Raspberry Pi-based camera powered by Ethernet

June 7, 2016 George

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.
Continue reading »

Uncategorized Comments Off on Building a Raspberry Pi-based camera powered by Ethernet

Building a WiFi-connected streaming camera and video recorder using Raspberry Pi 3

May 30, 2016 George

This post explains how to build a WiFi-connected video recorder and streaming camera using Raspberry Pi 3.

I wanted to install a survellance camera to watch the front yard over Internet, and to record video. Unfortunately good-quality connected cameras are expensive, and the image quality is not so good. For example, most are unable to record 1080p, and the camera optics quality itself is not good. The ones with decent quality output have a stiff price tag, and most are cloud-based in some way (configuration or output), which means the company might start charging monthly fees for it, or even shut down the whole product at anytime.

The solution is to use the Raspberry Pi 3. One of its accessories is a camera, which is actually a very good camera with good optics, great resolution and viewangle. It has hardware MP4 encoder, and is capable of recording video with 1080p resolution. And the Raspberry Pi 3 has a built-in WiFi, which allows installing a camera without the Ethernet connection. While using WiFi for the security devices is not very reliable (as it could be easily jammed), the camera records video into the internal storage. So jamming is not much a security concern if the camera body itself is not easily accessible.

Using Raspberry Pi also gives you ability to use motion detection, and only record video when motion is detected. You can also configure it to alert you when motion is detected, perform face recognition and do many other cool things.

Continue reading »

Linux, Raspberry Pi , , , , , 4 Comments

The Biggest Myth of Technology Licensing

May 19, 2016 George

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?

Continue reading »

licensing, SDK tsar , Comments Off on The Biggest Myth of Technology Licensing