So you think writing a Set-Top-Box Middleware is easy? Think again!

So you came across this technology called Digital TV and stumbled across the various (open) standards (MPEG, DVB, MHP, etc) and thought it cool for you to write your own software stack? Or you've been writing Set Top Box Software for other customers (namely PayTV operators) and decided you have enough knowledge to venture out on your own and sell your own software stack? Or you're a

PayTV operator, sick and tired of being locked into expensive and time-consuming Middleware vendors that you decide it is time to write your own software stack, be in control of your destiny and deliver cool products to market faster, cheaper and on-time?
Or you figured there is a quick and easy way of making some money, since just about every country in the world is going to switch off analog TV and turn to digital, where you can provide a very cheap and cost-effective software stack?

If you've answered yes to at least one of these questions, then you should be asking yourself: Just how serious are you about Middleware?  Just how serious are you about the EPG User Experience?

Just how serious are you about competing in this marketplace? Is there any room for you to compete in this arena? Where  do you see your software stack in the marketplace: low-tier, middle-tier or top tier? Who are your competitors? Are you big enough, flexible-enough, savvy-enough, innovative-enough or unique-enough to displace your competitors? Or do you even wish to displace your competitors? What relationships do you have with the big technology players? What is the compelling value proposition that you're offering that your competitor's aren't? Do you stick to one large customer that can finance your operation? Do you seek out other customers to monetize on your product's offering? Do you keep a common product that can service multiple customers at relatively low cost? Do you feel the market is big enough to support many divergent offerings? Are you a small fish in a small pond, big fish in a small pond, or are you swimming with the sharks and you just don't know it yet? Do you rely on hope that everything goes well, or have mountains of cash so as not to notice you're burning fast, but don't realise it? Have you been sold vaporware, demoware, software that's far from being fit-for-purpose for real world mass production use?? Etc, Etc, Etc...

I have met developers, architects, software managers and product owners who think that writing a STB Middleware stack is easy, a piece of cake, all you need is just four really good developers...to which I smile and think in my mind, oh how naive they are! Yes, for sure, the software architecture can make sense on paper, heck you can even hack a proof-of-concept together in about three months or less that proves a simple Zapper or PVR stack. But that's just it, it's a hack, a Proof-of-Concept (POC) - nothing close to getting a real world product into the marketplace.

My rambling in this post covers the following:

• Typical Challenges for New Middleware Players
• Securing support from Chipset Vendors
• Choosing the Application / Interactive Engine / API for EPG
• Integrating with Conditional Access Vendors
• Competitive Costing / Pricing Model
• Overall Middleware Strategy
• Advice for PayTV Operators
• Conclusions - Middleware/EPG business is hard work
• Last Point: If I entered the Middleware/EPG Market today, what would I do?

Diving into STB software design, architecture and implementation is pretty much an art, requires significant investment in time and resources, and quite an intense management overhead in building the product roadmap in winning new customers, as well as, significant relationship management with third-party, dependent suppliers. It is the result of significant effort, a journey, one in which there'll be many challenges along the way, failures & some successes...

So suppose you did get it right - you started with a small team of four developers, developed a relationship with a chipset vendor like Broadcom or ST, and landed yourself two big customers. Customer A is really a low-tier Operator, focused on the mass market of cheap STBs, who's main product line is an entry level Zapper, it expects a fully packaged system, this Operator is not interested in taking technical ownership. Customer A takes what you give them, any new feature is expected at low cost or for free. Customer B, on the other hand, is operating at the opposite end of the scale, a tier-one customer, already entrenched in the marketplace as a dominant leader. Customer B wants to innovate, build and extend on its PVR offering, entering the world of connectivity and hybrid STBs, is in full control of the technical value chain, and wants to be really involved in shaping the direction and evolution of the software stack. Customer B has aggressive timelines, and doesn't want to be impacted by other unnecessary, useless features from Customer A. Customer B also doesn't want its timelines to be impacted by you having to support Customer A. Customer B expects open interfaces to your software stack such that Customer B can develop its own EPG application, thus breaking away from your one-complete-shop offering, i.e. your packaged EPG application is not acceptable. Added to this constraint, customer B decides to also enter the mass market, low-tier market, and is also willing to run with your full package only for low-tier markets. But one of the overriding strategies for Customer B is to harmonise the feature set across all tiers, as well as unifying much of the user experience across all platforms.

