Set-Top-Box (STB) software stacks have come a long way since its inception back in the early 1990s, with custom & bespoke software vendors providing proprietary components for most of the STB software-stack. Still today, most of the higher level STB components are still indeed proprietary - for example, the likes of Middleware providers (NDS, OpenTV, Irdeto, DirecTV, EchoStar, etc.) are still pretty much closed, but the game-changer was really the advent of the Linux Kernel, and especially its foray into the embedded space, when it really started to take off and start gaining critical mass from early 2003 in Set-Top-Box stacks (if I recall correctly). And more recently, and this is something that I'd forewarned my previous company (NDS) about, was the advent of the Android stack, way back in 2007 when I first downloaded the Beta Android Core SDK and saw immediately the similarities of this stack vis-a-vis set-top-box middleware software stacks, and lo and behold, Android STBs were seen in early 2009/2010; and are already becoming the mainstream choice for quick-and-easy, low-cost-to-market projects.
I am not sure how many STBs (apart from legacy) are still using the likes of uCos, vxWorks, Nucleus, ST OS/20, etc.(I had at a previous life worked on all these OSes), but nowadays, the OS of choice is definitely a variant of the Linux Kernel, available for free! A Linux system opens up the world to so much more: in terms of utilities, components & application engines, almost any type of functionality that exists on the PC/Systems world, is just a port away from the embedded device world.
PayTV Operators and Middleware System vendors alike, would spend months to years, re-inventing the wheel for functionality & features that are readily available in the PC world. Before Linux, these vendors would literally re-create software components from scratch: Compression engines, Point-to-Point Protocol, TCP/IP stack, HTML engines, UPnP stack, etc, etc. Time-to-market is much shorter than before, proof-of-concepts can be also be done in record time. In past projects I've seen teams use free, off-the-shelf components, to name a few: libupnp, pppd, httpd, dhcp, libcurl, xbmc, ffmpeg, webkit, directFB & gstreamer to do some impressive demos. I myself, have personally used other open source software like the Festival Speech Engine to bring real-time Text-To-Speech to set-top-boxes.
I attended a session recently where Broadcom's (BCM) STB team presented their chipset roadmap & demonstrated their Trellis Software Framework, built on open source. It's really interesting to see that BCM is quite well established in the Open Source community, using as well as reciprocating. Their proposals on using an open interface really defies the old ways of traditional Middleware stacks is really an interesting (most likely disruptive) thread worth keeping an eye on...
I attended a session recently where Broadcom's (BCM) STB team presented their chipset roadmap & demonstrated their Trellis Software Framework, built on open source. It's really interesting to see that BCM is quite well established in the Open Source community, using as well as reciprocating. Their proposals on using an open interface really defies the old ways of traditional Middleware stacks is really an interesting (most likely disruptive) thread worth keeping an eye on...
However, using Free & Open Source Software (FOSS) in the context of PayTV products such as digital consumer devices like Set-Top-Boxes, does not come cheaply. If due diligence is not applied carefully in managing the open source components such that there is a clear split between proprietary code and open source code, especially in respecting the various licence obligations thereof, then problems will abound - and it can be extremely expensive, possibly detrimental on the part of the PayTV Operator and dependent software vendors. Generally the PayTV Operator will implement strict policies and processes such that the responsibility of conforming to Open Source Licence obligations is passed on to the actual Software Vendors themselves.
Take for example BSkyB in the UK. The last incarnation of their Sky+ Anytime HDPVR that was powered by a software stack of which I worked as Development Owner/Technical Project Manager, had to respect FOSS rules quite stringently. Sky have a website dedicated to explaining the use of open source software. DirecTV also have something similar in their T&Cs site. Sky also have provided detailed screens that discloses all the free software contained in their STB platform (Note: the below picture was taken from an old user interface dating back to 2010, this could've changed in their latest UI launched recently):
 |
| Sky+ HDPVR Open Source Usage Declaration (Example-only, photo from 2010, not an endorsement of Sky) |
PayTV Operators & Software Component vendors alike, must become familiar with the implications & legal obligations of using FOSS. Chances are, if you're using the latest incarnation of a modern Middleware release post the year 2007, then you probably are using some FOSS components already, maybe not directly in the STB image itself, but still very good chance that all peripheral build/development tools are using some FOSS. So if you don't already have a FOSS policy in place, then you should seriously reconsider your strategy!
If you want a brief overview of the key areas to consider for FOSS compliance, read this post here. The Linux Foundation have been a valuable support point in our experience, as well as the likes of commercial outfits like BlackDuck.
I've experienced both worlds compliance obligations: As a Middleware Software vendor we had to take strict measures to keep the codebase cleanly separated, proprietary code isolated from FOSS code. We also had to clearly publish what components were in use, the associated licences, clarifying with the legal team what the risk & impact is on the customer, the PayTV Operator. We had to maintain a roadmap of FOSS components, and run FOSS scans using BlackDuck on every major release of software. We created a special team to focus on FOSS, including strict architectural review & approval of new components into the system. Component owners & technical leads took ownership for the overall maintenance & life-cycle of their usage of FOSS components.
As a PayTV Operator, the main driver is to avoid legal prosecution by the Open Source community. I am a firm believer and supporter of FOSS, if commercial entities are using FOSS, it is only fair and right to disclose its use. Not only must the PayTV Operator take reasonable steps at disclosure, it also needs to enforce a policy of review by its vendors. Usually the Operator moves all responsibility to its respective component vendors, as I described above. In terms of cost, most of the cost is on the vendors since the vendors own the code. However, as the PayTV Operator owns the overall product that reaches the end-consumer, therein lies the responsibility of the Operator to communicate the disclosure, for example as Sky & other operators have done. This is not uncommon in the mobile device world, Smartphones & Tablets all have a disclosure screen usually in the "Settings/About" menus that inform the consumer of what FOSS components have been used...
For an overview of what you need to do for FOSS, please refer to this white paper - contributed by a friend & colleague, who is currently acts FOSS-compliance champion...
If you want a brief overview of the key areas to consider for FOSS compliance, read this post here. The Linux Foundation have been a valuable support point in our experience, as well as the likes of commercial outfits like BlackDuck.
I've experienced both worlds compliance obligations: As a Middleware Software vendor we had to take strict measures to keep the codebase cleanly separated, proprietary code isolated from FOSS code. We also had to clearly publish what components were in use, the associated licences, clarifying with the legal team what the risk & impact is on the customer, the PayTV Operator. We had to maintain a roadmap of FOSS components, and run FOSS scans using BlackDuck on every major release of software. We created a special team to focus on FOSS, including strict architectural review & approval of new components into the system. Component owners & technical leads took ownership for the overall maintenance & life-cycle of their usage of FOSS components.
As a PayTV Operator, the main driver is to avoid legal prosecution by the Open Source community. I am a firm believer and supporter of FOSS, if commercial entities are using FOSS, it is only fair and right to disclose its use. Not only must the PayTV Operator take reasonable steps at disclosure, it also needs to enforce a policy of review by its vendors. Usually the Operator moves all responsibility to its respective component vendors, as I described above. In terms of cost, most of the cost is on the vendors since the vendors own the code. However, as the PayTV Operator owns the overall product that reaches the end-consumer, therein lies the responsibility of the Operator to communicate the disclosure, for example as Sky & other operators have done. This is not uncommon in the mobile device world, Smartphones & Tablets all have a disclosure screen usually in the "Settings/About" menus that inform the consumer of what FOSS components have been used...
For an overview of what you need to do for FOSS, please refer to this white paper - contributed by a friend & colleague, who is currently acts FOSS-compliance champion...
No comments:
Post a Comment