What could be done to support Open Source maintainers?

Yesterday’s story about the inception of the xc/liblzma vulnerability went viral. At the end of it, I said things need to change. We need to find ways to support Open Source maintainers. But I didn’t say how. I didn’t offer a solution because I don’t think there is a single solution. I left the question open to elicit discussion.

And there was lots of discussion. The massive majority of it was surprisingly constructive. One comment stood out above all the rest: companies building businesses using Open Source projects should support the maintainers more.

So, let me take this moment to talk to my corporate brethren. If you are a developer, manager, or CTO/CSO/COO/CEO of a company, I’m talking to you.

Before we start, for the last 10 years, I have been the CEO of a small company that supports the Open Source project I’ve maintained for 20 years. Before I was CEO, I was a Principal Software Developer at Microsoft for 12 years. I am intimately familiar with both the corporate and Open Source worlds.

Let’s start with the most important part of our conversation.

Know your Maintainers

If you write software today, you depend upon Open Source software. So, the most important question is: Do you know who maintains the projects producing the Open Source software you use?

Unless your team maintains a fork of the project, the project’s maintainer is a direct contributor to your product.

• For the Managers: that means you have at least one remote software developer on your team whom you do not meet with regularly and whose schedule does not align with yours. In fact, chances are good that your team only interacts with this external contributor if something goes wrong. It is possible you do not even know their name.

• For the Executives: your company could easily have hundreds of unnamed vendors supplying software for your products, and they don’t even know you exist. That means you have no relationship to resolve problems should they arise. Even worse, you have no insight into the health of the supplier. This part of your supply chain could produce very nasty surprises.

Your initial reaction might be to lock everything down. On one extreme, you could ban the use of Open Source in your company. On the other, you could try to require every Open Source maintainer to sign a contract so they align with your corporate requirements and timelines. Both extremes have problems.

First, Open Source has proven to be a very effective development methodology that harnesses the collective expertise in a problem domain and solves it. Open Source projects often grant access to expertise that is simply unavailable within your company. Banning access to Open Source projects would be a huge competitive disadvantage.

At the same time, the maintainers don’t work for you. They will have no interest in complying with random corporate demands. (We will explore options that may address these challenges later.)

In both cases, the first step to remove Open Source surprises from your supply chain is the same:

You need to establish a relationship with the maintainers for each Open Source project you depend on.

You probably also need to establish relationships with the maintainers of the projects those projects depend on… unless someone agrees to aggregate those relationships for you. The transitive closure of your Open Source dependencies is the number of relationships you need to account for.

Next, you introduce yourself. Most consumers hide behind Gmail addresses. Don’t do that. You need to establish a working relationship. What sort of working relationship you get will depend on how the maintainer responds. But here are a few scenarios that are common.

Pay your Maintainers

Not all maintainers want to be paid. However, those that do may be the most direct solution for your supply chain integration. Paying maintainers can take many different shapes. Here are a few options:

1. Purchase a support contract - This option allows you to treat the Open Source project like any other software supplier. It tends only to be available from larger Open Source projects as the maintainer must invest in non-software development infrastructure (i.e., a company of their own).

2. Hire the maintainer full-time - This option requires the maintainer to want to be hired, but it places them on your staff and on your schedule under your corporate requirements. It is important to come to terms with how much time the maintainer continues to contribute to the Open Source project vs. company work.

3. Hire the maintainer part-time - This option makes the maintainer something of a consultant for your company.

4. Sponsor the maintainer - This option is a gesture of goodwill with no expected return. The goal is to support the maintainer with the hope they stay engaged with the project. This may be the only option to pay maintainers of smaller projects.

These are the most common scenarios that I’ve seen in use today. There were also some fascinating proposals that deserve experimentation in the future (example 1, example 2, example 3).

For those maintainers that do not want the responsibilty that comes with taking payment, you need to stay involved in the Open Source project’s community to help care for the maintainer.

Care for your Maintainers

Being present in an Open Source project’s community is incredibly important, especially if you cannot establish a business relationship with the maintainers. Maintaining software is arduous, where one faces only failures: fixing bugs and responding to consumers complaining about bugs.

Kind words can go a suprisingly long way, especially given today’s online discourse. Some examples off the top of my head:

1. Defend the maintainer - entitled consumers can be demanding and sometimes abusive. Directing abusive consumers to be more kind to their fellow humans will help maintainers feel less isolated and attacked.

2. Celebrate shared successes - thank your maintainers for their contributions when your product reaches major milestones. This assumes your relationship is well established and the maintainers will not feel uncompensated.

3. Promote your maintainers - invite maintainers to speak to your company or your industry and give them a platform to share their work. Even better, pay for flight and accommodations to attend.

Creative minds will surely come up with additional options to support maintainers when directly paying them is not an option.

The importance of Relationships

It’s a cliche to talk about the importance of relationships in business. Thousands of pages in books are written about customer, client and employee relationships. You need to think similarly about Open Source projects and the maintainers that care for them. Consider the above page one.