Making an Open Source Library Financially Sustainable

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.

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.

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.