Financial sustainability for open source projects at GitHub Universe
10th November 2023
I presented a ten minute segment at GitHub Universe on Wednesday, ambitiously titled Financial sustainability for open source projects.
GitHub invited me to speak as a representative of the GitHub Accelerator program from earlier this year. The goal was to share some of the advice from that program, and talk about my own personal experiences trying to achieve financial sustainability for my Datasette open source project.
To set expectations: Datasette is not yet financially sustainable, at least not in terms of my long-term goals for the project! Fitting everything I’ve explored so far into just ten minutes was a significant challenge.
You can watch my presentation on YouTube, or embedded below. Read on for an annotated version of the slides, based on a Whisper transcript and extended with some extra clarity and links to further reading.
I closed with a call to action for a novel way that companies can help support open source projects: pay maintainers to speak to your team, in the form of time-boxed one hour Zoom consulting calls. Open source developers are often bad at asking for money. If you want to support a project, try pushing money towards them from your existing training budget instead!
I’m here to talk about the single hardest problem in all of open source: as independent open source developers, if we’re giving this stuff away, how do we make a living?
We’ve got ten minutes, which is definitely long enough to solve this! Let’s get it figured out.
It’s important to acknowledge that this is a two-sided problem.
As open source maintainers, we need to figure out how to make this stuff work financially for us.
And as users of open source software, we should be really invested in solving this problem, too. If you depend on open source software, you need that thing to keep on working for you, and to be maintained long into the future.
So I want to approach this from both sides of the problem.
My main open source project is called Datasette.
I’ve been working on this for about six years now, and it’s grown into a whole ecosystem of tools around the theme of helping people explore, analyze, and then publish their data.
Datasette itself is a Python web application that you can pour data into.
You load that data into a SQLite database, then Datasette provides in interface for people to explore that data, filter it and visualize it—on a map, for example. Here’s an example.
Crucially, Datasette helps you publish that data online.
My inspiration here is WordPress. If you want to publish content, WordPress has mechanisms for doing that.
I’m trying to build WordPress, but for data itself. The best possible way to publish structured data online.
More on Datasette:
- Exploring a database with Datasette is the official Datasette tutorial
- Cleaning data with sqlite-utils and Datasette shows how to use it in conjunction with another of my open source projects, sqlite-utils, to clean and transform data.
The original idea for this came from work I did at the Guardian newspaper back in London.
We were reporting data-driven stories, and we wanted to publish the data behind those stories as well.
Back then we figured the easiest way to do that would be to have a blog.
So we built the Guardian Datablog, and any time we published a story that was driven by data reporting we would try to publish the data underlying that data as a Google spreadsheet.
I always felt like there should be a better way of doing that: there should be some kind of mechanism that was more open and powerful and flexible than just sticking things in a spreadsheet.
I worked on Datasette as a side project for a while, and then I built a feature which really blew the whole thing open.
I added plugin support, again, inspired by WordPress.
Today Datasette has over 128 plugins that let it do all sorts of useful additional things.
And I’ve realized that in terms of open source contribution, plugins are absolutely the best model.
I can wake up in the morning and find that my software has developed a new feature, and it was released to the world, and I didn’t even have to review a pull request!
It is so liberating to have this as a mechanism for extending software.
I thoroughly recommend open source maintainers look at plugin systems if you’re feeling overwhelmed by the contributions that people might be trying to make to your core software.
Datasette started as a side project, but I quickly realized that, especially with the plugins mechanism, this was going to be something I want to work on for the next 10 to 20 years of my life.
That’s never happened to me before in my career. I’m very easily distracted! You don’t often get a project where you think that if I was working on this in 10 years’ time I’d still be excited about it.
So I’ve got two goals now.
Firstly, I want to be able to support myself. I would like to continue to work on this for the next decade plus.
But I also realize that working on this kind of thing solo is kind of lonely. I want a team.
This is super-useful as a psychological trick for me because I’m not a natural capitalist. I’m very much an open source engineer.
I’ve found that thinking in terms of paying for a team helps me elevate my financial goals and be much more ambitious about making serious revenue from this thing, if I’m going to achieve these dreams.
I’ve beneffited from a few lucky, unconventional ways of supporting this project so far.
I was working on this as a side project when I heard about a program at Stanford University called the JSK Journalism Fellowships. Each year they pluck around 20 journalists from around the world and pay them to spend a year on campus at Stanford working on problems that are relevant to the world of journalism.
I applied saying, you know, I’m not actually a journalist, but I write tools for journalists. Does that count?
And they decided it did.
So I got paid to spend a year working on my open source projects, which, with hindsight, completely ruined me. Because once you’ve got to spend a year just working on the things you want to work on, it’s very difficult to accept somebody else stepping in telling you to work on other things instead.
Since that fellowship ended, I’ve been mainly living off savings and occasionally picking up bits of consulting work— and trying to keep that ball rolling, because I’m enjoying myself so much.
I had another lucky break earlier this year: I was accepted into the GitHub Accelerator program.
This was a program from GitHub where they take twenty open source projects and sponsor the maintainers to work on them full time for ten weeks, while also focusing on solving this larger problem: How can we make our projects financially sustainable?
(The accelerator is running again in 2024, applications will be open soon.)
A highlight of the program was the guest speakers. Every week we heard from the maintainer of a different open source project that had found a model that worked for them.
The themes that started to emerge from there were fascinating.
Some projects had made sponsorship work really well for them, funding teams of several developers. If your project is widely used enough you can make this work.
The difficulty here is that it’s something of a marketing and sales job: you have to actively seek sponsorship, and you have to maintain strong relationships with your existing sponsors to keep the happy.
Another interesting approach was to acknowledge that if your project is successful, someone is going to make a bunch of money selling courses and tutorials and books about it. Since you know your project better than anyone else, maybe that person should be you!
A classic solution which has worked for a lot of projects is hosting it for people, going the software as a service route. WordPress, MongoDB and Plausible are good examples. This is a well-trodden path for building a business around an open source project.
The last option I’ll mention is enterprise licensing. Offering an enterprise licensed version with different licensing terms, commercial support and maybe a few enterprise-friendly features.
We heard about that one from Mike Perham from the Sidekiq Ruby message queue project, who has had fantastic success with this.
Mike very specifically warned us to avoid the hosted version option, especially as a solo developer. Building that makes you responsible for customer data, and if something breaks, you have to get up at 3 o’clock in the morning to fix it. It’s much better to have your customers run and be responsible for the software themselves.
After carefully considering all of these options, I decided to go for that hosted option that Mike had warned to avoid!
I should justify that a little bit.
A problem I’m having with Datasette is that my initial target audience is journalists—and Datasette is at its most useful when you have it running on a server somewhere.
If you tell a journalist "It’s easy! All you have to do is spin up a Linux server, pip install datasette
, set up systemd, and then open it up to the internet..."—you’ve just lost 98% of your target audience!
Offering the hosted versions gives me two things at once. I’m getting a business model that has been demonstrated to work, and I’m also solving the problem that my target audience need to be able to click a button and start using the software.
I’m calling it Datasette Cloud.
This is where my last unconventional form of support came from.
I’ve been building Datasette Cloud on a hosting platform called Fly.io, which is absolutely perfect for this kind of project. Fly makes it really easy to spin up secure containers for individual customers, so I can run copies of my software independently for everyone.
Fly have been generously sponsoring the project by funding a freelance developer (the most excellent Alex Garcia) to work with me on getting this stuff working.
They agreed to this because we’re building in open source and working in public, and this can become a great case study for them showing how you can solve these kinds of problems on top of their platform.
So if you’re a company looking to sponsor an open source project, offering to pay for freelancers to work on things is an incredibly generous and very effective way of providing that support.
I want to bring it back to this idea of tackling this problem from two directions. As users of open source, what can we be doing to help push money towards the projects that we care about?
I have a proposal for you: a little bit of a conspiracy we can all get in on here.
What you should be doing is paying maintainers to speak to your team.
Maintainers are very busy people. I don’t have time to do extensive hands-on consulting with people... but I can spare an hour out of my day to jump on a Zoom call.
I’ve done a few of these now and they’re absolutely fantastic as a way of having a time-boxed commitment where I can earn some money doing something genuinely useful, talking to people about my projects and sharing my expertise.
It’s also a great trick for end-users of the software because, as I hinted earlier, open source engineers are often great at writing code but not great at asking for money.
With this model, you don’t need the contributors to ask! You can push money towards them instead.
You can get in touch with the maintainers of the software you’re using and say: Hey, we’d love to know more about this. We will pay you to jump on the Zoom call with our team and answer questions and talk about what you’re doing.
This is a call to action. If you’ve got projects that you depend on and you want to support them, try this sneaky backhand way of funneling money there.
Every company has a training budget. Companies are very bad at just giving money away, but they’re really good at hiring consultants.
So if you can shape this as a consultancy agreement to get a maintainer to do an hour-long call with you, I think that could work really well.
Please, go ahead and work on this from the other side. Help us figure out this problem by finding ways to push money towards those projects that you depend on!
Want to book me to talk to your company? Contact simon@
this website’s domain.
More recent articles
- OpenAI DevDay: Let’s build developer tools, not digital God - 2nd October 2024
- OpenAI DevDay 2024 live blog - 1st October 2024
- Weeknotes: Three podcasts, two trips and a new plugin system - 30th September 2024