open source

Software, Sandboxes, and the Back Office

Sandbox. Another everyday noun stepping out in different stripes, especially amongst Software People.

 

Here it is as a verb, from a recent batch of notes: “When you’re sandboxing, you’re allowing people to fail without killing anything.”

 

And as an adjective: “It’s more of a sandbox-y thing than a bag of tools.”

 

On the surface, the notion of a “software sandbox” is perhaps obvious. It’s a place where developers can try out their code, using the same raw resources as a production environment, but without causing anything in production to break.

 

Why the sandbox is of increasing importance in broadband technology circles is perhaps less obvious. To get the head around it, point toward open source software, as a staple in the transition to all-IP (Internet Protocol) everything.

 

Let’s say we all agree that a) it’s a software world anymore.  And that b) next-gen competitors who grew up on broadband just move faster. Lastly, that OTT competitors move faster, in part because they live on open source software, and make it easy for developers to try stuff out.

 

In other words, they sandbox.

 

Let’s further say we agree with the one about “if you can’t beat’em, join’em.”

 

So far, in the realm of what we used to call “cable,” most sandboxing happens at the interactions of “old” and “new,” also known as “now” and “next,” and especially with back office stuff. For instance, maybe you want to experiment with how people navigate video. One option: Build some kind of software-based emulator, so that developers can work within a semi-real environment.

 

Another option: Create a sandbox that links developers into the live elements of the back office that really do link to video navigation — the billing system, the conditional access/encryption components, the provisioning experience, as three of several examples. Developers can develop away, without damaging anything happening live, in the back office.

 

As for whether the software sandbox ever encounters gifts akin to what cats leave in sandboxes? In practice, developers usually get their own sandboxes, electronically cordoned off from anybody else writing code. Which is good, because there’s not any actual sand.

This column originally appeared in the Platforms section of Multichannel News.

 

 

What’s It All About, Linaro? (And What About You, Yocto?)

Amid the lingo of open source software is a new-ish entrant: The Linaro Foundation, which dropped an intersection with cable in the May 29 formation of the “Linaro Digital Home Group,” abbreviated “LHG.”

 

What’s it all about? On the surface, it’s a way for chip makers, set-top/gateway manufacturers and service providers to manage the complexities involved with moving from one type of silicon chip architecture (“MIPS”), to another (“ARM”).

 

In at the get-go are Cisco Systems, Comcast, and STMicroelectronics (all active members of the RDK [Reference Design Kit]), as well as Allwinner, ARM, Fujitsu, and HiSilicon.

 

Lots of moving parts here, starting with why the shift to ARM-based silicon in the first place. Answer: Lower power, higher speeds, smaller form factors. Mobile devices use ARM-based chips, for instance; in-home devices like set-tops and gateways are likely next.

 

And yes, MIPs v. ARM is a religious architectural debate — not unlike Microsoft v. Apple, in the operating system battles of yore, and Apple v. Android, in today’s techno-landscape. “Going ARM,” for companies accustomed to building MIPs-based silicon (like Broadcom Corp., as one example) usually starts with at least one outburst of “over my dead body!”

 

What Linaro brings, in general, is “the rest of the story,” from a Linux perspective. Building software products isn’t just writing code — there are points in time where an actual build is required. A “compile.” Important in the lingo of software builds are “active users” — how many people are throwing code into how many “build slaves” in which “build farms.”

 

Part of every software build involves the best way to ingest what is a usually a torrent of code chunks, coming from all over the place. Thousands of drops, daily. Linaro, in general, manages the Linux distribution of software components for ARM; LHG will extend that into cable-oriented devices.

 

But wait, there’s more! The Yocto Project, which generally comes up in Linaro conversations as the open source tools software developers use to participate.

 

In a nutshell: LHG aims to steer the industry further into open source software, and specifically the software related to ARM-based chips, so that the industry can build in-home gear that runs cooler, faster and smaller. Yocto provides the development tools to get there. Off we go…

 

This column originally appeared in the Platforms section of Multichannel News.

More Open Source Lingo (Hello, Fork!)

ATLANTA–As expected, the annual get-together of cable’s technical community steamrolled a fresh mound of terminology into the field of view.

This year’s batch, wafting up from the SCTE Cable-Tec Expo two weeks ago, seemed less about tongue-twisting gibberish, and more about lingo swapping  —  particularly as it relates to the Wild West that is “open source” everything.

