Skip to content
Get 30+ hours of free content from GitHub Universe! Watch now.
Photo of Tanner Linsley

When open source is symbiotic with your business

Hooked on open source, Tanner has a knack for building solutions people need.

Tanner Linsley // @tannerlinsley

Hello! I’m Tanner. I build open source software that’s used by everyone from indie developers and startups to Fortune 500 companies. If you use React, you’re likely using one of my libraries! Most of what I write is in JavaScript and focused on React, remote and local state management, data visualization, and enterprise application architecture. I also co-founded Nozzle, a Google keyword rank tracker and enterprise-level search engine analytics platform. When I’m not writing software, I enjoy vacationing with my wife and children, making music, woodworking, and home improvement projects.

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

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.

A touch of foresight, good timing, and a new way of thinking

Photo of Tanner Linsley on the beach standing on a rock.

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.

Photo of Tanner Linsley on the beach standing.

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.

Photo of Tanner Linsley on the beach with his wife and children.

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.

Photo of Tanner Linsley and his wife playing with their kids.

GitHub Sponsors allows you to financially support the people who build and maintain the open source projects you depend on. One-hundred percent of your sponsorship goes toward helping Tanner maintain chartjs.
Support Tanner on GitHub Sponsors

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

Thank you! for subscribing