Each media file specification has a massive number of configuration combinations. And combined with the complex software clients demand, testing each combination and variation of media file, software version and hardware platform can take an impossible amount of time. Therefore, vendors have been known to restrict their testing to more common types, resulting in the occasional bug creeping in. The alternative is having no software released at all resulting in the believe that some bugs should be accepted as a small price to pay for more feature rich code.

Keep Big Clients Happy

It’s entirely possible that a bug in a software release will only affect a small portion of the vendors client base, maybe as low as one or two clients. Although it may be unpopular to suggest, keeping the larger client base happy is the key to profitable business.

Automated code testing has helped in recent years to reduce bugs as the highly repetitive tasks required to catch the bugs can be processed by another computer. Testing can take place during development instead of waiting until a feature design has been released.

Keep up with Latest Formats and Trends

Open source code has muddied the waters further as users have the perception that the software is free to use, which it is with certain caveats, such as you must make the source code available including your changes to other users, but it still requires developers to maintain the code, especially as new file formats are still being released.

A broadcast vendor selling software will soon have problems with their client base if they do not keep up with the latest file formats and the latest trends. They constantly need to upgrade their designs and fix bugs along the way.

If the software maintenance model was turned on its head and broadcasters successfully argued they should not pay for bug fixes, then we could find ourselves in the position where vendors no longer fixed bugs or fixed them very slowly, giving us the worst of all worlds.

More New Standards

Yes, you could argue that the product should not have bugs and you may even be right. But sometimes it’s very difficult to prove whether a bug is in the vendors software or is a side effect of the broadcasters installation, or even caused by data being sent by other systems.

Furthermore, we are working in a highly accelerated industry with new standards being released with incredible frequency, especially as we transition to IP.

Software as a Service (SaaS) solves the software maintenance issue beautifully. Broadcasters never download or install the SaaS service code, instead they receive HTML pages with the results of computations from the SaaS server.

One Release for All

SaaS software tends to be one release, a generic software application for all users. The key to the design is to use configuration to enable and disable features on a client by client, and user by user basis. Each user account is configured, usually with a database, to enable features they have paid for or signed up to. The big advantage of this is that the vendor only supports one application with one compilation so they don’t have to support many different code versions.

Using the subscription model, SaaS providers sell access to their service, generally on a pay as you go basis, instead of selling and distributing code. Cloud servers run behind web interfaces to provide certain tasks, such as transcoding or standards conversion. Subscribers upload their media files to the servers, they are transcoded and sent back to the user. A further advantage to the vendor is that they never need to send code to the user, thus reducing distribution costs and risk.

Hardware Compatibility

For all the reasons mentioned, it’s inevitable that bugs will occur, and as they do, the SaaS provider will fix big issues immediately to deliver more reliable code. The advantage of running one version of code with the subscription system from a user’s point of view, is that if a bug occurs it affects all users, and if it’s a really big bug then the vendor could lose many clients quickly, thus improving their motivation to get it right and keep it that way.

Also, the servers running the software are updated by the development teams so the clients do not have to download the modified code or update their systems, thus further reducing the risk of incompatibility issues with their hardware and operating systems.

Point of Demarcation Moves to the Camera

As the industry transitions to IP and the point of demarcation moves closer to the camera, more features traditionally serviced by hardware will be moving to the Cloud. The value of SaaS is in it’s reliability and versatility.

Vendors will still be selling specific software applications but their support and maintenance complexity will eventually make them obsolete. To incentivize vendors to support stand-alone software, broadcasters must accept the maintenance contract business model.  Otherwise they may find themselves with obsolete software sooner than they expected.

Editor note:

Tony Orme has written a series of tutorial articles on moving to IP centric software and hardware infrastructures. To learn more about migrating to this new platform, type "Tony Orme" in the search box on The Broadcast Bridge home page. You will be provided a list of his articles and links to each of them.