I’ve worked with many customers on their open source and Linux strategies over the years. A reoccurring organizational pattern I’ve see is the “platform team”.

The platform team is usually only found in large corporations and it typically only created after a few embedded Linux based products have come and gone. Someday an executive in engineering or the CTO office declares that a central group should manage everything Linux related for product design and the team is created. Usually the first few projects go off well but after a while some cracks begin to occur.

Here are a few reasons I’ve seen platform teams fail to scale across the engineering community of these large companies:

Failure to consolidate: The symptom of this failure is that you’ll end up with several platform teams. It often gets so bad that you’ll see one or more per major division in the company. Executive fiats are often rendered to try and “fix” this problem but that is a seemingly difficult organizational edict to enforce due to technical limitations.

Failure to solve real project design problems: The symptom of this failure is design teams who start to quickly explore “alternatives” to the official platform due to technical requirements that just aren’t supported by the platform team. I’ve spoken with project leaders who said it would cost their platform team, and I kid you not on this, TWO MILLION DOLLARS to migrate their platform team created Linux to the new hardware design created by the project.

I spent time with a design team who’s central Linux platform team had allied with a competitor. This was over a year into the partnership and the project team had been given the thumbs down from the central Linux platform team. It seems that neither the central Linux platform team nor the vendor that they had allied with wanted to support the hardware platform they needed to use to meet their project’s performance requirements.

If you are a platform team and you aren’t serving your internal customers and your Linux commercialization partner can’t help you in this essential mission exactly what value are you adding to this game?

Failure to agree on how to split the tab: This is the one that seems to bite them all in the butt. The platform team does good work but the various project teams that want to use the platform can’t agree on how to fund the platform team and the maintenance of the platform. Each is willing to pay for the essentials to enable their project but none of them want to fund common technology investment.

Failure to remain connected to open source: Open source is the fount of all embedded Linux goodness. Platform teams who are more concerned about building the widget (their particular kernel and Linux release) than they are about building the process fall in this trap. This is why at MontaVista we emphasize that we help you to get the most out of open source. It isn’t about kernel 2.6.28… it is about the best way to get essential technology into your engineering team efficiently. Stay connected, build process, don’t become an island.

No ability to say “That’s a bad idea.”: Sometimes a project team will just have a bad idea. They’ll need something that isn’t right for the platform constituency at large. If you’ve built your platform team around consolidating on a set of particular widgets rather than a process to get the most out of open source you’ll have trouble. What if this project is your biggest funding source? Can you really say “no” to their bad idea?

If you are working at a company on a Linux platform team or are using the output of one of these platform teams I’d love to hear from you. I’m kicking around some interesting ideas. Comment lines are open.

Next week, November 18th, we’ll be running a great webinar entitled “Tips and techniques for improving embedded Linux startup time”. I encourage you to attend because one of our greatest assets here, Christopher Hallinan, will be speaking with Sridharan Subramanian of Freescale, and providing an overview of the boot sequence and kernel optimizations to consider for improving boot up. Chris, as you may know is has authored the number one embedded Linux book out there: Embedded Linux Primer.

Register and learn something new!

Amanda McPherson, Brian Proffitt and Ron Hale-Evans over at the Linux Foundation just released a new report on estimating the total value of the GNU and Linux software stack. If you’ve been around for a few years you’ve seen similar studies by David A. Wheeler and Bill Weinberg. All three of the studies use the COCOMO software costing model. COCOMO is an algorithm that uses some some algorithms to estimate the cost of a software codebase from the number of lines of code and the cost of the engineering team to write the code.

COCOMO spit out that Fedora 9 was a $10 billion dollar nugget of code.

Those out there with a more cynical mind will likely start complaining about the model, the cost of the engineer, the biases of the study authors, etc.

Let’s ignore all of that and just be brutally honest: There is zero financial incentive to create new competitive proprietary operating systems. The costs are too high because the barrier to compete is set very high by Linux. You won’t get rewarded by the market for writing a new block disk layer or scheduling algorithm under a proprietary license.

What does this mean for the embedded systems market? Lack of new competitive threats against the surviving proprietary operating systems. With few new competitive options the investment that might go into product improvement that could benefit the common user is withering. You can see it already… the real competitive front for many of these companies has shifted to milaero. They duke it out adding new features that 99% of embedded developers will never use.

So what to do? You’ve got to make your move and find a comfortable orbit around the world of GNU and Linux. That’s the innovation center. $10B is part of the proof of that. Next you need to find a way to get the most benefit from this new world of open source.