This is not an unusual situation to be in for a Middleware Vendor...

Typical Challenges for New Middleware Players

Referring back to the classic layered architecture of the traditional STB Software stack, in my view, based on my experience of playing in this space for over a decade, the core challenges new Middleware vendors face are the following:

• Securing support from Chipset Vendors 
• The architecture of the low-level OS / Driver Abstraction Layer (HAL = Hardware Abstraction Layer VS CDI = Common Driver Interface VS HDI = Hardware Driver Interface VS HPK = Hardware Porting Kit, etc.)
• First of all, there is no Open Standard for the Device/Driver interface
• Traditional Middleware vendors would have defined a closed API for managing device drivers and Operating System interfaces
• The big players in this market are NDS MediaHighway & OpenTV
• MediaHighway started first with a traditional abstraction layer called HDI, which is basically your standard C-function-interface to low-level drivers
• OpenTV had something similar called the HPK - which also provided a C-interface to higher level functions (Function calls, with function pointer hooks into the Middleware)
• These two big players later evolved their Middleware and Driver interfaces to adopt the Linux / Posix interfaces - which is more generic, flexible and relatively open to porting and extending the software stack, making it more amenable to leveraging and re-using, standard off-the-shelf open source components
• In my opinion, the traditional HAL C-function-like API is dead - the move to a more Open, Linux-based driver model is the way to go
• Chipset vendors have been in bed with these big players for many years, and are in reality loyal supporters, and sometimes followers and promoters of their techology / architecture
• Chipset vendors want to sell millions and millions of chips - this is their core business. The heavyweight Middleware vendors can guarantee Chipset Vendors return on investment
• If you're a new Middleware Vendor and you come offering, im your view, a brand new Driver Interface, which is in reality, at odds with what the big players are offering, you will face resistance and support from Chipset Vendors, unless you've secured a major customer that's guaranteed to roll-out hundreds of thousands, if not millions, of the underlying chipset
• But overtime, you will start to lose support from Chipset vendors as they would see the market as being rather small, they have to support a codebase which is at odds to their own current development processes, or their roadmap indeed
• Chipset vendors are also now wanting a piece of the Middleware Pie
• Because they've been involved supporting the major Middleware Vendors, Chipset vendors are in a position to understand the best of all technologies
• Generally a chipset vendor would abstract away their driver & OS code such that it, in itself is an internal product, that is really shared between various competing Middlewares
• For example: Broadcom's chipsets are found in a variety of platforms around the world, often using different Middleware - but the underlying software driver stack is essentially re-used by Broadcom, and ported or adapted for the different systems
• So Broadcom are now saying they can offer their own middleware stack, that is built upon their common driver codebase, pretty much bypassing the traditional Middleware Vendor
• The same trend can be seen by ST 
• Similarly with other STB manufacturers like Pace - are also offering their own Middleware
• So a newcomer in the Middleware business has to impress upon:
• Uniqueness and technical strength of the architectural offering
•  A compelling business model for revenue generation
• Cementing support and relationship with Chipset Vendors/STB Manufacturers who are immediate potential competitors

