The role of the platform, revisited -

The role of the platform, revisited

When an article can motivate someone to respond right after reading it, or even after taking a walk for a second to cool their jets, it must be a good article. To that end, a recent Bernard Cole article is a winner. In “Blind Men, Embedded Platforms, and RTOS Elephants” Mr. Cole addresses the topic of platformization .

A platform in the technology space is akin to a platform in the automotive space and shares some of the same advantages. By developing a platform of RTOS, silicon, and associated development and debug tools from which multiple products can be developed, OEMs come closer to reaching economy of scale and enjoy lower per unit costs. This is not some black art, but rather, business applied to science.

Mr. Cole's article seems to convey the platform concept from a narrow scope, and doesn't really take into account the commercialization of products that OEMs have to face.

Also misleading is the inference that the applicability, or future success of an RTOS provider, is directly related to the degree of source code that the provider opens up to the world. The reality is that most OEMs do not have the staff with the right experience to really make a difference if they have access to the kernel, nor does the problem normally have to do with any kernel, or source-protected code. Usually it has to do with the way a developer utilizes the facilities offered by the RTOS provider. So, if we agree for a moment that having source is not a major necessity for developers, why do we cling to this notion?

I've got two theories. First, there is an overwhelming concept that RTOS companies offer terrible support, or at least do not offer the right kind of support (Wind River, we are talking to you here). If you can't get support to your issue, and you can't push your project/product manager to push off the delivery of your product to be more aligned to the RTOS provider's schedule, then of course you would need to look at the source for the underlying code for which your code body is based.

My second theory has to do with perception. The perception is that if your work is transparent to your customer, you have nothing to hide. This is certainly true of businesses post-Enron, but is this transferable to the world of commercial RTOS providers where the bulk of their IP is in their source?

Heck no. There source code is what keeps them in business to allow you to buy their products, which in turn allows you to build yours and sell them to your customers. Asking a commercial RTOS provider to lift up their kimono and risk losing their IP is like asking Cisco to show Juniper just how they have architected their packet distribution technology in their latest core router.

I'm saying that we need to hold RTOS providers to better support. This is a call to all OS companies, not just Wind River. Second, I'm saying that platformization is equivalent to the development of a reusable component, which means that reliability should go up, time-to-market should go down, and costs should go down. All good stuff. And last, I'm saying that the concept of open source is highly altruistic. It does have its place, but not in an environment of taking innovative ideas and commercializing them for sale to the open market.

No, I'm not saying we should all be like Microsoft. Instead, I'm saying that we don't go to work for free, we don't give our products (for which we spent thousands of person hours developing) to our customers for free, and we don't shout from the rooftops when we have to pay two dollars for a cheeseburger. Why then should we expect skilled developers to work hard and be creative and then want them to share their IP with their competitors so that they must try to make money on services alone?

Greg Fields

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.