Open Source Sustainability

Open source software is awesome. And I depend on it for quite a lot. Even writing and publishing this blog post relies on several different open source efforts. I’m typing this blog post using an open source text editor (Atom). The operating system that I’m using (macOS) is a commercial offshoot of an open source project (Darwin). We use an open source blogging engine (Jekyll) to power our website. We write our content in Markdown, and converting that content into HTML is handled by an open source project (Kramdown). We deploy our website to an Amazon S3 bucket, and there is an open source ruby gem (s3_website) that helps us do that.

Those are just the projects that I depend on directly. Each of those projects depends on other open source projects. The entire dependency tree of open source projects that I rely on every day likely numbers in the thousands. That’s a lot of open source.

Corgibytes focuses exclusively on making code better. So far, we’ve mostly helped out on closed source efforts. Our clients have been organizations that need some additional help making the great code that they have even better.

When I started Corgibytes, my dream was being able to maintain open source projects. And we’ve had moderate success so far. We built some small tools that we released as open source while working for clients (sftp_server, redacted_attributes, and encrypted_search_attributes). We’ve even been paid by an non-profit organization to make improvements to their open source project (otwarchive).

I’d love to figure out how we can do more work on open source projects. And I’d like for us to do so in a way that has a positive impact on the open source community at large. This is something that percolated in the back of my brain for over a decade. My interest was piqued even more after listening to The Changelog podcast’s Bonus episode about “Sustain Open Source Software”, a one day facilitated conversation about how more money can be imbued into the open source ecosystem with the goal of keeping it healthy.

I’m planning on going to Sustain. If you want to make sure that open source continues as a driving force in our lives, then I encourage you to go, too.

While I’m there, I plan on chatting about the different ideas that I’ve had for Corgibytes to provide services to help support open source projects.

I’m eager to get the conversation started early, so I’m going to outline a couple of my ideas here.

Patron model

One idea that I have is to ask organizations to band together to pay for a person to work full-time on a particular project. Perhaps your company is willing to contribute 10% of the funds needed to have someone work on Ruby on Rails full-time, because they depend on it so much. If there are 9 other companies in the world who are willing to do that, too, then Corgibytes could have a member of our team focus on that project.

We’d work on the project in the open. Helping out the community however we can help best.

We’d work on the things that we’re good at: improving documentation, paying down technical debt, tackling issue triage, nurturing the test suite, increasing reliability. And if the companies that are backing us would like us to focus on anything more specific, then we’d be happy to do that, too. We’d aim to be healthy contributors to that project’s community, and all of the work that we’d do would be towards that end.

To help provide some transparency about what we’re spending our time on, we’d work up a regularly published report which tells the story of where our efforts were focused. The goal here would be to communicate the value the project received as a result of our help. This is something that we do for our closed source clients, and they find it incredibly useful.

I could see us doing that for any number of open source projects. One thing that I’m not sure of is how we find the companies that are willing to fund projects this way. Another issue is finding projects that should be funded this way. I also imagine that there are some projects that need this help more than others. And some projects are going to be more receptive to this kind of help than others.

There is a weakness with this approach. What do we do if there isn’t enough interest to fund a particular project? Perhaps we get pledges to fund only 65% of a project but no more. Could we staff someone on the project part-time? Would that provide enough value?

Support contract model

Another idea is to have Corgibytes sell support contracts for specific open source projects. In addition to the work that we’d do under the patron model, we’d also provide some on-demand support for the companies that have purchased support contracts.

We could have service level agreements (SLAs) in place to provide different turn around times for different classes of issues. The support that we provide could be varied: helping answer a question about how to use that project, pairing on confirming that a bug exists, working on fixing a particular bug and getting a fix accepted by the maintainers, back porting a bug fix to a version that’s being used by the company that’s paying for the support contract.

Again we would aim to be healthy members of the community, but our primary focus would be on providing quality support to the companies that are paying for support contracts.

Open Source Insurance

Another idea is to model what we’re offering around the metaphor of insurance. We’d issue insurance policies that would cover the effort needed to address issues with specific projects. A claim against that policy could be for fixing a bug or back-porting an existing bug fix to a specific version or anything else that the policy specifically covers.

We’d be incentivized to stay active community members for the projects that we cover, because that would help us minimize the amount of time we’d need to spend to satisfy a claim.

I guess there’s really nothing preventing us from giving a combination of these offerings a try.

I’m looking forward to attending Sustain and exploring these ideas further. If you have any other ideas, please add them to the comments below, and I’ll be sure to take them with me. Also, I’d appreciate any feedback you might have about the different approaches that I’ve proposed.

I’ll also write a follow up blog post after I’ve attended Sustain. I want to document and share what I learn while I’m there. Look for that post to come out shortly after the event’s concluded.