Most software is obtained as a binary executable. The program may run and does what it does, but the user has no knowledge of its inner workings and has no opportunity to modify its functionality.

And all of this is fine.

For example, I am writing this text using a MacOS program. Later, I will probably review it on my iPad using another app. The two programs are probably written in different languages by different teams.

Do I care?

Not at all. The important thing to me is the data (my text) and what the software does with it.

In the world of embedded software, things are a little different.

The difference is not with programs that are run on a desktop computer, compilers, debuggers etc. These are also normally provided as binary executables and used in much the same way as other application software. There are open source options, of course, but most users will never look at the source code. The different approach applies to software IP (intellectual property) code that is to be incorporated into a design. A good example of such IP is a real time operating system (RTOS).

Broadly speaking, RTOS products are either supplied as a linkable binary of some form (which is a "black box" – the user has no visibility of its internal function) or come in source code form, which may be perused and/or modified at will. Many developers feel strongly that having source code is essential and may cite some clear advantages:

• There is the opportunity to customize the RTOS to the specific needs of the project.
• Having the source is a good aid to understanding what the RTOS API calls do and how they do it, and how the scheduler works.
• As tech support maybe be needed urgently, having the source code means less reliance on other parties, like the RTOS vendor.

This all sounds logical, but I would counter that having the source code can have some downsides:

• Although it is superficially attractive to be able to customize an RTOS for specific purposes, it is a dangerous path. The result can be multiple versions of the OS, which are undocumented. When a new OS version comes available, it is a big challenge to re-apply the customizations.
• Habitual access to the source code may discourage using the supplied manuals, which are likely to be a much richer source of information.
• Understanding the internal workings of an RTOS is a specialist skill. Can you afford to support such expertise?
• Is there a strong reason why treating the RTOS as a black box is bad? Assuming it does what the manual/specification says, why do you need to know more? Hardware developers commonly use integrated circuits without any information on their internal functions.

The last point is quite significant. Why are software developers so untrusting of software provided by others? Does it say something about their faith in their own software?

Of course, you can select a product where source code is provided, there are several on the market, and lock the source away for emergencies.

There is an interesting, intermediate option where the code comes as source, but it is scrambled to render it unreadable to humans (i.e. effectively rendering it a black box, but with easier compile-time configurability). If you are buying an RTOS, that apparently comes with source code, you might want to ask awkward questions about its readability.