Linux: Not for license dodgers

Far more consideration than license cost is required for inexperienced would-be migrators.

Sadly, the response to most “Why are you considering Linux?” questions is rarely on its own merits and invariably “because it’s free”. Product designers often perceive Linux as exclusively an opportunity to circumvent (typically) Microsoft license costs from appearing on their bill-of-materials, with the apparently obvious conclusion that their product’s sales price, or profit margins, will improve as a result.

This is naturally disappointing, primarily as it demonstrates those approaching design from a purely cost perspective at the expense of focusing on quality, functionality or reliability – an approach which thankfully is pretty rare in our embedded industry, but the lure of “free” is clearly too much. The pitfalls of blindly following a (allegedly) “free” route may only become obvious later.

Before I move on from the zero license cost headline that Linux stalwarts so often wave about, it’s worth noting that whilst Linux for personal usage is, by definition and design, free of license cost, this isn’t always true for commercial variants. Yes, the fundamental open source mantra remains, but there are many commercialized versions of Linux out there that do charge a license fee – always verify this before beginning your operating system evaluation.

Once you’ve established if the Linux flavor you’ve identified truly is license cost free for commercial implementation, you are a step closer to facilitating a like-for-like comparison, but you’re not there yet. I’ve seen many leap blindly into specifying Linux on embedded systems, with the ill-informed assumption that development and deployment effort against license fee based operating systems (such as Microsoft’s) needn’t be considered – in fact the opposite is true.

A simplistic way to look at this is to consider license cost to be inversely proportional to development and deployment effort. Logistically with license fee based operating system that charge is covering the effort the operating system designer spent on creating a platform that is as ready to use as it can be. With a license-free operating system no such funding exists through license sales so there’s a much higher onus on the implementer to configure that operating system to perform as they need it to.

Additionally, if we focus purely on Linux versus Windows temporarily (as this is the most common debate), a high percentage of the public, even those outside our industry (and quite possibly even your children/grandchildren) could configure a Windows installation to be 95 percent perfect for your product ¬– that 5 percent covering more industry specific configurations such as kiosk modes, write filters, and security. Put a standard Linux desktop in front of those same people and the majority will stare blankly at a setup that is inherently alien to them – that’s without considering how many variants of Linux there actually are!

I’m by no means discrediting Linux, for seasoned Linux developers I’d have few arguments for them to suggest they migrate to an operating system they must pay license fees on, but that isn’t the issue. The issue is those with no Linux experience themselves and no willingness to pay a third party to deploy Linux into their embedded system, specifying it anyway because it’s “free”. From my own experience, I often see these individuals attempting to lean on the supplier of the embedded hardware to support them through this alien software development cycle and facilitate them dodging operating system license fees – though embedded hardware suppliers are rarely in a position to provide that level of support, especially on a product they didn’t supply. This is an interesting argument in itself as I’ve seen scenarios where a Windows user, sourcing the license through their hardware provider thus providing some financial support coverage, wishes to migrate to Linux. With no Linux experience at all, they attempt to put that task on the hardware supplier, which is expected to fund this effort, despite successful completion meaning reduced level of business!

Clearly that latter plan for prospective first-time Linux integrators is doomed to failure, so what should an operating system specifier do?

The very first question must be: What quantities am I producing this product in? Understanding this will give you the constant you need to balance development effort with unit costs. As a very crude demonstration, with a choice between a license cost of $100 and $0 development effort, or a $0 license cost and $11,000 development effort, the point of intersection is 100 units. Above 100 and the license free route will reduce overall cost, the further below it you venture the license free route will cost increasingly more. Further aspects that require consideration include current and future hardware support (will drivers be issued free, or do they need developing at your cost) and connectivity support – what will your product interface with today and in the future, and is that likely to require any further development effort in the event?

I am sure that this will have raised the question: “Should I use Linux?”

Linux is a mature operating system that is proven as a viable operating system and can be very reliable. This is also true for your embedded system. So the answer is a positive “maybe”.

Armed with all of the facts, and given the knowledge of all “hidden” costs, you should be able to make an informed financial evaluation of all available solutions. Remember, the key driver may be the application, the quantities, the product’s functional longevity, or, it may be YOU.

Topics covered in this article