Open Platform

“Open”

Sounds better than “Closed” doesn’t it, but in many cases it is just the usual bullshit that we’ve become so accustomed to. In many cases it’s a trap.

“Open” seems to suggest that you can easily enter the box, but also that you can leave if you want to. You might expect it to be almost as easily as it was to enter. What you’ll find is that in many cases, it is actually quite hard to find the exit.

“Open” has to come with some kind of proof. It’s not enough that the warden keeps the door unlocked, if he still keeps the key dangling around his neck all day. Who knows if or when the warden decides to lock the door?

A good strategy to baffle you, is to toss around technical terms that you might associate with “Openness”; XML, JSON, SOAP for example, but those terms have nothing to do with openness. It’s as indicative of the openness of a system as if I suggested that you can simply replace English with Danish because both languages use (almost) the same letters.

{ “a” : “21xx1fgwccr21223==” }

The above is perfectly valid JSON, but what does it mean? Oh, just call the vendor. The vendor who sold you the (expensive) box you are trying to flee. Sure – he will help you out.

{ “camera ip” : “192.168.0.100” }

The above is also JSON, but you can (hopefully) make sense of it, and you don’t need to call the asshole vendor who ripped you off. My guess is that if the vendor was kind enough to provide this sort of clarity, you might not want to leave in the first place.

Naturally there are things that are just a lot more complex. If you’ve ever written a MPEG decoder, it’s just not possible to express that in a way that a regular, non-dev, can easily understand, but the documents exist, they are freely available, and everyone (almost) does it the same way. The same applies to RTSP/RTP.

Does this mean that I can plug in my own/someone else’s stuff? Yes, and No. Imagine that a vendor does provide a readable interface via JSON. You ask your good friends at some company to write a plugin, which should be easy, because… you know.. JSON, Open, and all that good stuff.

So the poor coder writes a piece of code that extracts “camera ip” from the JSON document, and does something wonderful and innovative with the information. Everyone is happy, and there is much rejoicing.

The vendor sees (from his castle on the mountain in Mordor) that you are unusually happy, and dancing around, free of their shackles. But in their evil, evil and dark minds, they are cooking up a devious plan. The next version you install causes the integration to fall to pieces, and it all turns to shit. Luckily, the vendor has an integration that looks very similar to the one that just broke. What happened? Oh, the new version replaces “camera ip” with “camera_ip”. Still readable, still JSON, still “Open”?

VMS and Camera vendors fall into two categories; either they adhere standard and enter the apples to apples comparison war, or they don’t and instead try to lure you into the trap.

As I have whined about before, one of the founders of ONVIF actually disables it per default on their camera. This company goes out of their way to make it hard for you to use ONVIF, but at the same time provide a much simpler (but proprietary) alternative. If the simpler protocol was not universally supported by almost all NVR vendors, no-one in their right mind would buy their cameras. Granted there are rational reasons to disable ONVIF, but why then did they not steer ONVIF in the direction that it was not a security risk?

On the other hand, Apple gave us the iPod and killed the “Open” MP3 player. Apple’s OS only runs on their hardware (unless you jump through hoops), whereas any old manufacturer can build an Android phone. Both models can work, and there is nothing wrong with settling for “Closed”, but it would be great if you made that choice knowingly.