Maintaining an open source library is a lot like running a business, but with less risk. Except, of course, one big one: You probably won’t ever make money on it. However, you do get to build something for other people; you have customers (users), who you provide with customer support; you get to ship new features; and you even market your project. You have to think about design, user experience, cost, flexibility, durability, use cases, and maintenance.
I didn’t realize the connection between open source and running a business until I decided to build my own startup, Nozzle. But there’s always been a synergy between the two. In the beginning, a lot of my open source contributions and libraries came to fruition because we encountered real-world challenges in Nozzle and saw opportunities to leverage open source to help solve them. In fact, a lot of my more popular libraries, like React Query and React Table, are just a mashup of the technology I used to build Nozzle.
This mindset allows me to balance my hobby with my job a bit better than most maintainers. I don’t think everyone has this luxury, and I would not be able to contribute as much to open source if I didn’t have the freedom to make that decision for myself as a co-founder.
I didn’t realize the connection between open source and running a business until I became a cofounder of a startup, Nozzle.
A touch of foresight, good timing, and a new way of thinking
I think the reason React Query took off was timing. Its trajectory had been building up for years. When React Hooks came out, the new API began a new era of how we consume data, which was the beginning of React Query.
The fact that React Query didn’t already exist had to do with the syntax of composing logic in React before Hooks. React Query is just a tool. But it’s a tool that prescribes and encourages a new way of thinking for a majority of front-end developers, like Kent C. Dodds.
I really look up to Kent, and he lives an hour south of me, so we’d meet up sometimes. One day around this time, we were sitting at lunch and I shared this idea about server state versus client state—and he had been thinking the same thing. After that, I set out to build a tool that encapsulated this new way of thinking. A tool that not only made it possible, but forced the user into this new methodology of deliberately thinking and actually separating server state from application state. By doing so, we’d not only eliminate loads of code, bugs, and issues, but we’d transform all those unique server state concepts like caching, request deduping, invalidation, pagination, and many more from challenges into features that the user no longer has to build themselves.
I figured there had to be a way for developers to have a better experience managing and fetching all this server-side data without using Redux. And I know it was about timing because there’s another similar library, SWR, from the Vercel team. We developed them independently and in isolation of each other, and when we found out, we were surprised, but also validated. We had honed in on that gap in the React ecosystem, and knew a tool like this was going to be important. That little bit of foresight, plus the ability to build and deploy at the right time, was crucial.
If you’re building a React application, I want the first three things you install to be React, React Dom, and React Query. For a majority of React developers, regardless of what you’re using, whether it’s GraphQL or REST, it will work for you. I believe that it’s filling a hole in the ecosystem, and that’s why it’s become a very popular de facto solution.
React Query is just a tool. But it’s a tool that prescribes and encourages a new way of thinking for a majority of front-end developers.
Fueling an open source hobby and sharing your talents
In 2015, I was working on a popular project called Chart.js. I didn’t start it, but was contributing to the early versions with Evert Timberg, and we became obsessed. So we got permission from the maintainer, who had more or less checked out, to take it over, and wrote version 2.0.
Looking back, it wasn’t amazing code, but at the time, we thought it was great. I remember we were at the top of Hacker News and Product Hunt, and trending on GitHub. That was the first time I realized I was addicted to open source, and part of me is a little ashamed to say that. I know some people seek fame with open source, but not me. I’ve worked on each project because I needed the technology, and the excitement of that Chart.js release kept me going.
Fundamentally, every human on the planet, regardless of whether they think so or not, feels good when they help other people. Being charitable with your time and with your talents is a healthy practice for everyone. I think that’s one of the reasons why people feel good when they contribute back to open source.
It’s one thing to see your product succeeding and making you money. But it’s another thing to hear from all of the developers, usually offline, who share that my library helped them get into programming, land a new job, or launch a new feature within their own project. Trending is cool, but those grateful messages from developers are what it’s all about for me.
Being charitable with your time and with your talents is a healthy practice for everyone. I think that’s one of the reasons why people feel good when they contribute back to open source.
Paving the right path for the future of open source
In the future, I think more and more businesses are going to be built on open source. But there needs to be better expectations of balance for maintainers and contributors and the time it takes to work on code. There aren’t many options that allow maintainers to stay balanced, unless they proactively do it themselves. As we move forward, that’s something we need to be aware of—as both an ecosystem and a community—and make sure we’re not going down the wrong path.
At first, I was asking developers to become sponsors, but I’ve started to move away from that. I don’t love the idea of taking money from other developers. I feel much better accepting money from the companies they work for. So that’s the expectation I’m trying to set. I’ve learned to politely reach out whenever anyone engages on social media about my projects. I’ll say something like, “Thank you for reaching out, and if you would like, please encourage your company to become a sponsor.” So far, it’s working well as a side income, but isn’t enough to be sustainable full time.
Most people don’t have hobbies where they give away work for free, but I don’t look at it like that. It’s different to me. I just like the fun of it. We’re contributing to the internet time capsule. I hope someday my kids or grandkids will say, “Oh, yeah, my dad or my grandpa, he wrote these libraries. Sure, nobody uses those anymore but they were on the roadmap to these cool, fun things.” That’s just so motivating to me! Part of it is monetary for my business. But at the end of the day, it all comes back to my family and friends and relationships. Helping people.