Feeds

Windows device development faster, cheaper than Linux?

But if so, why are so many outfits committing suicide?

  • alert
  • submit to reddit

The Power of One eBook: Top reasons to choose HP BladeSystem

A survey of embedded device developers claims a 4:1 development cost advantage in using Windows embedded platforms over Linux ones. By happy coincidence the report was funded by Microsoft, and will no doubt therefore be playing its part in Redmond's current 'get Linux' campaigns, but nevertheless it should not be dismissed out of hand - its numbers do have a certain validity, and warrant examination, although the report may not ask all of the right questions.

The obvious question it doesn't ask Linux developers is, if it's so darned expensive, why are you doing this to yourselves? It claims average total cost of development for using Windows XP Embedded, Windows CE.NET and embedded Linux respectively at $438,000, $510,450 and $1,888,458. Within this, Linux development tools are more expensive, time to market is almost double (14.3 months versus 8.1 months), Linux developers are paid more, Linux development teams are bigger, and total runtime licensing costs are far higher, because while much comes free with Windows, Linux projects typically require more components to be bought in.

Pretty damning stuff? You can get Jerry Krasner report with all the raw data here, then join us in taking a shot at the 'why are they doing this to themselves' question.

Krasner surveyed 50 outfits developing for Windows and 50 for Linux, covering the standard range of devices. For reasons of commercial confidentiality it clearly wasn't possible for him to go too far in identifying particular products, but given the fairly small number in each category (e.g. one each for consumer electronics and gateway/server for Windows, also just the one for Linux POS/kiosk) there's a lot of scope for single projects to screw up the averages, and there's no way to match the level of resources expended with the relative complexity of particular projects, aside from crossing your fingers that distortions will average out.

The two European Linux set top developers who clocked up DMM (Developer Man Month) scores of 1955 and 1700 would seem to us to have had a certain unfortunate impact on the numbers, as indeed would the Asian Thin Client project under XP Embedded that took two engineers one month, for a DMM score of 2. Divergences like these within very small samples would seem to us to tend to undermine the statistical validity of the numbers.

One can infer a certain amount about project complexity from the populations of the various device sub-categories. CE handheld computers (several are covered), for example, should by now be pretty simple things to develop, given the amount of effort Microsoft has put into this particular sub-sector of world domination. Linux handheld computers, on the other hand, are clearly a considerably bigger challenge, while Linux gateways and servers, being rather more mature, are much less so. So the devices range from simple, well-understood ones that are at least approaching commoditisation (by design, in the case of many of the Windows ones, which provides one answer to the question we started with) to more ambitious punts aimed at categories that don't entirely exist yet.

But despite this, with just a couple of exceptions Krasner's numbers do seem to indicate fairly consistently that more development effort is put into Linux embedded projects than Windows ones. The divergent nature of the projects may make it rash to, as he does, report a threefold advantage for Windows (64.0 versus 203.7 DMM), but the divergence is there.

So, why? Do we hear voices at the back saying it's because Linux developers are creative types with short attention spans who'll goof off down strange byways if you don't keep an eye on them, whereas Windows developers are code-monkey morlocks? There's perhaps more than a grain of truth here, so we'll try rephrasing it less insultingly.

Windows, in all its many and varied forms, is about commoditisation. Microsoft offers tightly defined and controlled platforms together with a wealth of standard tools, Ts & Cs and support packages for developers to work with, so it's fairly cheap and easy to produce products that are pretty similar to other people's products. Microsoft also, from way back in the 80s, has pushed the industrialisation of the development process. The result as far as hardware is concerned has been that differentiation and price have been eroded, and if you want to compete - with, say, Dell and HP - in the commodity handheld computer market you need to keep your team size down and your ambitions modest.

Avoiding commoditisation while sticking in the Windows arena is however hard, and quite probably a suicide mission, so if you don't want to go on it you go somewhere else instead, check? You don't necessarily go for Linux (Krasner's Linux versus Windows focus is in this sense artificial), but whatever you go for you're likely to be spending more on development than you would by taking the Windows commoditisation route. And your developers are more likely to be more expensive, goof-off prone geeks than cheaper, downtrodden code-monkeys.

Not inevitably, of course - in cases where the objective is simple and well-understood it should be possible to knock out a Linux or BSD product for relatively little effort, and provided you understand that means it's a commoditised product and price it accordingly, then that's cool too. As embedded Linux matures, there should be more products that fall into this category.

So it strikes us that the higher costs for Linux Krasner identifies could to a large extent be put down to a larger proportion of the developers trying to differentiate and/or break new ground. In doing this they will naturally tend to overrun development schedules, cancel projects and produce products that fail to hit the spot (The Register now owns several of these, but could not possibly have afforded them at list price).

High risk projects that are possibly aimed at new categories we think may exist are more expensive and fail more often, but produce higher rewards when they hit the spot. Commoditised categories result in low risk projects, but the rewards are also lowered, and there's a case for saying that, where there is an overall objective of commoditisation, innovation dies.

In the embedded market, Microsoft initially set out to displace proprietory embedded systems, and is now in some areas the incumbent defending itself against what it sees as a similar challenge from Linux. Microsoft spent - and continues to spend - a large amount of money in getting itself into this position, and it seems reasonable to expect a certain expense now to be associated with challenges to Microsoft. Further down the road, if the challenge begins to succeed, then the average costs will come down, although we'd argue that it'd be bad for innovation if expensive and protracted development projects vanished entirely.

Essentially, innovation, differentiation and building on new platforms ought to cost more, and we should not be surprised when they do. Krasner's figures are certainly interesting, and flag some areas of concern (the tools issue being one of the more obvious of these), but they do not provide adequate reason for Linux developers to flee the battlefield and sign on with Satan instead. Hindsight may tell us that some of the developers of failed embedded Linux devices were indeed foolhardy or even crazed, but most current developers are not, have very good reasons for not taking the Microsoft shilling, and understand the reasons for spending more, if that's what it takes. ®

Related link:
Embedded Market Forecasters

Boost IT visibility and business value

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Captain Kirk sets phaser to SLAUGHTER after trying new Facebook app
William Shatner less-than-impressed by Zuck's celebrity-only app
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
EU dons gloves, pokes Google's deals with Android mobe makers
El Reg cops a squint at investigatory letters
Chrome browser has been DRAINING PC batteries for YEARS
Google is only now fixing ancient, energy-sapping bug
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
The Essential Guide to IT Transformation
ServiceNow discusses three IT transformations that can help CIO's automate IT services to transform IT and the enterprise.