I was going through some old notes and came across some notes from a brainstorming session around contributing to open source projects. With all the different apps that we’ve worked on over the years, there wouldn’t be any that didn’t involve at least one open source project. Whether it be a framework project, like Mvvmcross, or a simpler helper libraries, it’s hard to imagine how we ever managed to build software, at pace, prior to the collective contributions made to open source projects. However, despite the fact that so many companies, teams and developers rely on open source software, it’s a constant battle for open source maintainers and contributors. In this post I’m going to cover some thought I have around contributing to open source, and a set of questions for working out which projects you, your team, or your company should be contributing to.
Let’s back up a bit and talk about why open source projects struggle. Before we do this though I’m going to narrow the scope of this discussion a bit. The focus of this post is open source projects that are not what I’d call enterprise open source – by this I mean open source projects that are not funded and controlled by any individual company.
Without a company backing an open source project, there is of course no funds, or minimal funds, to support the ongoing development and maintenance of the project. In other words, in order for the project to continue, it relies upon the ongoing contributions by the maintainers and other contributors. This isn’t usually a problem during the early stages of an open source project, where there’s lots of excitement and drive to deliver a high quality first version. However, over time, contributors (and particularly maintainers) get burnt out because there are unrealistic expectations placed on them by the community of developers that use the project. This is the point where open source projects struggle and often collapse, as the key people involved walk away.
In this post I’m not going to delve much into the topic of software assurance or dependency management but suffice to say that if you build an application or service that uses an open source project, you’re taking a dependency on that project and you need to be aware and manage that dependency, and the risk that goes with it. Each open source project will be structured differently, have different process and will have different options for support. When you take a dependency on an open source project, it’s important to understand the nature of the project and the potential risk that it may have on the software you’re building. As the number of dependencies increases, the ability to manage these risks can be quite difficult, so it’s important to focus on those projects that have the highest potential impact and where your contribution can affect the project.
Let’s try to drill into this a bit more and to do this I’m going to look at a series of questions that can help you decide how to manage any dependency you have on open source projects.
Influence
Can you influence and/or contribute to the open source project?
In this question I’m not asking whether you can raise and issue, or perhaps contribute singular pull requests, I’m asking whether you, or anyone in the community, can affect the direction of an open source project?
A version of this question that’s easier to answer is whether an open source project is being directed by any individual company (i.e. whether the project would be classified as Enterprise open source). For example, dotnet and maui, are examples of project that are being paid for and directed by Microsoft. Prism and MvvmCross on the other hand are not, and as such the direction is determined by the maintainers of the project, rather than a corporate overlord.
If an open source project is backed by a company, it significantly reduces the risk that the project will cease to be maintained. However, it’s not always the case – there are plenty of open source projects that large companies like Google and Microsoft have shelved, even when there are plenty of developers that are depending on the project.
It’s also worth noting that if an open source project is being directed by a company, it’s less likely that they’ll accept significant community contribution. Again, I’m not talking the occasional PR to fix and bug, or provide incremental features; I’m talking contribution to the direction of a project and making substantial changes/contributions to the project. Often companies that back a project won’t manage the project in the open, with development done in a separate internal fork, before being pushed to the public repository. This makes it hard to accept substantial contributions from the community.
In order to reduce the risk associated with a company backed open source project it’s worth looking into how strategically important a project is to the company. For example, if you consider dotnet, Microsoft is unlikely to walk away from it after decades of investment. The same can’t be said for Maui – If Maui (and by association Xamarin.Forms) was to be discontinued, there would be a handful of developers that would be bent out of shape and it would probably reduce the number of .NET developers who would build apps for iOS and Android but would this be a significant strategic loss for Microsoft. The question you have to reconcile is how likely is it that Microsoft will continue to back these projects, both in the short term (1-2 years) and the long term (5-10 years).
The strategy for managing company backed open source project is to only use those projects where the risk of the company discontinuing the project is below your acceptable risk level.
An alternative, for high risk projects where the entire source code and process for building the project is available, is to base your software off a snapshot of the open source project. This ensures that even in the case of the project being disbanded, you still have access to the dependency.
Capacity
Do you, your team or company have the capacity and/or capability to contribute to a project?
Assuming that we’re talking now about project that aren’t backed by a company and where you could, in theory at least, influence the direction of the project. The next question becomes whether you, your team or company, has the capacity to contribute to a project. If you don’t, it may be necessary to contribute financially to help ensure the viability of the project.
Depending on how a project is structured, contributing financially may give you some sway over the direction/priority of features and bugs – please make sure you check with the maintainers as I know this is a sensitive topic and I don’t want you to assume that just because you contribute financially, you’ll have any more rights over the project than anyone else.
Contributing financially to a project is actually one of the lowest cost mechanisms of contributing. Of course this is dependent on the amount you contribute but if you measure it against the daily cost (including lost revenue) of having a developer work on the project, making a financial contribution to a project can be the cheapest option.
Strategic Importance
Is the project of strategic importance to you, your team, the project, or the company?
Of course, answering this questions depends on how you define “strategic importance” so let me start by giving an example. For a while, every cross platform application we built used the MvvmCross framework to reduce the hassle around doing basic things like navigation. Unlike other libraries, that we mixed and matched based on the nature of the application we were building, MvvmCross was strategically important as it formed the basis of many of the apps we were building. As such, we made the decision to invest heavily into MvvmCross and for a while I was an active maintainer on the project.
Over time, our needs changed and we shifted focus. Whilst we still had applications that relied on MvvmCross, we had other priorities and MvvmCross was less strategically important to what we were working on. Our involvement with the project dropped back to being a contributor.
I guess the point I’m making is that if an open source project is so intrinsic to what you’re developing, you should probably step up and be either a regular contributor, or consider volunteering to help as a maintainer. Again, different projects handle this differently but most projects won’t turn back an offer to contribute more in the name of building a more sustainable project.
Summary
I’m going to leave this post here but ask each and every one of you to be more mindful of the open source projects that we rely on every day in the software we create. Think about how you, your team or your company could contribute back to all the projects that help you be a more productive developer.