• Choosing the Application / Interactive Engine / API for EPG Integration
• So you wrote the engine of this Middleware that parses the MPEG/DVB broadcast stream, presents Audio/Video, parses all the service & event information; and supports a usable graphics engine. You now want to demonstrate this cool middleware by showcasing the classic EPG application. So you write your very own EPG - still very technical, and your engineers have no clue about usability or user experience, but do the best they can with the resources available. It turns out your demo application looks pretty decent though, but in the rush to get to market, your engineers bypass architecture guidelines, and pretty much entangle the core middleware code with application code (this scenario deserves a post in its own right)
• Providing a demo application or sample Application APIs is just the beginning
• Your strategy must consider whether your middleware stops at just the Application API level, or include as part of the package, EPG Applications
• If EPG Applications is part of the package, then you need to have a strategy for application APIs
• Strategy for Application APIs are typically: C-API (dying out slowly), Java (50/50), Flash / Actionscript (Gaining traction) and HTML5 (new kid on the block)
• Your strategy also calls for what options you have for supporting multiple customers. You want to sell your software stack to as many broadcasters as possible, yet at the same time, maintain a common product codebase, without forking out branches or separate codebases per customer
• You also will be faced with the challenges that broadcasters like to create their own branding and user experience, re-using your software stack, yet have flexibility to tailor and profile the user interface and user experience as they see fit
• You as a small outfit, need to figure out a way to support this need from customers, maintain your product codebase yet at the same time offer this flexibility to broadcasters
• You also need to consider having a strong graphics or creative artists team that specialise in user experience and usability, because frankly, engineers don't make the best creative artists!
• Agree on your target audience: Do you offer a one-size -fits all interface: cross-platform, any device experience?
• Do you offer traditional, out-date interactive application experiences built on traditional DVB DSMCC or do you offer a more modern integration interface, popular App Store experiences?
• Do you offer a state-of-the-art, fully managed service of API support such as an Application SDK that allows independent application vendors to write and deliver applications on top of your platform?

• Integrating with Conditional Access Vendors
• Writing a free-to-air middleware system stack is a pretty straightforward affair. I have first-hand experience in coding a middleware stack from scratch, from zero to zapper in about four months, was demo'ed at IBC as well.
• Traditionally the real core and value of a STB stack is integrating with the CA system - the CA protects content and is ultimately responsible for generating huge revenues for PayTV operators.
• If you want to enter the Middleware game, you must integrate with a CA vendor
• CA Vendors have their own requirements for integrating with third-party stacks, often subjecting Middleware vendors to various security requirements, including audits as well as requiring certification tests
• CA Vendors also have their own low-level device integration requirements, which means that your low-level hardware abstraction model must be compatible or easily integrated with that of the CA vendor
• PayTV Operators are ultimately responsible for choosing the CA vendor, this usually comes first, then the choice of a Middleware/EPG provider is considered. Usually, CA vendors offer a one-stop-shop, fully integrated, end-to-end system, operators need not shop anywhere else: this is what most newcomers to Middleware market will have to contend with - you must provide a compelling reason for an Operator to choose you.
• Some Operators are concerned about keeping all their eggs in one basket, look for a more federated model, embracing openness - choosing a CA vendor, separate Middleware and separate EPG vendor. This means more vendors to manage, and has an overhead on integration
• As a new Middleware player, you need to invest significant time in not only the technology integration, but also relationship management with CA vendors - this is a costly affair that you must budget for.

• Competitive Costing / Pricing Model 
• The royalty model for new players might seem enticing at first, one dollar per STB per month, with at least five hundred thousand subscribers, this makes for a pretty decent revenue stream indeed
• But over the years, this market has become quite competitive, charging a dollar per subscriber may longer be possible, but in depends on the technology offering & value proposition
• Newcomers have to come in low to undercut existing entrenched vendors
• PayTV Operators themselves are becoming increasingly self-sufficient, relying on in-house development more and more. It is entirely plausible for a PayTV Operator to setup its own development house, own its own Middleware & EPG code - it's far more cost effective to have a team of 20 Engineers on your payroll than to pay Middleware premiums to vendors
• A lot of the software in Middleware/EPG stacks can be acquired through free and open source software - so the question is why should people pay for this?

