Whether you are sailing a ship at sea or shooting a rocket into outer space, you often have course corrections. A couple of people in the press and in personal conversation have recently made statements which indicate that people need a "course correction."

One example was in a loud discussion about the amount of bugs or security issues that exist in "open source" (and I use that term specifically rather than "free software") and how this is somehow big news. This has led to additional discussion about the need for a Software Bill of Materials (SBOM) which indicates what pieces of open source appear in the products of companies. Don't get me wrong, I think an SBOM is a good idea, particularly if it could be done easily and almost automatically through the software build process. However, people talk about "the bug problem" as if it were solely the problem of open source and that it has not been a problem of all software throughout time.

When software was a lot simpler, people could wrap their minds around the code and (with a couple of good engineers) manage to keep a hand on the libraries and environments. However, I have worked for closed source companies where large portions of code were not reviewed by software engineers over large periods of time, because of a lack of resources. I have seen large amounts of code not covered by test scripts or regression tests. It happens in both free and open source software (FOSS) and closed source, but "FOSS" or "Linux" are the names that grab attention.

The difference with open source (and particularly free software) is that the code is exposed to many eyes and is available for patching when the problem is understood. Closed source code (or closed source that uses open source components) cannot be patched by the end user. The end user must rely on the company that produced the closed source product to get the patch, and that assumes the closed source company actually produces a patch for that software.

I do not mind that the press and pundits point out that there are bugs in FOSS. I do mind when they somehow imply that this is a problem with FOSS and not also problem with closed source.

Somewhat tied to this is a recent incident where an open source developer purposely put a bug into the code they were developing, ostensibly because they objected to companies making large amounts of money off the code that FOSS people generate. This created a call for companies to compensate FOSS people for their work in the FOSS community.

While I applaud developers being paid for their time and effort in creating FOSS projects, and while I share the frustration of many people with multi-billionaires receiving their riches, making tens of thousands of times the money that "their workers" make, the motivation behind FOSS is not being paid for software that others use but to make the software that we ourselves need.

In the early days of computers, there were few, if any, "professional programmers," people paid to write programs. People wrote programs to solve their own problems and then often gave them away to help other people. Perhaps those other people would help to make the programs better.

Eventually there were people who did not know how to program who could use these programs too … and that was great. Software that no one uses is useless.

Shortly after the Linux kernel project was started a number of developers brought forth the issue of "companies making money from the software I write for free," and ways of making these companies pay for the software were considered. It was observed, however, that if this path was followed, then FOSS would move forward slowly, like a glacier. Some people left the project, and some were hired by companies that saw the value of hiring them, and some continued to write the software for their own purposes.

When I talk to programmers about becoming involved with FOSS, I first suggest that they pick an area of software that they otherwise have a passion for: audio, video, games, databases and data mining, word processing tools … the list is endless. They will learn more about their passion and perhaps be hired by a company that needs their expertise delivering on that passion.

Or you may anticipate that the software you are working on facilitates an industry where you can make money, but this is a lot harder and you have to be careful not to create a project that is not sustainable, both for you and the other people using it. However, we should not purposely punish users if we no longer get satisfaction out of our software development work.

The press and pundits are insinuating these are only "open source" issues, and they are not.

Let's keep them honest.