Foreword: Yesterday, we published an article defining Device Software Optimization (DSO), based on an interview with John Bruggeman, chief marketing officer at Wind River, which coined the term. In response to that article, we received the following thoughtful “rebuttal” from Christopher Stone, offering a developer's perspective on DSO. We invite our readers to voice their own opinions on the topic, using the talkback thread at the bottom of the page. Enjoy . . . !

---

To DSO, or not to DSO — a developer's perspective

by Christopher Stone

Wind River has a message for us. Embedded software development needs a new process, they say, and “Device Software Optimization” (DSO) is the answer. Is it, though? Does DSO deliver true value to the developer, or does it just sell well in the board room? When you visit the DSO website, you will find a significant amount of content from the CEO's, vice presidents, and engineering managers of some of the world's largest embedded software product companies. There is an obvious buy-in from the management side of the embedded software development business.

The process of embedded software development does need to change for the following reasons:

• Social — in order to compete with offshore development costs and retain jobs in North America and Europe, we have to make developers more productive.
• Complexity — the increasing throughput of hardware means that embedded devices can fulfill more functions. This translates directly into more complex software. Since the complexity vs. development cost curve is not linear, better processes save large amounts of development cost.
• Robustness — consumers measure products primarily on reliability.
• Security — insecure is unreliable.

This article examines the DSO message from the engineer's point of view. In this article, I attempt to separate the engineering value from the marketing chaff in the Wind River DSO message.

According to John Bruggeman, Wind River's chief marketing officer, DSO has three main aspects:

1. Developers should build their devices with application-enabling platforms instead of doing it all themselves.
2. Application-enabling platforms should be based on open standards.
3. Application-enabling platforms should be globally supported by a multi-vendor ecosystem of commercial suppliers.

I am going to examine two of these points, numbers one and three, because point two is pretty straight forward.

Software reuse

Point one is all about software reuse — that is the engineering value. However, embedded software reuse is no different than software reuse in the desktop application industry. The state of the art in software reuse today requires the blending and successful execution of the disciplines of architecture, design, and programming based on fine grained software components. What does that mean? Application-enabling platforms are too big — components are what the industry really needs. Positioning application-enabling platforms as the answer the industry needs is the marketing chaff.

The problem with platforms is that they limit choices. Developing devices that sell requires a healthy dose of innovation. Innovation comes from diversity; from choices. One of the primary catalysts for the rise of open source software is the diversity of choices that it presents, and the innovation that it fosters. Choice creates innovation, platforms stifle it. I know from experience that developers today do not use application-enabling platforms unchanged. The vast majority still delve deep into the middle of them to enable the choices they are looking for — the choices they hope their competitors haven't thought of. Those changes invalidate the value of a tested platform. Tested components would deliver more value.

What does the embedded industry need to enable software reuse? We need tools, we need training, we need mentors:

• We need modeling tools that allow us to combine components into designs and automatically generate code
• We need test tools that allow us to build up databases of test cases during design and automate testing
• We need simulation tools that allow us to quickly try out new ideas and develop applications before there is hardware
• We need online courses that allow us to upgrade our skills at a reasonable cost
• We need mentors that can guide us
• We need it all to support the entire body of open source software in the world, and not just a productized subset

Multi-vendor globally supported solutions

It is a fact that the hardest tradeoff in a design is the cost of re-engineering components to work together vs the cost of developing from scratch. Thus, multi-vendor solutions designed to work together is the engineering value behind the third aspect of DSO.

To find the marketing chaff, consider that almost every embedded project gets into some kind of trouble with on-time delivery. Even projects that are completed on-time probably had engineers working late into the night in order to meet the schedule. The concept that there is a global company waiting to take your call and parachute a local expert in to your project to save the day is powerful, but unfortunately, is the marketing chaff behind the third aspect of DSO.

The vast majority of problems found at the last minute are solved by the engineers developing the device — either through working around a bug or solving the bug. It is true that an engineering manager will report problems to the software supplier, but, she doesn't sit and wait for the supplier to solve the problem. The engineers on the project will look for a way to get around the problem. Instead of focusing on global support delivered locally, it is more important to provide the customer with solutions that include the source code. The source code does not have to be under a free license, but, it must be available to the engineer at 3am when his test case fails.

Conclusion

DSO has some obvious value behind it. The DSO message would not be picked up by others if it was only marketing spin. Nonetheless, in order for DSO to be more than a passing fad, it must deliver value to the engineer at the keyboard, without vendor bias. The current DSO message needs to be changed because it is being used as a vehicle to influence decision makers toward solutions that are not optimal. The values of software reuse, open standards, and vendor diversity are honorable, but, they are values that have been honed by the desktop application market over the last ten years. They are not new values, so giving them a new name is questionable. Embedded developers just need to be given the tools, training, mentors, and source code to realize these values in the embedded software industry.

---

About the author: Christopher Stone is a partner in Sombrio Systems Inc., a consulting firm that specializes in real time, embedded, open source software. He is the founder of the Industrial Grade Linux distribution Mekanix which aims to enable Linux in factory automation and plant intelligence applications. He holds a B.Sc. in Computer Science from the University of Victoria in British Columbia, Canada, and has worked as an embedded software developer for 22 years.

---

Do you have comments on this article?

---

talkback here

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.