Open Source vs. Interoperable
Open Source is one of the current buzz terms in technology. In the world of software applications and services offering to make the source code of a program freely available is certainly a noble gesture. Interoperable is more of a design specification and philosophy to make sure systems and devices can interact and communicate with each other, regardless of vendor enabling the entire media chain to function. What a concept!
The term Open Source means the original application source code is accessible and available to anyone – this is a good thing – and it means that it can be changed by anyone – this is a bad thing. Interoperable is almost a direct contradiction to open source because what interoperable means is that applications and systems should be able to communicate with each other based on accepted standards, specifications and protocols. Now before we all get cranky, Open Source can support interoperability, it’s just not a requirement.
Let’s break this down a bit
Linus Torvalds with his introduction of Linux was the first to popularize open source and since then it has become very popular among programmers and accepted by many end users. Almost to the point that it is pretty common for someone looking for an application to just say “it’s probably open source and I can get it for free”.
When Linux was first introduced, it was all open source for anyone to modify and there were a lot of contributions. This introduced a small issue of interoperability. How do you develop applications that need an operating system if each version of the operating system is different? If each instance of the operating system is different, how do applications, device drivers, systems and devices communicate? To address some of these issues along comes Red Hat. And they introduce a version of Linux they will support and manage for a fee. While Linux is still open source, the Red Hat version promises consistency, support and warranties their version. They continue to participate in the open source arena, however their products are keeping to a tested and stable version of anything they publish. As companies saw the benefits of Linux, they also wanted the security of a stable platform to build services on. There’s a pretty high level of insecurity when the enterprise servers are running a “home grown” version of Linux that is more than likely undocumented and even more unlikely backed up.
Another consideration that the corporate world is less concerned with is Interoperability between applications. However they are concerned with device drivers and communication systems. Linux has become something of a standard in server applications and has migrated to main stream operating systems. Many broadcast servers run on Linux. BUT, even though the version of Linux that’s installed is technically open source, the manufacturer makes very clear caveats and warnings about making any changes to the core operating system without voiding the warranty and the manufacturer becoming very unwilling to support it.
Now let’s see how this applies to the broadcast industry
As the industry becomes more software and server based, it is also adopting many common practices from enterprise IT and commercial applications. There are two (2) main conditions,
- Manufacturers are producing some of their products as Open Source applications.
- System engineers are expecting and looking for solutions that are Open Source applications.
The business model of open source is a little unclear. If a manufacturer develops an application that’s their product and then posts it as open source, what prevents free sharing? Or do they require a subscription and SLA with permission to access the “open source” and then control under warranty what they will or will not support if a user makes changes.
As I mentioned earlier, one of the key differences between enterprise services and applications and broadcast products and services is interoperability. Word applications do not need to communicate with accounting and accounting doesn’t communicate with graphics.
Broadcast is a little different. Traditionally, SDI In & SDI Out is a standard and interoperable across all SDI systems and devices. Internally, each manufacturer processes the SDI with their proprietary technology, but the in & out is based on standards that assure interoperability. As technology migrates to computer technology, all systems, services, applications and devices still need to interoperate with each other.
- Camera systems communicate and interact with switchers, recorders and editors, plus control and intercom.
- Audio communicates with microphones, playback sources, intercom, recorders and editors, and on and on.
Interoperability applies to applications that can co-reside on the same server or computer, there may be a specific hardware component that one application supports and others do not need to however the same applications may need to interoperate moving content between them.
There are agreed standards, protocols and specifications that assure all these systems do interoperate. Standards are NOT Open Source, they are standards. This allows manufacturers the ability to build products and services that can be integrated seamlessly with each other to create a whole system. Once an application becomes open source, it introduces the danger of it being changed by a specific user for their use case, it potentially becomes no longer interoperable in any other user environment.
Even if the user reposts their version of the open source application back to the originating site to make it available to others, there are no guarantees it will work for anyone else. Also, once an application moves into the open source community, testing and validation becomes an unknown.
Interoperability is one of the core design considerations in EVERY design requirement and specification of a broadcast facility. Even the smallest production relies on interoperability.
Open Source enables full customization of an application or an API to suit the needs of a single user. While there are some benefits to this, custom is still custom. When updates or upgrades are released they are released for the original application not any modified version. Maintenance includes software version control and non-disruptive updates and upgrades. In the software connected environment, it’s important to remember that applications communicate with each other, so updating or upgrading one application could significantly impact its communication with the ones connected to it. That’s where interoperability becomes important.
Open Source is freely accessible source code, interoperable is how things interact. They are not interchangeable!
You might also like...
IP Security For Broadcasters: Part 1 - Psychology Of Security
As engineers and technologists, it’s easy to become bogged down in the technical solutions that maintain high levels of computer security, but the first port of call in designing any secure system should be to consider the user and t…
Demands On Production With HDR & WCG
The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.
If It Ain’t Broke Still Fix It: Part 2 - Security
The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.
Standards: Part 21 - The MPEG, AES & Other Containers
Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.
NDI For Broadcast: Part 3 – Bridging The Gap
This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…