Making an Open Source Library Financially Sustainable

Rate this content

React Flow is an open source library used by thousands of developers and hundreds of companies. How do we make sure it stays alive, and also free? I’ll share some insights along our journey from open sourcing React Flow to passing the “black zero,” including findings from our user research where we spoke to some of the people who support us every month.

8 min
02 Dec, 2022

Video Summary and Transcription

The Talk discusses how an open source library, ReactFlow, was made financially sustainable. Various methods were tried, including Github sponsoring and cross financing, but a price tag was eventually added to the library. Building trust and clear expectations through ongoing support and communication with subscribers was key to gaining financial support. The issue of people not knowing how much to contribute was addressed by providing a clear pricing structure. Additional features like one-on-one support and Pro examples were added to combat the paradox of choice and encourage financial support.

Available in Español

1. Making an Open Source Library Sustainable

Short description:

I'm here to talk about how we made our open source library financially sustainable. We built ReactFlow as an open source library that gained traction. We tried various methods to financially sustain it, including Github sponsoring and cross financing. However, we wanted to maintain the MIT license and allow smaller companies to use it. So we added a price tag to the library.

Hello, everybody. I'm John. Hi, everyone. I'm John. That just felt like an intense intro. I'm here to talk about how we made our open source library financially sustainable.

I am John. I work for ReactFlow. It's a library that we built in order to build another thing that we were making a couple of years ago. Has anyone here by any chance used ReactFlow at some point? Got a few hands raised and more to help build the library. Thanks for that.

We built this a couple of years ago. While making something else, we decided to open source it. It ended up getting some traction, which was great, but of course what comes with an open source library that's used very often is that we need to sustain it. We start to get a lot of issues, a lot of people asking questions, the Discord channel starts growing. Our question came to be how can we make sure that this has all the features that it needs, that it's stable for all these people who are using it? That comes with finances. How do we make sure to financially sustain it?

We tried a bunch of stuff. First, Github sponsoring. For us, it didn't work at all. It wasn't nearly enough money to work on this and to dedicate a strong amount of time to it. We didn't have enough supporters, not enough money per supporter. Cross financing was an option but of course that's working like agency work a little bit more intense and then splitting your time between two things. Going to investors. We wanted the option to be able to decide the direction of our own library at the time so that wasn't an option for us. Of course there was, let's just smack a proprietary license on it instead of MIT, sell it to some of the enterprises that are using it for a couple of thousand euros and we can go to Mallorca. But for us, the MIT license was super important since we had used a bunch of MIT license stuff and we wanted people that wouldn't be able to pay for it or smaller companies to be able to use it, and we believe in open source generally.

So what did we do? We added a price tag. So all of you have probably seen this kind of three rectangle screen before and know exactly what it means. You have cheaper option on the left, more expensive on the right. So on the left we have the library as it stands.

2. Building Trust and Clear Expectations

Short description:

Open source, MIT, everyone can use it. We added features, bug reports, and one-on-one support. People subscribed and we became financially sustainable. We talked to subscribers and got insights. Building trust through ongoing support is important. By responding quickly, subscribers knew us and supported us. Making our expectations clear helped us gain financial support.

Open source, MIT, everyone can use it. Just download it as you want. And then we threw on a couple of features of pro examples, prioritized bug reports, and for the slightly more expensive, we gave people one on one support for just an hour a month and we wanted to see what happens. Let's see if this works. People subscribed. Amazing. And this is how we got to becoming financially sustainable as a three person company.

Great. But the thing is, we weren't quite sure why people were subscribing to pay for something that they can basically get for free. So that's what I'm gonna talk to all of you about today is what we found from some research that our good friend Eileen, who's a researcher, said, hey, why don't you actually ask your subscribers why they're paying? So we talked to eight subscribers. And we got a bunch of great insights from them. And some of them are just React flow specific, right? Our value proposition is great, which is awesome. And in the space, at the time, there aren't many competitors in this niche space. But today, I'll share with you some of the stuff that I can sort of impart on you all that's not just related to React flow.

I am talking fast. I am from near New York City. So slow. There we go. Clicking the buttons. Back, back. And that was a break for all of you. The first point of four. Probably a lot of you already know if you've worked on open source software at all, building trust through ongoing support is super important early on, especially if you're going to be trying to figure out what features do we build, your users will tell you. And by responding to those things quickly in GitHub and Discord, you're easily going to start to build that trust. So when we actually talked to our subscribers, they didn't just know like, oh, React flow is a great library, they knew our names. So they weren't just supporting the library that they were getting on GitHub, and the documentation, but they were supporting us as people.

Then the question is, if they support us as people, how can we get them to actually support us financially if they're able to? And that is by making our expectations clear. So as I said before, we tried GitHub sponsorships, and it didn't work at all, not even close to financially sustainable. And then we threw up this thing that's pretty much the tried-and-true model of SaaS companies for years, and it worked. And our hypothesis here is that we've basically narrowed the choice down, because so many open-source libraries, we're not sure how to support them.

3. Addressing the Paradox of Choice and Pricing

Short description:

We addressed the issue of people not knowing how much to contribute by providing a clear pricing structure. Despite being free, we added a few extra features like one-on-one support and Pro examples. This has helped us combat the paradox of choice and gain financial support.