• Overall Middleware Strategy
• Ability to Deliver Basic Features to Market in short time
• Ability to Deliver Enhanced Features to Market - Reuse Open Source or Create your Own?
• Ability to provide Effective Customer Support
• During early stages of development & integration the Middleware Vendor could get away with offering limited support or remote support
• TV Operators, the primary customer, prefer a stronger presence onsite, especially if you, as a vendor are geographically isolated from the local footprint
• On-site support during final stages of testing and deployment is almost mandatory and is a well established practice in large PayTV operators, it is almost expected as a natural part of the project's contract, unquestionable. If you have a very small complement of people, you need to rethink that strategy because one way on another, you will not be able to not provide onsite presence as and when the customer requires it
• It is also expected that the vendor has the ability to turnaround fixes to issues on-site, instead of sending the problem report to the report team located off-shore - this has inherent inefficiencies that from a broadcaster point-of-view is a time waster
• Once the product is deployed live, there is an expectation for ongoing future support, on-site. It is usually during the post-launch phase, that generates serious problem reports because the product is exposed to a massive user-base which is in order of magnitudes larger than the test group, i.e. field trials
• So a Middleware/Application vendor must be prepared to complement the R&D team with an Operations/On-site support arm that will most likely be permanent, embedded in the PayTV operator's premises - so your ability to scale your team must be planned for in advance.
• As part of your overall support strategy, you will have to support delivering new features built on top of an already deployed codebase, at the same time, manage new feature enhancements or architecture refactoring on a separate codebase
• Once a product is deployed, the customer is generally reluctant to make the next big platform/Middleware upgrade until sufficient time has been seeded in the market to stabilise that deployed build. So as a customer, I would remain bullish not to accept serious changes to my deployed system, and will maintain my right to incremental new feature development on that platform. I will only upgrade to the next major release of Middleware if I really have to, and if there are compelling, killer new features that I need to have.
• So as a Middleware provider, you need to take pain to ensure your customer understands, buys in, and supports your product management philosophy and roadmap - do not assume that what's best for you as a MW provider is best also for the customer.
• Solid Product Management Strategy
• If you've landed a client, willing to go with your software stack for either Middleware or EPG, then you're in a race against time to deliver to market quickly
• Depending on the market & competition the distinction between Basic and Advanced features must be understood. Some competitors might consider advanced features as basic, due to their product being more mature and entrenched in the market for a long time - if this is the case, there will be some quick catching up to do
• Your delivery of a solid product (basic or advanced) to market in a short time will be a measure of your success in the game. 
• Many customers have been sold smoke-and-mirrors, only to find out the product marketed was really far from complete, and had months of stabilisation & integration required, turning a 6 month project into a 24 months one
• You must have thought carefully about your product management strategy
• Start with a small team and scale aggressively to cope with the demands of customers?
• Share a common core product team (and codebase) across multiple customer delivery teams?
• Ability to support the many requirements for managing the product:
• Keep existing customers happy - maintain and enhance legacy code to support the current customers (number one priority)
• Work on enhanced features on existing codebase - to secure new projects with existing customers
• Work of really innovative, possibly disruptive technologies - to catch the next big customer, possible Tier-1 PayTV Operator
• Reduce maintenance costs of having to support more than one customer
• Deciding on the end-of-life of first generation products
• Creating a migration path for customers to move to next generation products
• Ability to deliver features is short time frame
• Agile / Iterative or Lean approach to product development
• Extent of re-use of common off-the-shelf components
• Extent of partnering with third-party suppliers to complement your offering
• Extent of being open and transparent with your customers or third-party integration vendors - i.e. do you share your code?
• Amount of Intellectual Property that is unique to your offering that's patentable
• Do you licence your technology modules or own the entire stack

Advice for PayTV Operators

As mentioned earlier, there's an increase in interest from PayTV operators to be more involved with the technology architecture, design & implementation of the Middleware / EPG Application software that powers their set top boxes. It usually starts with PayTV Operator's expectation of shared source code, Middleware/App vendor is contracted to share the source code with the customer (PayTV Operator). It gradually moves on to the customer developing in-house technical skills (often headhunting engineers / architects from their software vendor), building up familiarity with the software stack, to a point where the customer can steer technical design decisions. With growing confidence in themselves, the customer decides to take the leap and do application EPG development in-house. After a couple years, the customer then decides their technical team is competent-enough to take on the full Middleware development. 

Deciding to own Middleware development in-house is subject to a variety of factors, usually around:

