Through-out 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, remove the the safety belt 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. (Or at least be very careful using it!)
Reason #1 – Lacks a traceable software development life cycle
Open source software usually starts with an ingenious developer working out of their garage or basemen. They create something very functional and useful. Other developers are grateful and support for the software starts to grow. 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. The development doesn’t really follow any traceable software development life cycle but instead is just a mish-mash that is usually pulled together by the project hero.
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 the software functions, the code is generally not robust. It works well under controlled conditions, such as on the workbench but throw a wrench at it and the software will often fail. Robustness, in my opinion, is rarely found in many open source frameworks. 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 and conditions. 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, then a developer could find themselves having to release confidential code and algorithms to the world. Free software just cost the company in revealing their secret sauce! If a team wants to use open source while still protecting their IP, 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 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 – Customer 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.
Conclusions
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”.
Especially #3 is a real killer in many places. There is even the term of “contamination” used in the context of open source and commercial software: It is required to not contaminate productive software with open source code in order to avoid having to expose business secrets to the competition. Violations to that rule may easily ruin a company.
Do you see any irony in simultaneously sharing this and your post “5 Advantages of using Micro Python for Embedded Software” with “Advantage #3 – Open source and free”? A less click-baity title for this article might be “14 reasons to carefully consider open source software”, and include 7 good things about open source. That would be a more useful article, and not be two-faced with respect to simultaneously advocating Micro-Python. Thanks, Glenn
https://en.wikipedia.org/wiki/MicroPython MIT license
Thanks for the comment Glenn. I posted both of those together on purpose because it’s important to have a balance. Open source CAN be evil (notice this is not IS) if developers don’t carefully vet the open source code they are using. MicroPython is a great example of a very successful open source project which is why I paired it with this article. As an independent consultant, it’s critical for me to examine both sides of an issue.
I appreciate your suggestion for upcoming article(s) and these are actually already on my list.
Some comments:
#1
Most modern open source software these days use a versioning system like git, mercury or subversion. This greatly mitigates the traceability issues, but does nothing for the “build-and-pray” issue. On the flip side, you are allowed to modify the source to fit to your particular organisation, too. If the software is strategically important enough, you could even hire the basement dwelling teenager and bring the code and expertise into the company, like Transmeta did with Linux.
Also, FLOSS might be started to solve a specific need at a company, which does have all these resources available at the start. It is rare to see a Linux-style project growing like mold from some teenagers basement these days… 🙂
#2
This has to do with QA and testing – if your product depends on outside sources then internal product QA is required, but the same is true for all third party technologies. Again, since this is open source, you can do something about it be it document obscure bugs or pay a professional to come fix it for you.
#3
Right on the money there, Open Source does require you keep an iron grip on licenses.
#4
Formalised tests are great for products, but it all depends on the usage of the software. Oftentimes Open Source is not designed for a product, but as a quickly evolving software project. As the software matures, automated tests are eventually written. Also, do keep in mind that most FLOSS these days are written by professional programmers that do work on it for a living.
#5, #6 and #7 are genuine issues that the FLOSS movement does suffer badly from, but are hardly unique for FLOSS projects (any small actor suffer from the same problems).
A good read all in all, I agree with most but wanted to raise some minor reservations.
Thanks for the comment!