Maintaining several open source projects, over the years, I’ve seen a common request. That the project either produce builds or a wider variety of builds. For example, to build for a new architecture or to provide the software as a container or Helm chart. I see a couple common expectations. First, that the open source project is the right place to do the builds. Second, that a project isn’t open source if it doesn’t do this. Both of these are just not true.

Having had three requests for build situations in the last quarter, it might be a good time to think through this.

Consider curl

Just about every developer has used curl at some point in their career. Sometimes they didn’t realize it because they were using something built on top of it. curl is an amazingly successful open source project.

Have you ever considered where you get your builds from? They are likely from the operating system provider or a package manager like homebrew. There are so many places you can get it from that curl has a Download Wizard. This wizard helps you find the right place to get the build for you. It points you to others who provide the builds.

curl isn’t the only example. Another simple example is the Linux kernel. There are many more beyond this.

Why Do We Expect Builds?

I’ve been told that something isn’t open source if you don’t provide all the builds all the time. It’s open soure software not open build software.

So, why do we expect builds? I see three places that have made them very common:

1. Venture Capital funded open source companies who are shooting for growth. They provide builds to make things easy.
2. Foundation based projects, like those from the CNCF. They often produce builds. But, the build you run may not be built by the project. You just might not realize it. Consider hosted Kubernetes as an example that is sometimes built by the host.
3. The availability of build systems, like GitHub Actions, has made it easy to produce builds and make them available for download.

The ease of producing builds and some business cases have made builds more prevalent.

Why Wouldn’t A Project Provide All The Builds?

If they are easy to do, then why wouldn’t a project want to do them or want to limit them? As a project maintainer, I’ve seen a few reasons:

• You have to do the maintenance work to keep the builds working properly. Any time you add more build work it adds more to do. And should you really just build on a platform or should you test there, too? Often you should test there. This means more work. It’s not always a simple change.
• You end up needing or wanting to support those builds. This can add more to your support queue. Is the project really up for that?
• Sometimes there are competitive situations going on. For example, what if maintainers work for different companies offering base container images that you could ship your application on? How do you pick the base image?

I’m not trying to produce an exhaustive list. The idea is that there are legitimate reasons for not producing builds or not adding one more target output.

Why Might You Want A Build Not From The Project

If someone else produces a build of an open source project, should you use it? Are there good reasons for others to produce them?

First, you should always trust the source before using it.

There are many reasons to get something from a 3rd party. To illustrate this I’ll provide four of the many examples.

1. There are many pieces of open source you get with your operating system. That makes it easy and they will sometimes make sure the build works with other things on the system. For example, some Linux distros will work to manage conflicting software. This is a benefit. But, it only touches on a small percent of open source software.
2. Some regulations require people to use builds that meet certifications, such as FIPS-140. Due to the cost around these certifications, this isn’t something you’ll usually get from an open source project. But, a company may do builds that support this.
3. If the open source project is producing builds but not providing security guaruntees, like those around SLSA, you might want to get from a source that does.
4. Builds that are generated more securely than SLSA Build Level 3. If you think L3 is the pinnacle of build security, let me share that there are ways of building that add more layers of security. Some of these showed up in early drafts of SLSA levels but were not clearly defined. Some build systems implement these features. An example of this is the build system that lets SUSE produce SUSE Linux Enterprise Server (SLES) in a manner that meets Common Criteria EAL4+ certification.

If one of these reasons isn’t for you, that’s ok. It is for some people and businesses that use open source. It can be helpful to know the needs of others.