When did you last purchase a software product in the form of source code? I am guessing that the answer may be either never or a long time ago. Of course, open source products are available in source code, but the average user never sets eyes on it. With software intellectual property (IP) – libraries, networking protocol stacks, real time operating systems (RTOSs) – the availability of source code is very common. The question is whether you really need it. Would not the binary (i.e. a black box) be just as satisfactory? With an RTOS, the answer is not obvious. You might even start to question what constitutes source code.

Most developers, when asked whether they would like to receive source code for some software IP, would answer resoundingly in the affirmative. This is rather surprising when you consider how often a black box is acceptable in other contexts. Hardware designers use integrated circuits without demanding the schematics; they assume that the data sheet (along with errata) defines the functionality precisely. Surely this could apply to software? Another example is my car. I drive it confidently without taking any particular interest in what is going on under the hood.

Traditionally, software engineers have felt “secure” when they have the source code, even if they never have cause to look at it. Maybe this is a good enough reason to supply source, but maybe there are some more tangible reasons for its availability. First off, system build flexibility is eased by starting from source code. Every embedded system is different, so some kind of adaptation is needed, and this is most easily achieved starting with source code. Second, if the embedded device needs certification – such as in medical devices and avionics, for example – the entire source code is needed for the certification process. This includes IP components like an RTOS.

An interesting further question is “what is source code?” There are at least three possible answers:

1. Adequately structured and commented C code.
2. Code written, structured, commented and documented with the human reader very much in mind.
3. Scrambled source code: unnecessary white space removed, identifiers changed, no comments, etc. Unreadable by humans, but acceptable to compilers.

The first answer is common. The second is the preferable option. But why does the third even exist?

There is at least one RTOS vendor who opts for answer three. They reason that their IP is protected (as it would be if it were in binary), but the user gains the configurability benefits of source code. This is logical and acceptable, if buyers are fully aware of what they are getting.

Some years ago, I was talking to a prospective customer, who was considering a change of RTOS. He asked, “How easy is it to find the task stacks?” My colleague showed him on a debugger in a few keystrokes. He was delighted as he had been subjected to option three. We made a sale.