For close to 25 years, I have been dealing with trying to develop and maintain computer systems over long periods of time. In dealing with the longevity issues, I have been suffering through the use of closed source firmware inherent in GPUs, BIOS, WiFi, Bluetooth, etc. in particular, and closed source in general.

For the first 20 years, I was very patient. I realized that companies had business plans, and they did not know or trust Free and Open Source Software and Hardware (FOSSH) business plans. Some had contracts that they had signed as they bought and sold intellectual property (IP). Some companies could not expose the sources of the software they bought because of the contracts they had signed with the software or hardware providers. Who could possibly have the expertise to maintain the software provided with the hardware or produce software better than the manufacturer, right? Read that last sentence with sarcasm turned fully on.

In the late 1980s, Digital Equipment Corporation (DEC) had a world-class X Window System server that worked with "dumb frame buffers." The engineer who wrote the code refused to support shipping the source code due to the IP that was inherent in the X server. DEC was losing millions of dollars of sales, because we did not make our X server code available.

I flew to California from the East Coast to talk with the engineer. I asked him to go over each and every part that he felt was unique and tell me if any of our competitors (who all allowed customers access to their X servers) had that particular IP. It finally turned out that the only IP that was not in our competitor's X servers was a routine that was hardly used by anyone. When asked if this little-used piece of code was worth losing millions of dollars in sales, the engineer agreed to ship the source code.

Over the past five years, I have been working with a few hardware projects such as Caninos Loucos [1]. I have also been looking at lots of single-board computers (SBCs) from various organizations. I have a large plastic bin full of them, most of them using ARM architecture, while some use Intel or AMD. Some of the companies that made these SBCs are out of business. Some are still in business, but they have moved on from creating updates to their drivers that would allow these boards to work with more modern versions of the kernels.

These SBCs will become useless over time as the various kernels are updated with new features, new security fixes, and new device support, simply because the source code for these pieces of firmware are not available. Personally, this is an annoyance. However, for people who bought these systems hoping that they would be useful for a reasonable period of time, it could mean huge losses of money, because they were not buying the units just for evaluation (as I did); they wanted to use them in education, or manufacturing, and therefore purchased hundreds or thousands of them.

One small company I know sold 60,000 of their units to various people with version 3.x of the Linux kernel running on them. Now, about a year later, version 4.x is the mainstream kernel, and the binary device drivers that came with the 3.x-based system are close to useless. This includes the firmware for the GPU, the WiFi driver, and the USB driver, as well as some of the bootloader.

Most of these hardware devices are still viable for use, but because the devices themselves are "end of life," the manufacturers are not interested in upgrading the binary drivers for the newer kernel. Even if they were, the same issue would probably come up as the hardware moves through newer versions of the kernels.

On the other hand, the vendors could "open up" the hardware interfaces of the different devices by telling FOSS device driver writers how the registers and chips actually work. The FOSS community could maintain these components as long as the community desires.

The computer industry has changed over time. Significantly powerful, cheap computers allowed groups like the Linux kernel developers in the 1990s to develop a full-fledged kernel without having to buy a multi-hundred-thousand-dollar computer to do the development.

Today there are groups of people, such as the University of California's RISC-V project, who are designing and manufacturing full-scale open CPUs, with other groups developing GPUs and other sophisticated processing units, producing them in open FABs.

These groups understand that opening up their hardware interfaces to FOSSH programmers will allow a greater number of sales. Users of GPUs, WiFi chips, USB devices, and SBCs will now stop using closed, proprietary chips in their products in lieu of ones that can be supported properly.

This is not a threat, but a promise.