Who needs OS source code?

It is an interesting question: when do you need the source code in order to reuse some software and when would binary [i.e. a black box] be quite satisfactory? With an embedded operating system the answer is far from obvious. There is even a question as to what source code really is.

If you ask an engineer whether he would like to have the source code for an OS or any other reusable software, the answer will almost always be a resounding “yes please”. I wonder why this is, given that, in many other aspects of life, a “black box” is entirely acceptable. For example, electronic engineers use integrated circuits without requiring their circuit diagrams; they are satisfied with getting the specification for their usage [and errata sheets, of course]. Another example is that I cheerfully drive a car with very little interest in what is happening under the hood.
Historically, software engineers have simply felt secure when they know that they have access to the source code and maybe that is reason enough. However, there are some more tangible explanations for why source code being available might be necessary.

An obvious possibility is system build flexibility. As all embedded systems are different, it is advantageous to start from source code to get the memory map exactly right. Having said this, an intelligent design of binary modules and a good embedded linker could achieve the same result.

If a system needs to be certified – as would be the case for medical or avionics applications, for example – the entire source code for the system needs to be available for scrutiny. It is generally not possible to independently certify the OS. So this is a situation when OS source code is required.

An interesting further question is: what actually constitutes “source code”? It can simply be adequately structured and commented C code. Alternatively, it could be code written, structured and commented to a high standard with the human reader in mind. This is obviously far preferable. The third possibility is that the source code is scrambled [white space  removed, identifier names changed, etc.] to render it quite unintelligible to the human reader, but still acceptable to the compiler. This is done by at least one RTOS vendor to enable them to take advantage of easy target configuration without exposing their intellectual property. The only lesson to learn here is ask before you buy. I know of a user who bought the “scrabbled RTOS” and was surprised to find that they effectively had no source code access.

If you are interested in the selection process for real time operating systems, you might like to attend a Web seminar that I am presenting on Thursday [it will be available as a recorded archive straight afterwards].