Mike Hall (Windows Embedded Blog, of Microsoft) posted that Linux use in embedded systems is declining based on a whitepaper from an RTOS vendor and a study from Jerry Krasner of Embedded Market Forecasters. Mike writes a great blog… you should subscribe to it and read it regularly. Microsoft makes a compelling set of products that service true market needs. Nothing but respect for what the do… but I can’t let this slide.

Claim: 48% developers not considering Linux for their next embedded project

This is based on an unreferenced CMP survey cited in a whitepaper by RTOS vendor Express Logic. I sure wish they had a URL to the study because the chart they cite gives me pause. The little footnote that states that they question that supports this claim was changed in 2007 to be more specific about time frame was intriguing. Perhaps they asked a more specific question and got more specific answers? One might feel more freedom to answer liberally about what you hope to do in the future if there is no time frame to it.

Claim: New or modified lines of code on Windows CE 47,000 (ave) compared with 193,000 industry average

The Krasner report which supports this claim is far more interesting. Lets dig in!

A bit about EMF and Jerry Krasner: Jerry’s had years of experience watching this embedded systems market in particular. He’s said both positive and negative statements about embedded Linux. Back in 2003 he was unfairly vilified by many for his report “Total Cost of Development: A comprehensive cost estimation framework for evaluating embedded development platforms” that dinged embedded Linux for a high TCO and propped up Windows CE .NET and Windows XP Embedded. Linux Devices has a good historical summary.

In a December 2007 study “Embedded Linux Total Cost of Development Analyzed” he revisited this topic… this time with his own data collection and apparently free of any vendor funding or direction.

Some quotes from the December 2007 study that I find compelling:

In summary, Linux not only continues to gain market share across the embedded spectrum, but the definitive EMF data set forth herein demonstrates that developers using Linux have the same design outcomes compared with traditional RTOSes.

Uh… sorry Mike. Looks like you’ve reversed the polarity on what the LOC metric means. You’ve got to look at both the lines of code written and the design outcome data in the Krasner study. Just because a project is big in terms of lines of code doesn’t mean the underlying platform is a failure. Krasner mentions that “out analysis showed that the in-house developers wrote fewer lines of code and fared poorly when it came to final design outcomes as compared with their pre-design expectations.” He is using lines of code as a metric of developer contribution to product design requirements, not as a measure of project burden.

Consider what we get when we mash-up both the RTOS and Linux Krasner studies that were published in 2007:

So it looks like if you want to get quicker time to market you’ve got a fairly obvious choice. I also like how this data supports something I’ve felt empirically for 10 years now: Working with a commercial Linux vendor will result in a better project outcome:

Final design results within 30% of pre-design expectation for features and schedule:
Commercial Linux = 70.2%
Other Linux = 59.0%

I’m not bashing Windows CE/XP Embedded, Microsoft, or Mike. I just think that if you are going to go cite a market research study that you’ve got to take into account the overall dataset. The data indicates, to me, that:

1. in-house RTOS or Linux projects are painful
2. not all RTOS or Linux commercial vendors will support the same project outcome

I live in Atlanta and took some time last Tuesday night to attend CloudCamp Atlanta. I’ve worked with what we now call “cloud” technologies for quite a while. One of the highlights of my visit was a chance to meet Luke Kaines of Reductive Labs. As a few people around the office know I’m a big fan of Puppet. Luke was in town speaking at CCA from his native Nashville and I sat in on his session.

So if you don’t know about Puppet I’ll explain briefly. System administrators who run a _lot_ of systems can take at least two different approaches:

• Imperative: Write mountains of scripting code to diagnose what system administration actions need to be conducted.
• Declarative: Define a model which states how the system should look and let the tool bang the system into compliance.

Puppet is a declarative system. One uses a special domain specific language to describe a multi-system configuration. Puppet compiles this manifest and ships it out to nodes. Each locally installed version of puppet then tweaks the system until it matches the manifest.