• Time-to-Market: Strong Middleware vendors have more than one customer, some PayTV operators might be overshadowed by other Tier 1 operators, their projects take priority, vendor can't scale teams up or feel inclined to support urgent resource ramp-up requests for smaller clients
• Competitor insecurities: PayTV Operators don't like sharing vendors too much, and suffer from delusions of insecurity
• Belief it can be done in-house: Depending on the strength of their technical team, and the level of influence the techies have on overall business decisions, some operators are persuaded to move the development in-house. This is usually down to:
• Uncomfortable or strained relationships between the two technical teams (Vendor & Customer)
• Customer's tech team have a "Not invented here" syndrome, would like to do "we can do it ourselves, it is really easy. We done the EPG, how hard can a middleware be?"
• Vendor pricing wars: Some vendors are just too expensive, PayTV operators need to consider alternative business models to justify investment in future product development enhancements
• More control - some operators feel that the entire value chain is under the broadcasters control, therefore they can implement bespoke solutions to match their specific needs, instead of using some generic software built on open protocols
• Time-to-Innovate is too slow - operators rely on middleware vendors to drive the technology roadmap. Some middleware vendors are so locked in to customer deliveries that they're really not future looking at all. This tends to frustrate some Operators who tend to look for alternate ways of innovating - like doing advance R&D in-house, use of open source tools, etc. And in doing so, this operator realises that "hey, middleware development ain't so bad!" 

So my advice: Think long and hard about your business case before delving into in-house middleware development. And read up on the next sections on my view.

Look, it is not impossible to go out on your own. I worked with DirecTV who first had some other middleware, then we replaced it with our own middleware (NDS MediaHighway), and later on, DirecTV decided to switch back to an in-house, Linux-based Middleware, only keeping the Common Driver Interface (Licenced from NDS Mediahighway) and their Interactive Applications Engine (HTML, Javascript / Flash engines) - the core services middleware, or shall we say, business logic is owned by DirecTV. The ancillary services and core driver foundation, is still sourced from a Middleware vendor. It is really hard to move everything in-house, it goes back to leveraging on economies of scale (The NDS CDI driver interface is well-known, ported across 50+ platforms/chipsets, and has the respect of all chipset vendors - why should DirecTV reinvent the wheel here??)

When I worked with BSkyB on their latest Sky+ Anytime HD/VOD set top box, we had replaced OpenTV with NDS MediaHighway - complete replacement. BSkyB had full access to the source code, entire stack - but it became overwhelming for them. Instead, BSkyB focuses on core Application Development, their EPG team was started from scratch and came of age in five years (this was just a Java EPG, imagine the time it would take to own a Middleware technology). System Integration is mixture of in-house and outsourced. BSkyB, whilst they can take the code and fork it to do other features, would rather leverage of all new middleware features from other operators that they would get for free, otherwise they'd had to fund the development themselves.

Set-Top-Box Middleware development, in-house, by a PayTV operator is more likely to fail a few times before getting it right. You should be prepared to be set back at least two years before your middleware team become fully productive (depends of course on how advanced the features are). Remember the saying "Measure twice, cut once" - you really need to measure thrice, cut once ;-)

Conclusions - Middleware/EPG business is hard work

Every newcomer to the Middleware business must first understand what other vendors have done in this area, use their successes and failures as learning experiences; take the time to understand where you fit into the world of Middleware market share - how big a chunk do you want to take? The bigger the chunk, the more money, time, resources and energy you will require...

The newcomer to the Middleware/EPG business will have to contend with the big players in the marketplace already, if the newcomer's strategy is to operate or disrupt the market that is already stable / entrenched. Tier-1 Operators (these are operators in the developed world, with a mature market and technology operations, with at least five million subscribers) will take a long time to notice newcomers. 

Tier-2 & Tier-3 Operators, don't have enough cash flows compared to Tier-1 operators, with a focus on keeping costs down, will more likely be more open to newcomers, often themselves sending out RFPs (Request for Proposals) to aid in making their decisions for some technological areas. At the same time, these very Operators would like to innovate, supporting a mix of subscribers (low-income, low use to high-income, advanced users); and would thus like to see an aggressive roadmap from their technology vendors.

Compare with say, the beast that is MediaHighway Middleware - where I worked in product management for a few years:

