Do you really need the 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 he uses, the answer will almost certainly be - of course. It is the same with any purchased software. Is such an answer reasonable for all cases and why is the source code sometimes necessary, and sometimes its presence is 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 is always evaluated as a strong factor.

The availability of the source code does not mean that it is delivered 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.

The development of iron. 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 microcircuit and developing its application, the engineer relied on specifications that specify the functionality, pin layout, power requirements, etc. Nor did anyone expect to see the complete scheme of the internal arrangement of the IC, although they could often see the block diagram (mainly as an illustrative material that facilitated understanding of the principles of operation), and sometimes even a schematic diagram (for analog ICs of the OU type), although without denominations.
The engineer who is currently developing ASIC or FPGA firmware is likely to use some ready-made IP blocks - a pre-packaged block that provides certain 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 should be selected, considering the possibilities of future technical support. For example, when choosing an IP, the use of unique products from the same manufacturer should be avoided, which can alleviate problems during supply failures.
When using IP, whether it is hardware or software supplied, supply failures per se can hardly occur (except in the case of one-off 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 better to ask before choosing a specific implementation.

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

Setting up the software. The main difference between embedded systems and desktops is the variability of the first. Most PCs are similar to many others and the choice is only between the execution environment: Windows, Mac, or Linux. Embedded systems, in turn, are incredibly changeable — various processors, memory configurations, and peripheral devices. As a result, the IP software must be flexible so that it can be deployed on different systems. Although many products, such as RTOS, are delivered in binary form — usually a library that is configured for a specific architecture, the requirements for source code delivery can drive vendors, eliminating the need to preserve and maintain numerous variations, since the provision of IP as 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, the header file is edited to determine the configuration.

Certification. For some types of applications, such as military / aviation and medical, the firmware must be certified for safety and compliance with various standards. This process is complex and expensive and usually entails checking every line of code. Therefore, it is usually impossible to buy “pre-certified” software blocks, since the entire application is the subject of consideration. Thus, the developer of critical applications is likely to look for IP, which is available along 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, the discussion of any aspects of its presence (or absence) turns into a somewhat strange occupation. The answer may seem obvious: the source code of a program is a set of files containing instructions in a high-level language or assembler that can be compiled and assembled into functioning binary instructions. Immediately the question is - are the programs needed for the conversion process and the execution environment for them being part of the source code (in binary form)? Nevertheless, at least 3 forms meet this definition, in which the “source code” can be supplied (for example, let's talk about language C) in order of quality deterioration:
1) Indeed, the source code, with a good layout, clear conventions for naming variables and well commented out (provided that this is the case with the IP developer, which is completely optional).
2) Lines of code that will compile successfully, BUT without comments or especially meaningful identifier names.
3) Code lines after obfruskatsii, which makes the code unreadable by a person, but at the same time acceptable to the compiler. This is done by replacing identifiers with meaningless names and removing all comments and syntactically unnecessary spaces. There is a reverse process, but its results can hardly be called acceptable.
All of these forms are used by software vendors for the following purposes:
1) is what most buyers expect to receive and what many manufacturers actually provide. However, when making a purchase decision, if you require source code, it is important to make sure that this is exactly such an option, if in doubt, just ask for samples.
2) is usually used when the seller wants to deliver the required minimum, which can be (only) good enough for certification.
3) used to protect the contents of the IIP from prying eyes, which means that the software takes advantage of configurability, but no more.

Source code flaws.
The biggest disadvantage of having source code available is: this is a strong temptation. Every 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 to be optimal for the application, the availability of the source code provides the ability to change it.
Although it may seem that making an application optimal is great, but there is a problem of long-term support. What if there is a problem with RTOS functionality? The supplier will not support the modified product. What if a new version of RTOS is released? Including it in the redesign may require considerable time to make re-modifications, especially if their author no longer works for you (well, or you made these modifications 3 years ago and naturally, or, as they say, of course, did not bother with writing the relevant 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 supplier who can offer long-term support, the availability of source code is not relevant and may even be a flaw.