These days, the use of open source software is amazingly ubiquitous. The planes we fly on every day use safety-critical software developed with open source tools, as well as open source library code. In Europe the air traffic control systems have been developed using open source software. Everything from kitchen appliances to advanced weapons systems is powered by open source software. For example the refrigerator in the kitchen where I am sitting writing this article is Wi-Fi-enabled, and the manual comes with a URL reference to the source of the Linux version that this appliance uses. For some embedded systems, such as those using ARM technology, often the only available development tools are open source, and you can for example get a complete Ada language environment for the ARM chip, including tools for safety-critical certification and formal proof techniques.

If for some reason you decided that you did not trust open source software and wanted to avoid it completely, you would be pretty much stuck. You couldn't fly, you couldn't turn on your computer (even highly proprietary systems like Windows incorporate some open source software), you couldn't drive your car, you couldn't use the ATM machine ... All these systems incorporate some open source components, or are built using open source tools. At this stage, it would probably be easier to survive using only open source software than to avoid it completely.

So what are we to make of this? Is there some amazing software revolution in progress? Before we try to answer that question, let's understand a bit better what the term "open source" means. In fact it's a rather confused term, since it involves two related but different concepts. First we have the notion of licenses that provide much more freedom to users. Richard Stallman coined the term "Free Software" to capture this idea, where by "Free" he referred to freedom, not a $0 charge (languages like French which distinguish the words "libre" and "gratuit" avoid this English confusion). He prefers to avoid the term "open source" because it obscures this important notion of freedom, and to reserve the term to refer to the development methodology where software sources are freely available and where many different people – from high-school student hobbyists, to top professional programmers paid by major companies – work on the development.

In practice the two aspects of open source – licensing and methodology – tend to go together, because a necessary component of the open source software notion is a licensing approach free enough to permit this kind of open development, and a key concept behind Free Software is making the sources available, which makes open development possible. We like to use the term "FLOSS" (freely licensed open source software) to capture both notions.

What does this ubiquitous availability of FLOSS tools and code mean to a developer? If you are a student or a hobbyist, it means you can find freely downloadable software on the web (free in both sense of the term), and develop interesting additions to the FLOSS infrastructure. For example, the Ada-based development system for the (bare-board) ARM chip is freely downloadable, and we know of one university where students are developing interesting new drone software technology using this system.

But what does it mean for the developer of "serious" software? We put "serious" in quotes here because FLOSS software developed by students can very definitely be serious. For instance, the CubeSat developed at Vermont Technical College using freely available Ada technology, launched with other CubeSats last November as part of a NASA-sponsored effort, is now orbiting the earth and is one of the few CubeSats from that launch still operational, and it is sending beautiful pictures back to Earth. So let's narrow this down to the development of commercial systems, such as critical avionics software.

From one point of view, the availability of FLOSS tools and code really doesn't make any difference. How software is developed has little to do with its quality or suitability, and when it comes to licensing, freer license terms can only help and not hurt. So check out available software, evaluate whether it is suitable for your use from a reliability/quality/legal point of view; whether or not it is FLOSS is really quite irrelevant.

However, this is a little too easy to say, and we should dig a bit deeper. First, in the minds of many, including sometimes those who make important policy decisions at large companies, "open source" means downloading free (in the $0 sense) software from the Internet and using it without proper qualification and vetting. The notion of hundreds of software developers furiously downloading stuff from the Internet in a completely uncontrolled manner seems like a nightmare to those trying to control things. Are they right to be concerned? Absolutely, there are many problems in just pulling stuff off the Internet. First, you have no idea if it is licensed correctly (you absolutely cannot rely on copyright notices in files that you download, they have no legal significance). Second, you often end up with software that is totally unsupported, and that can be a major problem in a critical development environment. Third, you have no idea if the quality meets your requirements.

It really isn't FLOSS per se that is the problem here. If a company allowed programmers to freely spend money on any proprietary tools they wanted, they would be in an equal or perhaps even worse mess. But the $0 price tag means that this can go on without the normal control by management and purchasing departments. So indeed this has to be brought under control, and all companies need policies on software acquisition that make clear what is and what is not allowed.

Is an appropriate policy reaction to forbid the use of FLOSS entirely? No. In the first place there are many situations where you would be completely stuck, e.g. embedded chips where the only available compiler technologies are open source GCC based. Second, such a policy makes no sense. If we compare FLOSS and proprietary software, we find that there is great/horrible software in both categories, great/horrible support in both categories, and appropriate/inappropriate licensing terms in both categories.

What you need are policies that only permit the use of appropriate software; whether it is FLOSS or proprietary is really a secondary consideration. First you need to check licensing conditions carefully, and educate your programmers on proper usage in this regard. Just because something is FLOSS does not mean you can use it freely without any limitations. Although the concern that somehow you can lose all your intellectual property (IP) rights by using FLOSS is bogus nonsense spread by large companies developing proprietary alternatives, it definitely is the case that, just as with proprietary software, you can find yourself in copyright violation situations if the licensing is inappropriate, and that's bad enough!

Further, you need to carefully evaluate any potential tools or libraries that you consider using, and this needs to be done with care, considering quality and reliability of the software, suitability to your needs, quality of the support, track record in developing useful new capabilities, etc. This is a difficult task indeed, and FLOSS does not somehow make it magically easier, but it also does not make it more difficult!

We live in a software ecosystem where FLOSS plays an increasingly critical part. Learning how to take maximum advantage of everything that is available in this ecosystem is a critical part of effective software development, and every manager and programmer needs to be aware of how to make best use of all available tools and components, including most certainly those that come from the FLOSS world.

Robert B.K. Dewar is President of AdaCore.

AdaCore www.adacore.com @AdaCoreCompany linkedin.com/company/adacore