Wednesday, December 19, 2012

Open standards, open source, and why the difference matters

As Andy Gryc reported in a previous post, Paul Hansen of the Hansen Report asked six automakers whether they plan to ship products based on the GENIVI open source platform. Not one of them said yes.

This underwhelming response to open source may seem surprising, especially to people outside of the auto industry. It seems even more surprising when you consider the many companies that belong to the GENIVI Alliance — a veritable who’s who of high-tech and automotive companies, from ARM to IBM to Volvo. Why the disconnect?

A couple of reasons come to mind. First, the automotive market is exceedingly competitive. Asking automakers to collaborate on a common OS platform — the GENIVI approach — is arguably a non-starter. Also, many automakers seem to grasp that open source OSs don't necessarily address the issues that matter to them most.

Allow me to explain. Automotive companies entertain the option of using open source for several reasons. They want to avoid vendor lock-in. They want to leverage a large developer community. They want to access a rich toolset. And, in many cases, they hope to avoid the costs of runtime licensing.

Yes, open source can help address these requirements. But more often than not, open standards offer a better route to achieving what automakers really need.

Vendor neutral, OS neutral, hardware neutral
Take the goal of avoiding vendor lock-in. An open standard is, by definition, vendor neutral. It is typically the product of a collaborative and transparent process free of domination by a single company or interest group. Likewise, it isn’t controlled or maintained by a single, self-interested entity. HTML 5, for instance, isn’t owned by any one company, but is a standard embraced by Apple, Google, Microsoft, Mozilla, QNX, and others.

HTML5 isn't just vendor neutral; it's also OS and hardware neutral. By using it as an HMI and application environment, automakers gain the freedom to choose the best OS platform for the job at hand, and the option to migrate across platforms, if required. In other words, HTML5 enables automakers to use the platform that can offer fastest boot speed, the highest reliability, the best mobile device integration, or the best performance on automotive silicon — things that can reduce costs and improve the user experience. (To put this another way, the underlying OS platform is anything but a commodity — a fact demonstrated every day in the mobile device world.)

An open source platform may or may not share these characteristics. Even though developers can access the source code, a single entity may still control the technology’s roadmap and licensing terms. In effect, the platform can constitute a single point of failure for the automaker — exactly what automakers try to avoid. Compare this to an open standard, which is defined collaboratively and then supported over a long period of time. POSIX, with its 20+ year history, comes to mind.

Also, open standards like HTML5 are unencumbered by the protective licensing terms often associated with open source OSs — terms that can lead to greater system costs and complexity. For instance, the GNU Public License (GPL) that governs use of the Linux OS ensures that any modifications to the original program are released as open source. That's a problem for any OEM that doesn’t want to “open source” its technology; for instance, vehicle bus information. It is also incompatible with the certifications and licenses of consumer device manufacturers whose licensing terms are designed to prevent integration of their code with GPL code bases; iPod support and integration is a good example. Such technologies must, as a result, be separated into another virtualized OS or onto external hardware modules. The result is a more expensive and more complex system — another thing that automakers try to avoid.

Delivering the goods
Of course, all this hinges on whether a standard like HTML5 can deliver the goods. And from my perspective, it does. For instance, it can provide all the capabilities of a traditional HMI toolkit, including a rendering engine, content authoring and packaging tools, and sophisticated graphic transitions. But unlike proprietary solutions, it can also help automakers:

  • tap into a vast pool of apps and developers
  • integrate with mobile devices
  • build user interfaces that incorporate virtually any delivery model
  • customize the UX and simplify access to mobile apps
  • customize apps and the UX for context: park, creep, drive, etc.

In addition, HTML5 can, with the right platform, work in concert with other HMI technologies (Adobe AIR, OpenGL ES, Qt, etc.) and blend seamlessly with those technologies on same display. As a result, system designers can choose the most appropriate technology for each application.

Incorporating open source
So is open source a total non-starter in automotive? Absolutely not.

In fact, many standards incorporate open source. Let us once again consider HTML 5. While it is built on an open standard, many HTML5 implementations are developed using open source solutions. For instance, many of the current, industry-leading HTML5 solutions are built on Webkit, an open source solution governed by the Lesser GNU Public License or LGPL.

The point is, the most successful solutions will combine the best that open standards, open source, and proprietary platforms have to offer. But if you were mandate an “open” solution, an open standard would be the best to rally behind.



If you're interested in this topic, we recommend you listen to the webinar that Andrew gave last week, "In-vehicle product differentiation: open standards vs open source." — Ed.

2 comments:

  1. Stumbled across this article via Google alerts.

    I don't disagree with the thrust of it but I think you might have a couple of things a little mixed up.

    1st: open, i.e., unencumbered, standards, absolutely.
    2nd: I'm not sure you've framed open source software accurately

    HTML5 is not yet a standard. Some aspects of it still look problematic, e.g., video. Dealing with the substance:

    Using HTML 4.01, WebKit (nee KHTML) renders HTML. HTML 4.01 could be produced on the most horribly proprietary solution possible, but WebKit would still render it.

    WebKit has an interesting history. A large vendor that took KHTML to create WebKit initially refused to contribute back and had to be shamed into line (I wonder if the vendor would still be shameable today, BTW)

    Some standards apparently open are under single vendor control.

    I cannot think of a single, thriving, open source software project that has single vendor control.

    It's single vendor control that's the issue.

    Auto seem to be behind the learning curve here.

    For example, all the major bourses (stock exchanges) run on an open source software platform, Linux. They don't care because they're not software vendors, it's not what they compete on.

    OSS is a client side model, freeing you to get on with what you do best. My favourite anecdote remains Ernie Ball Strings:

    http://news.cnet.com/2008-1082_3-5065859.html

    a web search will reveal that this story remains true.

    Intended to be helpful


    ReplyDelete
    Replies
    1. OpnSrcCons: apologies for the delay in publishing your comment. - Moderator

      Delete