I used Puppet on an internal project here at work… so that was why I was interested in meeting Luke. He had some interesting statements on the nature of open source community that I found intriguing and applicable to any realm of computing… even embedded. These aren’t quotes… just recollections.

A community will likely get you a lot of marketers and maybe some developers: There is a #puppet IRC channel on freenode.org that according to Luke routinely has 200+ developers sitting on it. There is also a
very active email list. These “marketers” are profoundly helpful and it was my observation that Luke didn’t mean it as a slight. He did go one to elaborate that there was really a very small core of developers who did core Puppet work.

Those marketers might be quite powerful: The room at 15-20 people in it and many of them displayed not just awareness of Puppet but actual expertise. That’s something for a tool which has minimal commercial backing and is rather young relative to its class (4-5 years). There was even, at the same time, a presentation on going at Linux.conf.au which was reportedly very popular.

In my mind I start to wonder what is the right balance between skilled developers and passionate marketers for a commercially backed open source project? Luke has taken a very open approach. Reductive Labs is a small shop right now that pays their bills and has a very passionate user and marketing base. Do they have the right balance for the future? I don’t think I’d be listening to Luke at all if it weren’t for his community of marketers.

What about our realm of embedded software? I often think about a few different mobile and open source projects/standards of recent origin:

1. Google’s Android
2. the LiMO Foundation
3. the LiPS Forum (now merged with LiMO)

or in the closer to earth real time Linux realm:

1. the Ingo/Gleixner RT work
2. ex-FSM Labs’ RT-Core
3. RTAI

who out of these two groups of projects/standards has the most effective balance of passionate marketers and skilled developers? I think I’d have to pick #1 on both of them… but that’s just my opinion. What’s yours?

Brad

First of all… Happy New Year to everyone. I’ve been on the road for the first weeks of the new year so I’m finally getting back to blogging.

Last July the FSF released the new GPLv3 license and started to advocate for its adoption as the most preferred license for Free software development. The GPLv3 license brings many positive improvements to both developers and users of GPLv3 licensed code. Even those in the embedded software business.

Adoption of the GPLv3 hasn’t been as quick as the FSF might have expected. Under the covers there are a lot of interesting developments going on. Have you noticed that:

• GPLv3 adoption, while significant, isn’t a blazing wildfire. I wish I could substantiate this but I’ve noticed that Palamida’s GPLv3 adoption tracking website is now gone. Any idea when it disappeared.
• The FSF has been slow to migrate its own GPLv2 licensed projects that have embedded target resident software to the GPLv3. One example is libstdc++ which is under a GPLv2+Exceptions license.
• Nokia recently added an LGPLv2 license option for Qt. Prior to the Nokia acquisition the Trolltech team relicensed Qt under the GPLv3. Nokia buys them and all of a sudden there is is an LGPLv2 option. Coincidence? No, I don’t think so.
• I’ve also heard first hand, from multiple locations, that there is resistance amongst the corporate users of GPL licensed software to the GPLv3.

Now does all of this mean that the GPLv3 is a failure or should be revised? No, not necessarily. It is my personal opinion that the initial resistance to the GPLv3 is mellowing as people become more accustomed to it. Legal staffs are, presumably, have also taken this time to grow familiar with it.

I also get the sense from folks in the know that the FSF is well aware of the concerns in the user and developer community about the usage of GPLv3 on certain projects in the embedded software domain. Maybe that explains some of the slow transition. Ultimately I think that the FSF actually needs embedded software developers, projects, and companies more than it might be letting on. Much of open source development these days is corporate sponsored and keeping these companies as happy benefactors is important.

So will the GPLv3 go away? No… and it likely shouldn’t. As both a supporter and user of Free software I have confidence that the natural forces that are directing this system will likely force helpful compromises. I can’t really predict what those will be with accuracy but in due time I think we’ll all step over that GPLv3 threshold.