Who needs source code?

• RTOS
• Software Development
• Miscellaneous

When I first started out writing embedded code, I was very attracted by the fact that I could do everything. I would start with nothing in the memory and fill it with code, which would bring the device to life - an almost god-like power! I gained great satisfaction from knowing that a system was “all my own work”. I could be confident that I was using resources quite efficiently, as the code contained only the functionality required for the application - no overheads.

Time mover on and embedded systems have become steadily more complex and sophisticated, resulting in an explosion in code size. It is rarely feasible for all the code to be written by a single developer - it would take too long and any individual is unlikely to possess all the necessary expertise. There are two results of this progress. First, software is developed by teams - sometimes very large teams - so that a  number of specialists can contribute their expertise and the total effort can be divided into manageable chunks. The other result is that it has become common practice to license reusable software components, thus freeing up the team to focus on the core functionality of the system being developed.

The first, and still about the most common, component to be widely used was a real time operating system (RTOS). As designs became complex enough that a multithreading model would be useful, many developers realized that this would be an ideal candidate for outsourcing and a number of RTOS companies were founded. This raised an interesting question: how should licensed software be distributed? (There was also the question of how pricing should be structured, but that is a story for another day.)

It is generally claimed that the first commercial embedded RTOS was VRTX, from a company called Hunter & Ready, which appeared in the early 1980s. At the time, it was thought that licensed software was essentially a component - just like the integrated circuits universally utilized by hardware developers. With this in mind, VRTX was initially supplied in PROM (Programmable Read-Only Memory) chips that could be plugged into sockets on the board along with the rest of the electronics.

As the RTOS market matured and the number of vendors multiplied, there was much debate about how best to distribute an RTOS. Broadly, two options emerged: binary code (which was most likely a position-independent object module or library) or source code. This resulted in much debate. Some companies decided to provide source code and others provided binary, but maybe offered source as an option.

The question arose: is having source code beneficial and, if so, how?

From the vendor’s point of view, providing source had the great benefit of making user configuration very straightforward. But the possible downside was the exposure of their intellectual property. The latter did worry some companies, but could mostly be protected (legally) with the right licensing agreement.

From the user’s perspective, having source was (and is) mainly considered a benefit. This can be for a variety of reasons.

It is comforting to know that code in your application will not be compromised in the event of the vendor going out of business or otherwise failing to deliver on their responsibilities. Even if you never look at the source code, it is nice to know it is there if you need it.

Some developers are very resistant to using :”black box” code - i.e. software with a very clear specification for input, output and functionality - even if their hardware counterparts regard this as just normal practice. Knowing that the code could be debugged in the event of issues is comforting.

Other RTOS users feel that being able to modify the code to their specific requirement is a benefit. This is very misguided, as they would end up with a non-standard, unsupportable RTOS.

If a device requires certification (for various applications like aerospace, medical or automotive), having source code is almost essential.

The above arguments may or may not be valid. If they are, it is best to ascertain the availability of source code. If it is freely supplied, that is great. If it is available at a cost, that should be considered. If it is unavailable, that may be a showstopper.

If there is no compelling need to have the source code, it may be argued that having it is a disadvantage, as it might be a distraction. Any well run business focusses on its core competencies, so embedded application developers should not concern themselves with the inner working of an RTOS. 

The final question is: what is source code? This might seem to have an obvious answer, but it is more subtle. I have encountered source code of three varieties:

1. Clear source code with some basic commenting.

2. Source code that is written with the reader very much in mind - very clear structure, identifier naming and commenting.

3. Code that is processed to make it unreadable by removing unnecessary whitespace and scrambling identifiers.

Of these, (1) is acceptable and (2) is desirable. But, what about (3)? This approach is adopted when the vendor simply wants to ensure easy configuration, but wants their intellectual property to be protected. I have encountered a user who purchased an RTOS with this type of source code and was surprised that they could gain no visibility into its functionality. As with many purchasing decisions, it is essential to ask the right questions.

At the end of the day, whether source code is needed or desirable depends on the specific project. The key requirement is to verify exactly what your vendor has to offer; ask challenging questions.

Sign in