They might have complex governance structures, we're not sure how much money they need, how much money they expect for this kind of thing. So it might be hard for people to say, when they go to a GitHub sponsorship, to say, do I give them 10 euros a month or 100 euros a month? What do they need? So our hypothesis is we've combated the paradox of choice a bit here. But the question again is, what do you put on top? This whole library is free. Am I going to build a whole other library on top? And as I said before, we didn't. We just added these couple of features, like an hour of one-on-one support, that honestly not all of our subscribers are asking for, so we don't need to spend all of our time doing that. We have a couple of Pro examples on top.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
16 min
How to Build Your Own Open Source Project
We all used open source projects every day such as npm packages, editors, web applications, and even operating systems... Have you ever thought of building one of your own? In this talk, I will share my journey building jest-preview, from when it was just a vague idea, to currently a well-adopted library to help frontend engineers write tests faster. I will share with you how to come up with an idea for a project to work on, what is the struggles you have to overcome as an author of an open source project, how to manage time efficiently, and how you get attention from engineers around the world.
TypeScript Congress 2022TypeScript Congress 2022
30 min
Lessons from Maintaining TypeScript Libraries
Maintaining widely-used JS libraries is already complicated, and TypeScript adds an additional set of challenges.

Join Redux maintainer Mark Erikson for a look at some of the unique problems TS library maintainers face, and how the Redux team has handled those problems. We'll cover:

- Tradeoffs of different ways to define TS types for a library
- How to target different versions of TS, and considerations for determining the supported version range
- Migrating existing JS libraries to TS
- Differences between writing "app" types and "library" types
- Managing and versioning public types APIs
- Tips and tricks used by types from the Redux libraries
- TS limitations and possible language-level improvements
Vue.js London 2023Vue.js London 2023
31 min
Nuxt 3 Modules and Open-Source
Nuxt modules are the de-facto way of extending our Nuxt applications with new behaviors and functionalities. Have you ever built your own? Why would you bother with hundreds of modules already out there? Let's answer those questions together and see why making your own modules in Nuxt 3 can both help you have a deeper understanding of how Nuxt works while also paving the way for you to get into open source!
React Finland 2021React Finland 2021
18 min
The State of XState
Over the past few years, state machines, statecharts, and the actor model have proven to be viable concepts for building complex application logic in a clear, visual way with XState. In this talk, we'll take a peek into the future of XState, including new features in the next version, and new tools and services that will make it even easier to create and collaborate on state machines.
React Day Berlin 2023React Day Berlin 2023
31 min
Break the Race: Easy Race Condition Detection for React
Race conditions are among some of the most challenging to detect and reproduce issues. As such they pose a significant challenge in development notably in UI. In this talk, we explore how to detect race conditions by leveraging fuzzing techniques. We walk you through discovering the real problem of race conditions and how they impact user experience. We provide you tools and examples demonstrating how to easily detect them in your daily work thanks to tests relying on fuzzing. After that talk, we hope your React code will be race conditions free or at least that you will have the right tools to help you.

Workshops on related topic

Node Congress 2023Node Congress 2023
85 min
Node.js: Landing your first Open Source contribution & how the Node.js project works
This workshop aims to give you an introductory module on the general aspects of Open Source. Follow Claudio Wunder from the OpenJS Foundation to guide you on how the governance model of Node.js work, how high-level decisions are made, and how to land your very first contribution. At the end of the workshop, you'll have a general understanding of all the kinds of work that the Node.js project does (From Bug triage to deciding the Next-10 years of Node.js) and how you can be part of the bigger picture of the JavaScript ecosystem.

The following technologies and soft skills might be needed):
  - Basic understanding of Git & GitHub interface
  - Professional/Intermediate English knowledge for communication and for allowing you to contribute to the Node.js org (As all contributions require communication within GitHub Issues/PRs)
  - The workshop requires you to have a computer (Otherwise, it becomes difficult to collaborate, but tablets are also OK) with an IDE setup, and we recommend VS Code and we recommend the GitHub Pull Requests & Issues Extension for collaborating with Issues and Pull Requests straight from the IDE.

The following themes will be covered during the workshop:
- A recap of some of GitHub UI features, such as GitHub projects and GitHub Issues
- We will cover the basics of Open Source and go through Open Source Guide
- We will recap Markdown
- We will cover Open Source governance and how the Node.js project works and talk about the OpenJS Foundation
  - Including all the ways one might contribute to the Node.js project and how their contributions can be valued
- During this Workshop, we will cover Issues from the nodejs/ as most of them are entry-level and do not require C++ or deep technical knowledge of Node.js.
  - Having that said, we still recommend enthusiast attendees that want to challenge themselves to "Good First Issues" from the nodejs/node (core repository) if they wish.
  - We're going to allow each attendee to choose an issue or to sit together with other attendees and tackle issues together with Pair Programming through VS Code Live Share feature
    - We can also do Zoom breakrooms for people that want to collaborate together
  - Claudio will be there to give support to all attendees and, of course, answer any questions regarding Issues and technical challenges they might face
  - The technologies used within nodejs/ are React/JSX, Markdown, MDX and Gatsby. (No need any knowledge of Gatsby, as most of the issues are platform agnostic)
- By the end of the Workshop, we'll collect all (make a list) the contributors who successfully opened a Pull Request (even if it's a draft) and recognise their participation on Social media.