GitHub Sponsors extends GitHub’s role as the center of open source development, but it falls short of ensuring developers get paid for their work.
What we have here is a failure to communicate. Or coordinate. Or something. But in open source land, it’s tough to get paid. No, I’m not talking about open source vendors. I’m referring to open source developers. While some developers get paid by their employers to write open source software, many don’t, and burn out as a result.
GitHub just announced its Sponsors product, a way for companies or individuals to pay the developers working on the projects they love. It’s a nice gesture, and yet another example ofsetting itself up to be the center of the developer universe, but its tip jar approach isn’t likely to move the needle for open source developers.
SEE: Implementing DevOps: A guide for IT pros (free PDF) (TechRepublic)
Brother, can you spare a dime?
Open source has never been more popular, with tremendous depth and breadth of code available. This doesn’t mean that all of that code is equally well maintained. Many open source developers, after all, contribute as a labor of love.
Proving that no good deed goes unpunished, downstream users of such software aren’t always grateful. Even popular projects like npm can suffer from entitled users who “don’t love [the core contributors to those projects],” as npm’s former CEO Isaac Schlueter once lamented. It’s hard work building and maintaining great software. The work is made even harder by unrealistic expectations placed on unpaid (or underpaid) contributors.
As announced this week, GitHub is trying to make it easy for companies to sponsor the developers who write and maintain the open source software they love. As noted, “Anyone who contributes to an open source project is eligible to become a sponsored developer in the future. Contributions include but are not limited to bug reports, issue triage, code, documentation, leadership, business development, project management, mentorship, and design.”
Given how much open source development happens on GitHub, it’s a great move. It’s also not nearly enough.
For one thing, at least initially, GitHub Sponsors only allows individuals to sponsor developers. As CNCF executive Chris Aniszczyk warned: “[T]here are a lot of open source tip jar systems out there that put devs in a gig-style economy imho, I don’t think this will make much of a dent if it only relies on individuals.”
The problem is bigger than this flaw, which is easily remedied. What’s the problem?
A tragedy of the open source commons
The problem is that it’s hard for individuals or corporations to get excited about seemingly shouldering the entire burden of supporting a project contributor. It’s also hard to determine just how much should go to particular developers of a project, as well as to ensure one is covering all the dependencies of that project.
SEE: Software licensing policy (Tech Pro Research)
Say, for example, I want to sponsor Henry Zhu, who left his job at Adobe to develop Babel full-time. Yes, I can sign up to be a patron of Zhu’s work on Patreon, which currently amounts to $3,294 per month for Zhu. Great (though hardly sufficient to support someone living in New York City, as he does). But why should my company pay $1,000 per month instead of $5? How do I determine the appropriate amount of support for a given individual? And how can I be sure that I’m also covering the projects that Babel depends upon?
The Sponsors approach, in short, leaves many important questions unanswered.
A better (and complementary) approach is Tidelift, a company started by Red Hat veterans. Tidelift thinks about sponsorship differently, more akin to how enterprises are accustomed to paying for open source software support. Tidelift, as CEO Donald Fischer stressed, “is a ‘managed open source’ subscription that makes it easy to pay the maintainers of the various libraries and frameworks you use, specifically for proactive professional maintenance (security, compliance, etc).” Perhaps even more importantly, he went on, Tidelift tries to solve the “harder questions like ‘who to pay’ (often 1000s of distinct maintainers for a typical enterprise app) and ‘why to pay’ (for uniform commercial maintenance + services that you wouldn’t get for free).”
In a Tidelift world, enterprises focus on the software they need supported (and Tidelift figures out who to pay to ensure that happens). It’s a better fit for how enterprises want to pay for software. That’s not to say that GitHub Sponsors and other such “tip jar” approaches are bad; rather, they can be complementary to the Tidelift approach.
In both ways, developers get paid and write more open source software. That’s a win by any measure.