Do you really need source code?

In many knowledge, many sorrows

If you ask any firmware developer if he wants to have access to the source code of the real-time operating system that he uses, the answer will almost certainly be - of course. This is exactly the case with any purchased software. Is such an answer reasonable in all cases, and why is the source code sometimes necessary, and sometimes its presence less useful than expected?

There are a number of key criteria that engineers apply when choosing a real-time operating system (RTOS). Many of them - cost, functionality, licensing, support - are undoubtedly very important (especially cost - these are our realities). However, another criterion - the availability of source code - may not be so important, but it is always rated as a strong factor.

The availability of source code does not mean that it comes automatically and free of charge. This approach is valid only for open source products, and in other cases, manufacturers may charge for the source code or make it available on request.

Iron development. There is also source code here, which is especially true for development using VHDL and Verlog. How are you doing here? Historically, when choosing an integrated circuit and developing its application, the engineer relied on specifications that indicate functionality, pin layout, power requirements, etc. And while no one expected to see the complete circuit of the internal structure of the IC, although they often could see a structural diagram (mainly as illustrative material that facilitated understanding of the principles of operation), and sometimes even a circuit diagram (for analog ICs of the OA type), although without denominations.
An engineer who is developing an ASIC or FPGA firmware today is likely to use some predefined IP blocks - a pre-packaged block that provides some functionality. In this case, the choice will be based on specifications, and it is not at all obvious that the original HDL for IP will be included in the package. This black box approach is well known in the hardware world.

Security. Any technology that is included in the product must be selected, taking into account the possibilities of future technical support. For example, when choosing an IP, you should avoid using unique products from one manufacturer, which can mitigate problems in the event of supply disruptions.
When using IP, whether it is hardware sides or supplied software, supply failures as such are unlikely to occur (except in cases of one-time licenses), but ongoing support should be present. Therefore, the question of whether your supplier will be in business throughout the life of your product is best asked before choosing a specific implementation.

If the source code for IP is available, this makes it possible to solve any (well, almost any) problems with the software, even if the provider is no longer able to offer support. For this reason, many buyers of RTOS, etc. would like to have the source code on the shelf, even if they never look at it, just in case.

Software setup. The main difference between embedded systems and desktops is the variability of the former. Most PCs are similar to many others, and the choice is only between the runtime environment: Windows, Mac, or Linux. Embedded systems, in turn, are incredibly volatile - various processors, memory configurations, and peripherals. As a result, IP software must be flexible so that it can be deployed on various systems. While many products, such as RTOS, are shipped in binary — typically a library that is configured for a specific architecture, source code delivery requirements can spur suppliers by eliminating the need to preserve and support multiple variations, since providing IP as a source solves many of these issues. The user can build code for a specific processor, adapt to the device’s memory card, and add the necessary device extensions. In some cases, the IP block can be configured using conditional compilation - as a rule, a header file is edited to determine the configuration.

Certification For certain types of applications, such as military / aviation and medicine, the firmware must be certified for safety and compliance with various standards. This process is complex and expensive and usually entails checking each line of code. Therefore, it is usually impossible to buy “pre-certified” software blocks, since the entire application is the subject of consideration. Therefore, the developer of critical applications is more likely to look for an IP that is available with the source code so that a full check can be carried out.

What is source code?
The question may seem strange, but without an answer to it, a discussion of any aspects of its presence (or absence) turns into a somewhat strange lesson. The answer may seem obvious: the source code of some program is a set of files containing instructions in a high-level language or assembler, which can be compiled and assembled into functioning binary instructions. Immediately the question is - are the programs necessary for the conversion process and the runtime for them part of the source code (in binary form)? Nevertheless, at least 3 forms correspond to this definition in which the “source code” can be delivered (for example, let's talk about the C language) in order of quality deterioration:
1) Indeed, the source code, with a good layout, clear conventions for naming variables and well-commented (provided that the developer has such an IP, which is completely optional).
2) Lines of code that will compile successfully, BUT without comments or particularly meaningful identifier names.
3) Lines of code after obfrusion, which makes the code unreadable by a person, but at the same time acceptable to the compiler. This is done by replacing the names of identifiers with meaningless ones and removing all comments and syntactically unnecessary spaces. There is a reverse process, but its results are hardly acceptable.
All of these forms are used by software providers for the following purposes:
1) is what most buyers expect to receive and what many manufacturers really provide. However, when making a purchase decision, if you need the source code, it is important to make sure that this is exactly the option, if in doubt, just ask for samples.
2) it is usually used when the seller wants to deliver the necessary minimum, which can be (only) good enough for certification.
3) it is used to protect the contents of IIP from prying eyes, which means that the software takes advantage of configurability, but nothing more.

Disadvantages of the source code.
The biggest drawback is that source code is available: it is a strong temptation. Each developer wants to make their software as good as possible (well, there is such a point of view). So, for example, if the RTOS API does not work exactly so as to be optimal for the application, the availability of the source code provides an opportunity to change it.
Although it might seem that making the application optimal is great, there is a problem with long-term support. What if there is a problem with RTOS functionality? The supplier will not support the modified product. What to do if a new version of RTOS is released? Including it in the redesign may require considerable time for repeated modifications, especially if their author no longer works for you (well, either you made these modifications 3 years ago and naturally, or, as they say, of course, did not bother to write the corresponding documentation).

Having considered situations in which the source code may be desirable, useful or necessary, it should be concluded that it is not required unconditionally and always. If you buy IP from a large, well-known and stable provider that can offer long-term support, then the availability of the source code is not relevant and may even be included in the shortcomings.