Design News is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

7 Reasons Open Source Software Should Be Avoided

7 Reasons Open Source Software Should Be Avoided
Developers need to recognize their requirements, needs, and the robustness level that they require for their product and appropriately develop or source software that meets those needs rather than blindly selecting software because it’s “free.”

Throughout my travels I encounter quite a few development teams that seem to live by the adage, “The best software is free software.” The moment they hear the words “Open Source” the heavens open, the choirs begin singing, and all thought about doing due diligence on the open source code is gone. That’s the direction, no matter the integration costs, no matter how badly support is lacking, that’s it! Put the blinders on, kick back, put the safety belt on and enjoy the ride. As much potential as open source software can provide, there are several reasons why embedded software developers should avoid it like the plague.

Reason #1 – Lacks a traceable software development life cycle

Open source software usually starts with an ingenious developer working out their garage or basement and they create something very functional and useful. Eventually multiple developers with spare time on their hands get involved. The software evolves but it doesn’t really follow a traceable design cycle or even follow best practices. These various developers implement what they want or push the code in the direction that meets their needs. The result is software that works in limited situations and circumstances and users need to cross their fingers and pray that their needs and conditions match them.

Reason #2 – Designed for functionality not robustness

Open source software is often written functionally. Access and write to an SD card. Communicate over USB. The issue here is that while it functions the code is generally not robust and expects that a wrench will never be thrown in the gears. This is rarely the case and while the software is free, very quickly developers can find that their open source software is just functional and can’t stand up to real-world pressures. Developers will find themselves having to dig through unknown terrain trying to figure out how best to improve or handle errors that weren’t expected by the original developers.

Reason #3 – Accidentally exposing confidential intellectual property

Developers often think that all open source software is free and comes with no hooks attached. The problem is that this isn’t the case. There are several different licensing schemes that open source software developers use. Some really do give away the farm; however, there are also licenses that require any modifications or even associated software to be released as open source. If close attention is not being paid, a developer could find themselves having to release confidential code and algorithms to the world. Free software just cost the company in revealing the code or if they want to be protected, they now need to spend money on attorney fees to make sure that they aren’t giving it all away by using “free” software.

Make sure that if you are going to use open source software, that you calculate the attorney costs to verify you are in the clear.

Reason #4 – Lacking automated or manual tests

Yes, this one might be a stickler since there are so many engineers and clients I know that don’t use automated tests. A formalized testing process, especially automated tests are critical to ensuring that a code base is robust and has sufficient quality to meet its needs. I’ve seen open source Python projects that include automated testing which is encouraging but for low level firmware and embedded systems we seem to still lag behind the rest of the software industry. Without automated tests, we have no way to know if integrating that open source component broke something in it that we won’t notice until we go to production.

Reason #5 – Poor documentation or documentation that is lacking completely

Documentation has been getting better among open source projects that have been around for a long time or that have strong commercial backing. Smaller projects though that are driven by individuals tend to have little to no documentation. If the open source code doesn’t have documentation, putting it into practice or debugging it is going to be a nightmare and more expensive than just getting commercial or industrial-grade software.

Reason # 6 – Real-time support is lacking

There are few things more frustrating than doing everything you can to get something to work or debugged and you just hit the wall. When this happens, the best way to resolve the issue is to get support. The problem with open source is that there is no guarantee that you will get the support you need in a timely manner to resolve any issues. Sure, there are forums and social media to request help but those are manned by people giving up their free time to help solve problems. If they don’t have the time to dig into a problem, or the problem isn’t interesting or is too complex, then the developer is on their own.

Reason #7 – Integration is never as easy as it seems

The website was found, the demonstration video was awesome. This is the component to use. Look at how easy it is! The source is downloaded and the integration begins. Months later, integration is still going on. What appeared easy quickly turned complex because the same platform or toolchain wasn’t being used. “Minor” modifications had to be made. The rabbit hole just keeps getting deeper but after this much time has been sunk into the integration, it cannot be for naught.


By no means am I against open source software. It’s been extremely helpful and beneficial in certain circumstances. It’s important though not to just use software because it’s free and open source. Developers need to recognize their requirements, needs, and the robustness level that they require for their product and appropriately develop or source software that meets those needs rather than blindly selecting software because it’s “free.”

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer and holds three degrees which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website, and sign-up for his monthly Embedded Bytes Newsletter.

Join Jacob Beningo at ESC Silicon Valley!
Join Jacob Beningo for three can't-miss sessions at ESC Silicon Valley, Dec. 5-7, 2017. He will be on-hand live at the San Jose Convention Center, where he will be discussing: "Getting Started with Trustzone using Cortex-M Microcontrollers," "From Baremetal to RTOS," and "How to Start and Grow a Start-up." Click here to view the full ESC Silicon Valley lineup. Register today!
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.