The Twitch argument for GitHub Sponsors
May 24, 2019
I’m thrilled about the launch of GitHub Sponsors, which signals a strong commitment from GitHub to support financial infrastructure and tooling for developers. It’s arguably the biggest open source funding experiment to date and will create plenty of opportunities to learn from.
I’ve seen recurring comments to the effect of “This is great, but individuals aren’t where the money’s at, it’s companies”, which is a position I’ve also previously taken. If companies have the deepest pockets, stand to lose the most, and financially benefit the most from open source, they seem to be the most obvious source of funding. Viewed through this lens, Sponsors can be understood as a first, important stepping stone towards company sponsorships, the latter of which seems inevitable given the presence of Organization accounts.
Recently however, as I’ve been simultaneously digging into the world of Twitch streamers , I’ve begun to wonder: “What would a viable, standalone strategy for user-to-user sponsorships look like?” So I thought that would be fun to explore here.  My hypothesis: rather than individual sponsorships being a path to company sponsorships, the motivations of individuals are different from companies, and therefore should be treated as two separate use cases, and two separate products.
GitHub’s ‘follow’ feature
I’ll start with an observation about GitHub’s social features that I find endlessly strange and fascinating: the follow button.
Followers: that odd little number at the top of your GitHub profile.
Most people I’ve asked about the follow button say they don’t use it. As a hybrid of social and utility, GitHub isn’t quite like Twitter or Instagram, which are pure social platforms that transact in likes and follows. Although you can theoretically “follow” other developers on GitHub, many developers also just use GitHub to write and host their code. The follow feature, by comparison, seems like an afterthought.
Those who are dismissive of GitHub’s follow feature don’t realize there’s a whole other group of people out there who apparently love to follow other developers. Sindre Sorhus, for example, has 32.8K followers on GitHub. Jess Frazelle has 9.2K followers. Hell, I have 700 followers, despite not writing any code. Why does anyone follow anyone else on GitHub, given that the purpose of following is not clearly evident?
I haven’t talked to enough people about it to have strong conclusions here, but I have noticed a few differences. When I talk to prominent, “public figure”-type developers, they don’t seem to use or understand the follow button. But less publicly visible developers seem to be much more enthusiastic about following the work of others.  Even if they don’t officially use the follow feature, they’ll say things like, “Oh, I was obsessed with Dan Abramov’s work for awhile” or “I love watching noopkat’s coding livestream”. Their eyes light up when they talk about specific developers. If I ask why, I’ve heard a few common responses: 1) they’re learning a specific skill, and watching that person is helpful, or 2) they’re experienced developers who just love being able to see how “the best” do it.
This is a very different argument from, say, “Oh yeah, I use everything Sindre Sorhus makes”. That a developer uses Sindre’s projects is implied: Sindre’s voluminous output is what made him “famous”. But the fact that someone uses Sindre’s code might not be why they continue to follow his work on GitHub.
Similarities to streamers
As I’ve been ruminating on Twitch streamers, it struck me the other day that open source is a sort of “high-latency streaming”. It’s streaming, but in staccato snapshots. Fundamentally, though, the relationship between a prominent GitHub developer and their audience, and a prominent Twitch streamer and their audience, is similar: they gain followers because people enjoy watching them do something in public.
There are differences, so let’s maybe get those out of the way first. Latency makes a big difference. The ability to watch a streamer in real time engenders other viewer motivations that I think aren’t as present in open source. For example, people might watch streamers because it makes them feel less lonely, or is just something nice to have in the background.
In terms of funding, streaming also benefits from a short feedback loop that lends itself naturally to gambling-like dynamics. Viewers tip streamers because they’re bored, because they like hearing the streamer say their name, because they want to see something happen. Tipping storms are a delightful phenomenon in streaming where enough viewers start tipping simultaneously that they induce a flood of more tips, which swells and eventually crashes like an tidal wave. It’s hard to imagine these dynamics taking place in open source, either, because the feedback loops are longer.
On the other hand, I think streaming and open source do share similarities when it comes to a viewer’s desire for education and mastery. There are plenty of viewers who watch streamers because they’re bored, lonely, or just want to be entertained. But there are also viewers who watch streamers because they want to learn from that person, or because they enjoy the “behind the scenes” feel of watching an excellent player do their thing in public.
Given these dynamics, I don’t think GitHub Sponsors is quite “Patreon for open source”. Yes, there’s a patronage angle, in that most user-to-user funding tends to be fueled by a sense of “I think you are an awesome person, and I want to support whatever you do”.
But Twitch streamers and, similarly I think, GitHub open source developers, benefit from an additional set of motivations, which is, “I want to watch and learn from you”. A graphic artist or a blogger who’s funded on Patreon doesn’t quite have that same relationship to their audience. In those cases, I think their output – the artifacts they create – takes center stage.
By contrast, although people probably watch Twitch streamers in part because they enjoy the game that’s being played, it seems they’re more attracted to the streamer’s process than their output. Viewers seek an intimate connection with the streamer. Similarly, while I imagine that some individuals would sponsor an open source developer because they use their code, there are probably others who just love watching the person who makes it.
All this presents a very different argument from corporate sponsorships, which reflect a more transactional relationship with open source developers. Companies use and rely on open source code, and it’s in their best interest that that code keeps working. To that end, I’ve heard from open source developers that companies tend to be less comfortable using Patreon and funding individual maintainers; they would rather donate to the project itself.
Companies want things like prioritized support and attention from maintainers, brand visibility, and security. Individual developers want to learn, watch, feel “seen” by someone they respect, and build an intimate connection. With companies, open source developers are selling a product. With individuals, they’re selling themselves.
There are individuals who fund open source developers as a donation or a thank you for their work, but the total addressable market will always feel small, compared to what companies can offer. But if we frame individual sponsorships in terms of social dynamics, it implies a different sort of economy altogether.
On Twitch, individuals can subscribe to a streamer’s channel, which is a separate product from corporate sponsorships and advertisements that provide additional sources of revenue. I think GitHub Sponsors for individuals could grow to become more like these subscriptions – a natural extension of the desire to “follow” a developer – whereas company sponsorships are primarily motivated by a desire for either brand visibility or support.
Secondly, revenue is not a zero-sum game, which is why I think corporate and individual sponsorships might just be two distinct products. Some developers and projects will be better suited to corporate sponsorships, while others are better for individual subscriptions. This is not dissimilar from streamers: maybe a Twitch streamer who plays tabletop games primarily earns revenue through individual subscriptions, whereas a professional Fortnite player can pull in corporate sponsorships.
There are positive implications to treating individual sponsorships separately, too. Open source developers often work across projects, and might prefer not to have their funding tied to a specific project. And individual sponsors are probably more likely to fund crazy new ideas (much like Kickstarter crowdfunding), whereas companies are probably more inclined to support critical, existing projects.
Finally, encouraging developers to follow and subscribe to other developers feels uniquely GitHub to me, in a way that, say, Patreon couldn’t really do, because GitHub is the platform where open source is built. If GitHub were to double down on a user-to-user strategy, what are the product implications? What social signals would need to be in place for this approach to succeed? What sorts of rewards or benefits would individual sponsors expect, and how would that differ from benefits for corporate sponsors?
Okay, that’s all I’ve got. I’m mostly musing out loud here, because I’m so used to thinking of individual sponsorships as “smaller potatoes” compared to corporate sponsorships, and I wanted to challenge myself to imagine how they could be just as economically viable on their own merit. I’m curious to hear others’ thoughts! In particular, if you follow other developers on GitHub, I’d love to hear how much this does/doesn’t align with your thinking.
Note: I am not an expert on Twitch streamers; merely a casual connossieur. ↩
A few disclosures that feel relevant here: I worked at GitHub from 2016-2018, and I also have a (small) financial stake in Open Collective. ↩
Prominent GitHub developers could also include those who aren’t primarily known for their open source work. Julia Evans, for example, creates a lot of useful programming content and has 4.8K followers. ↩