Dear Open Source: let’s do a better job of asking for money

It’s common knowledge that many open source projects are underfunded. We think one reason for this is that the open source world is doing a bad job of asking for the money that it deserves. By telling the right organizations exactly why and how we want them to financially support our work, OSS projects can be compensated for more fairly, and result in a healthier open source ecosystem.

We maintain React Flow, an open source library for making node-based UIs. Our story developed in a similar way to some other lucky libraries:

1. Build a library to fill a need you have and open source it
2. Gain users who have the same need, and they start submitting issues and requests
3. Build trust by continuing to maintain and develop the library as it grows
4. Open your Github sponsors page

Unfortunately our Github sponsors page didn’t pay the bills- not even close. To avoid having to find contract work or pitch for investment, we decided to ask for money in a more direct way by adding this to our website:

We started getting paying customers at a much faster rate, each paying more than any of our sponsors were, and we became “ramen profitable” in a few months.

What caused such a drastic change?

How did we bypass a problem that plagues the open source world?

After some experimentation and user research, this is what we found as our answers to these questions:

Thin-Crust Open Core model

We moved from a donation-based model to a Thin-Crust Open Core model. This is why we kept the React Flow library MIT Licensed, and added a small amount of features (Pro examples, and some technical support) to the “crust” of the library. By offering something small on top of our core library, we created a reason to click the “buy” button.

At first, we were afraid that subscribers would have much higher expectations of us since they were now paying for our work. We imagined rapid response times, monthly newsletters, more frequent releases, and having to constantly prove our worth. This didn’t turn out to be true.

From talking to our subscribers we learned that after subscribing, they don’t think of themselves as paying only for the on-top offerings with their subscription, but rather that they are paying for whole library (the docs, guides, new features, and the app that they were able to more easily build by using our library). It is true: they aren’t just paying for the stuff on top, they are paying for the whole library. And for them, that’s worth the money.

Acknowledging the funnel

Every open source project that receives money has a “purchase funnel” (the steps a person takes to become a paying customer) even if it’s just a “buy me a coffee” button. Acknowledging and revising the steps of this funnel can turn targeted non-paying users (like large companies) into financial supporters.

We added a small attribution in the corner of React Flow’s viewport. It’s easy to remove, and 100% legal to do so under our MIT License. In the code where you can remove this attribution, we link to our pricing website with the request to consider paying if they are using our library commercially.

This moment establishes some friction to the user where they have to take a moment to consider if they are willing and able to support our library.

Stealing from the SaaS Playbook

We decided that we wanted those who get value from React Flow and are easily able to afford it to be the ones financially supporting the library. This meant most of our funding would be coming from organizations, rather than individuals.

We wish that every open source evangelist would pay us with their company’s credit card if they liked our library, but after talking to our subscribers, we know that’s not how this works. Often times they have to make a case to their project manager or CTO to ask if the company can support the project. Our job as OSS creators is to make it easy for our users to ask their organizations to support our project. We can do this by stealing from the SaaS playbook.

By using a three-column pricing page, the person with the credit card knows exactly what to expect when they arrive on our pricing page: cheap on the left side, expensive on the right. It says what they get, and how much it costs. We didn’t need to explain any complex donation structures, or how their money would exactly be used by us, which we believe might be a barrier for organizations who are easily able to afford the pricetag. This way, we helped our users to become successful liaisons when asking for budget within their organizations.

None of this is new

Investors are very aware of using open source as the center of a business model, since it’s a way to get an interested user group, expert feedback, developer goodwill, an interest from potential hires, and a foot in the door with larger companies who adopt your OSS. Along this path, the next step of a library like ours could be to seek investment, expand our service and/or proprietary offering, and eventually seek an exit.

What we’re doing instead is staying intentionally small and growing slowly. We don’t want or need to expand our proprietary offering at a pace that will outgrow the core library. Instead, we can have the benefits of being paid for our open source work, while having total agency over the direction of the library.

Our suggestion here is to take the models that investors are using for our own open source projects, so that we can get paid by companies and organizations, rather than a closed ecosystem of open source developers paying other open source developers.

Mileage may vary

Although we think many people could use these findings to get paid more fairly for their OSS, we also acknowledge that we had a head-start in a lot of ways: before putting a pricetag on the website, we had a business set up and ready-to-go (from previous agency work) and we had already worked on the library for two years. We were lucky that we hit a niche that is at the center of many startups building node-based apps, and building a visual library made it possible to have a visible attribution in the corner that can direct users to our pricing page.

Some final thoughts

If you don’t feel like taking money from customers because it gives you a sense of responsibility that you don’t like, that’s also fine. There is a different kind of work that has to be done when you have not only “users,” but also “customers,” and we hear that.

Asking for money in this way takes confidence in our work. It can be difficult to ask for money for something you may have considered a hobby, or a less-than-serious project. Just because we do work “for fun” or in our “free time” doesn’t mean we shouldn’t be compensated for it. If we were all compensated for our open source work, it might even allow for people to contribute to open source who otherwise don’t have the privilege of “free time.”

We hope sharing our journey can help a few people move money into the right hands.

source: https://www.reddit.com/r/funnysigns/comments/f151wh/local_tip_jar/?utm_source=share&utm_medium=web2x&context=3

Continued Reading

There’s a lot already said about this topic. For a start, check out a comprehensive exploration of Money and Open Source by Isaacs (creator of npm), how relying on unpaid labor creates an unfair OSS ecosystem from Ashe Dryden, and another model for working as an open source maintainer outside of a corporation (and how we should charge big companies for OSS) by Filippo Valsorda.

Thank you to Eileen Wagner for leading the research that led to this article and for helping to structure these thoughts. Also thank you to React Flow subscribers, contributors, and community for your continued support 😊