Here’s an example. “Intellectual Property leakage.” Abbreviated, IP leakage. Important: If life gives you cause to say it, do not say aloud the abbreviated version. Learn from those of us who fell prey to this linguistic trap, too many times – it’s but a variation of “it seems like IP everywhere!”

Intellectual property leakage is another early reason why cable technologists used to avoid dabbling in the open source software common to The Big Internet. Open source stipulates a “votes with code” mindset — participants contribute their efforts into a big, open repository, for anyone else to dip into.

This was seen as particularly risky when it came to set-top boxes, which contain things just too sensitive to be open. Like how encrypted signals are decrypted, for instance. Or how they tie fairly directly into things like billing data.

That all changed with the RDK – the Reference Design Kit. As was confirmed by panelists on an “RDK in Action” panel during Expo, RDK is the cable industry’s first real example of open source inside the set-tops and gateways cable operators buy to lease to consumers.

Concerns about being infected by the stuff of The Big Internet, coupled with the worries of Intellectual Property leakage, are why RDK is technically considered “shared source.” The difference between “open source” and “shared source,” very simply? The license. RDK community members gain access to the source code repository by signing a (zero dollar) license.

Then there’s the fork. Forks matter greatly in open source/shared source communities. This is more “fork in the road” than “put a fork in it,” although generally speaking, forks are bad. They happen when an open source effort decides to take a different technological course. Then, everyone who uses that code must decide: Take the fork, or stay on the original course?

This happened in September with one of the core components in the RDK stack – the web engine – which forked to a Google-built effort called “Blink.” Experts at the RDK panel at SCTE marked the development as “no biggie,” explaining that a tenet of RDK is to stay at the tip of the developments in the open source elements it selected. In other words, if Blink is deemed better, then so it shall be.

Bottom line: Cable going open source in its leased electronics is a new way of thinking about how it sources equipment. It’s part of the overall transition of the cable operator as an integrator, to the cable operator as an innovator, to quote Time Warner Cable SVP/technology Matt Zelesko, who added: “This is a key trend. It’s really important.”

 

Duly noted.

On Opening Up to “Open Source”

It wasn’t that long ago – two years, maybe three – that the term “open source,” to industries like cable, which operate giant, two-way networks, was dismissed as too risky. Guaranteed to introduce malware and other kinds of security hazards.

It just wasn’t a wise idea, the thinking went, to usher the techniques of The Big Internet into professionally managed networks.

That’s all changed. It changed quickly and pervasively, such that even those of us who make it a habit to track the technologies of this industry find ourselves thinking, “I saw the whole thing. What happened?”

Open source. Open stack. Open flow. Open this, open that. Open is good; proprietary is bad. That’s the trajectory.

Before we start breaking this down: Our apologies to those readers who’ve maneuvered the software jargon jungle long before the rest of us. You know who you are. Hunch: You’re a smaller percentage of the readership of this magazine than the rest of us.

What happened? It’s all part of the unstoppable flow of technologies, networks, services and people toward “all IP,” where the “IP” stands for “Internet Protocol.” As it is, the industry’s broadband networks are becoming “virtualized” – broken apart into individual chunks, or modules, of activity. At the same time, competition from all sides forces the need to do everything faster.

That’s where the open source community comes in. You need a module to get your network to do something? What if that something already exists, in the open source community – why reinvent that wheel?

Also: Open components are generally more transparent, which matters a lot in times of trouble. In today’s (proprietary) world, when something konks out, step one is to call the supplier. Here’s an actual example, from a recent batch of notes:

“With every (supplier) release, you get one large executable file. And if something doesn’t work, you don’t know what it is that doesn’t work. You test it. You go back to the vendor. They take a look at it – they don’t know where the problem is. They send you another large executable file. You go through that cycle four, five times.”

By contrast, with code that’s based on open source techniques, you’re able to see into the code, to fix problems on the fly. That load balancer that’s giving you fits? Move the logic out into an application layer for inspection. Find the bug, fix it, six hours.

Perhaps not surprisingly, the “open” world is thick with activity, participants, “solutions,” and jargon. We’ll tease out the parts that matter, and bring them to you here.

This column originally appeared in the Platforms section of Multichannel News.