Support FOSS

4 - 5 minutes read, 1089 words
Categories: foss
Keywords: build system foss

When working on a larger project (professionally or for fun), often one resorts to external libraries or other tools for offloading some work.

Most of the time, some of these tools will be open source. It could be the text editor, the operating system, some linked library, the compiler, the build system, or maybe some command line (or graphical) utility.

As we do not live in a perfect world, chances are that some dependencies might not work exactly as we want them to.

The common issue with third-party code is the lack of control of what the dependency does or how it does it.

What if the dependency does not behave as we want? Depending on the situation there are different possibilities.

If the tools take for input the data in a specific format we might need some preprocessing. If it outputs data in a format we do not want we need to do some postprocessing.

In the case of bugs, we need to find a way to circumvent them or see if a different version does not have the same issue.

Some websites claim FOSS software should be supported for ideological reasons. Most claims are "it is the right thing to do", that "you should give back", and so on.

Actually, there are practical reasons why it makes sense to use and support FOSS.

Cost factor and license compliance

Most FOSS programs do not cost directly in money, many are available for free. Most licenses require to give something back if a "modified" version is released. This is, after all, a very small price to pay. And if we are going to use, not release, those programs, in fact, we have nearly no obligations.


If the source code is not available, and the team behind the software ceases to support or develop it, it might not work on the newer version of your operating systems, or combined with other tools. Also, bugs will not be fixed.

This risk exists for all types of programs, but at least if the source code is available it is possible to step in.

Modifying and adapting a dependency

Generally speaking, with an open-source dependency we can at least try to fix or enhance the dependency and add the missing functionality, or improve the existing.

This might also be possible with closed-source programs, for example with reverse engineering, but it is generally more difficult. Also closed source licenses are generally less permissive than open-source licenses, so it might not be legally possible.

Another alternative is contacting the author(s) and ask for implementing the change(s). This is possible for both proprietary and free programs.

Supposing that we need to modify the open-source component by ourself we might have a patch file or something equivalent.

It does not matter how we achieved the change, we need to make sure that it does not interfere with other functionalities provided by the tool.

If we are lucky there is a test suite or something similar that can help us to augment this confidence. Nonetheless, there is a certain risk.

From a programming perspective, this is it, but there are other things we need to pay attention to.

For example, we need to comply with the license. With some licenses, it means that we need to publish or somehow make all our changes available.

The annoying part is when updating those components. All the work we have done for creating and publishing the patch needs to be revalidated every time.

Best case, we do not need to make any change.

Worst case, the changes we made are no longer possible. Now we are stuck with an older version and might need to replace it with something else to support new use-cases.

In other cases, we might need to implement our changes again.

What does supporting FOSS mean

Does support mean spending money? No.

Does it mean spending time? Normally less than not supporting.

Invest other resources? Some, but generally less than not supporting.

Some companies organize a mail address or a phone number to contact for requesting the patches. Either way, managing those patches will cost some resources.

What does, for me, mean to support FOSS projects?

  • reporting bugs

  • develop and merge patches (can be source code, documentation, …​)

It can, depending on the context, mean much more, but this is, for me, the minimum work one should do to get the most benefits from a FOSS project.

Non-supporting means just complying with the license, like making the patches public or show the license notice. Those are legal obligations.

Other advantages

By reporting errors and contributing back, there are multiple advantages.

  • It can make a good impression for future developers, especially FOSS enthusiast, or some programming communities

  • It removes some friction when working with the external library, or program

  • It reduces the amount of work, as there is no patch to maintain and nothing to organize to make it available

  • It reduces the risk of breaking the dependency

  • It makes it unnecessary to work around some bugs

  • It reduces the risk of build errors, especially in the case of a library used in multiple places

Merging the created patches might require some work (adding test cases, adhere to coding convention, do other changes) and take some time. But once the patch is merged, you have literally offloaded the work to someone else (for no extra charge).

It also simplifies the build system/process, because you can use the official library unmodified. It thus makes certain types of errors, like using the patched version in one place and the unpatched in another place, impossible.

It also ensures an overall better quality. Not only your workplace applied its quality process to the patch, but also the authors of the library.

given enough eyeballs, all bugs are shallow

— Eric S. Raymond
in The Cathedral and the Bazaar (1999), also known as Linus’s law

Most important, it ensures that the patch passes current and future unit-tests of the library.

Indirectly, it also has other benefits. Instead of creating a wrapper that undoes some work done by the library, or adds missing functionalities, as if it would b a black-box, modifying the library ensures that developers know better the dependency they are using.

Thus if the project dies, or takes a lead the company does not like, it is easier to make a fork and maintain it.

And as it is open source and public, there is also a chance that other people will contribute to the fork, even for free!

Do you want to share your opinion? Or is there an error, same parts that are not clear enough?

You can contact me here.