• Solid and flexible architecture: Can support varying profile of features from Zapper, PVR, Home Gateway, Home Networking Hub - off the same software stack
• Profile-based approach off a common stack worked across the system: Platform device drivers, Middleware & Application - could be tailored, i.e. to support almost any configuration
• Architecture supported lowest common denominator STBs from Zappers onwards, without having to have different versions of code running on different platforms
• With the click of a button, one can generate any build configuration, e.g.:
• Simple SD Zapper with one Tuner
• HD Zapper with two tuners, one primary tuner, one dead (for future PVR use)
• HD PVR with two tuners but no hard disk, a.k.a. Diskless PVR
• HD PVR with USB Support
• Home Gateway Server with 8 tuner support with home networking with local disk
• Home Gateway Server with 8 tuner support with home networking with Network disk
• Gateway client Zapper with PVR support
• Client Zapper without PVR (basic zapper)
• Hybrid-IP box with two tuners, IP plus a third Terrestrial Tuner
• Multiple EPG Applications supported: C / Java / Flash / HTML5
• Ability to release major product versions frequently
• 1000+ Worldwide development team involved
• Ability to scale and deliver on a variety of technology profiles 
• Hundreds of man-years experience in Middleware/EPG
• Hundreds of IP/Patents in the field
• Products have evolved over two decades, using best-of-breed approaches learnt from hard-won experiences
• Basic out-of-the-box product features, that newcomers might only consider advanced:
• Zapper is really not a selling point of any Middleware/EPG - it's really not a feature
• Basic PVR: At least two simultaneous records, Save from Review Buffer, Advanced Conflict Management, IP-VOD, Push-VOD, Pay-per-View, 14-day TV Guide, Interactivity, Application Store, Remote booking of Recording, Shared Planner, Remote Planner, Remote Diagnostics & Health Check
• Advanced PVR: Home networking Client/Server, Multiple clients, Content sharing across devices, Second screen, sideloading
• Other features we worked on in 2010, 3 years ago: Advanced 3D signalling, 3D Graphics, OpenGL ES Integration, Power-Saving, Green STB, Text-to-Speech, Targeted Advertising, 3D EPG, Advanced Search & Recommendations, etc.

[For more background reading on my experiences with the MediaHighway Middleware Product, start here].

But newcomers shouldn't be disheartened by established behemoths like MediaHighway. There are indeed smaller markets out there that the big players are really just not interested in. With smaller markets, newcomers have a level playing field, but as I highlighted earlier - it's about having perspective on where your strategy lies, and most importantly your ability to deliver solid solutions (fit-for-purpose products) in record time.

Last Point: If I entered the Middleware/EPG Market today, what would I do? 

If I had a Middleware/EPG software stack on offer, I would forego the whole royalty-based revenue approach and would tend to lean on the services offering. I see this technology as just an enabling technology. I would offer one-on-one, focused support and integration services to Operators, offering them the complete software stack source code - they can own it. I see it as a partnership, a collaboration where we can work together to enhance the product and ultimately deliver value both ways. I will still maintain ownership of the work product, free to take it on to whichever market I see fit, the customers free to do what they want with the stack afterwards. I would promote Operators maintaining their own software team (depending on how big the Operator is), to take ownership of the entire STB stack at a stage when they're ready to do so.

I would also leverage Free and Open Source Software (FOSS) as much as I can because it just does not make sense to reinvent the wheel today. By FOSS, I don't mean re-using Android! Android STBs seems to be all the rage these days, but if you've already invested time and energy into a fairly mature software stack already, instead of throwing it away for Android, think again - instead, look at ways to provide a bridge between Android and your stack. Android, really, is not the solution to all of STB problems today.

If certain technologies are not open, I would also consider partnering with companies that offer the solution already, rather than me investing time, money and energy in recreating an existing technology and having to play catch-up all the time. I will find my niche, area of expertise within the domain of my stack, and improve on the service offering there. Building a network of established partners promotes trust and openness...

I would also partner with the PayTV Operators to take them with me, or be part of their own journey, in the road to innovating and deciding on the next wave of new initiatives that may be disruptive or take the industry in completely new directions.

In essence though, I think the packaged software solutions is dying a slow death, in favour of more open, collaborative & participative service-based relationships...

I would also help & work with PayTV Operators to create a platform that is more in keeping with today's modern technology innovations, the old traditional models of Middleware/EPG is dying - you need a new model for Interactive PayTV. My system will be an open platform that enables and embraces third-party application development, whilst simultaneously preserving the revenue-content-protection model that is really the crown-jewels of the PayTV Operator - everything else is secondary. PayTV operators should provide just the platform, leave all the cool, interactive applications & new user experiences to the wider developer community...