Growing up, my dad was a mainframe engineer, and always pushed me away from a career in tech, so I had no real interest. I was pre-med in college, but also took a computer science class, which sparked a shift: I realized I didn’t want to be a doctor, and swiftly switched to a cognitive science degree with a computer science minor. This is where I found my true passion. Even homework was suddenly exciting because I finally got to code, and it quickly became the most time-consuming hobby in my life.

I was interested in machine learning and AI, and worked in a computational cognitive science lab writing code to power many of the experiments. I also participated in a computational game theory research group, and continued to dive into developer tools and programming languages. There were so many different areas that I wanted to learn more about, and computer science allowed me to contribute to all of them. I love that every company is a software company—and those that aren’t are just opportunities for the next great innovation.

After college, I became a software engineer at Pandora and found myself building open source tools in my spare time. I put them on GitHub, and people at bigger companies started using them, which looked like some semblance of a business opportunity—but I found it very challenging to actually navigate what came next. Today, a lot of my work in and around the open source community is about how we can help open source projects and maintainers be more financially successful when they produce valuable products. How can we help get maintainers paid more fairly for their work and for the value they create?

Building the right foundation and waiting for an opportunity

Even as I was learning computer science, I was interested in eventually exploring entrepreneurship. After working at Pandora for three years, I joined a startup called Fraction with some friends from Berkeley, with the intention that I’d learn by doing and observing. After being at Fraction for a few years, I left to start Scarf.

Scarf is a startup building tools for growth and adoption metrics for open source maintainers, with the goal to help them better understand how their projects perform. Say a project distributes the latest version of their software on GitHub. We’re able to provide granular stats about how they’re being downloaded and used. We can share detailed download metrics, and break them down by version, platform, geography, and much more. We can even share which companies are downloading them.

Often, someone will see they have 10,000 downloads, but without going deeper they can’t properly contextualize what that means. I’ve been in that position, and it could easily be a roadblock to making informed decisions or finding financial sustainability.

At Fraction, I built tools that the company started relying on heavily enough that it made sense to open source them on GitHub and promote them on Hacker News. It absolutely got me hooked on building stuff with and for the open source community. Often, as a maintainer, you want to drop everything to fix any bugs that come up, but you don’t know what to do first. You’re just trying to stay afloat, which can be stressful. My hope is that we can alleviate that.

I love when people tell me one of my open source projects has an impact on them. It makes my day. But the reality of open source means most people won’t tell you about their experience. Being able to surface the data makes the whole experience more rewarding. You can get those positive interactions without really necessarily interacting in a more traditional way.

People need to see the impact of their work to make informed decisions. Until then, open source maintainers are going to be at a disadvantage to those building proprietary software. It’s my goal to help maintainers be more successful—whatever that means to them. For some people, that could be seeing that your work has an impact. One thing GitHub did recently was release badges for folks whose code is part of big projects, like NASA’s Ingenuity helicopter on Mars. I thought that was super inspiring for contributors. Similarly, Scarf can tell developers which companies use their libraries, to give more insight to the impact developers are having on the real world.

Whether you have commercial ambitions or not, having the tools to see the impact of your work helps everyone find more success. It can also help us maintain projects more effectively. Before, every time I got a GitHub notification, I wasn’t sure how to prioritize it. But when a user comes to you and says, “hey, this thing is broken in a subtle way on Windows, and X percent of your user base is affected”—that allows you to prioritize accordingly. Being able to make data-driven decisions is a powerful way to help create an open source community where maintainers are less burnt out because they spend their time on the right things.

Making money when other businesses make money

My mom grew a successful, fully bootstrapped business that I always admired, so maybe I was raised to value that mindset. But I’ve always liked the idea of being able to solve the problems I want to solve and learn the things I want to learn —and I think entrepreneurship is a very attractive path.

I really like what I do at Scarf because I get to work on problems I enjoy and help a community that I have come to care deeply about. This kind of entrepreneurial angle is not one-size-fits-all in any capacity. But what we all do in open source directly contributes to huge organizations. There aren’t a lot of hobbies like that, so the incentives are different and affect people differently.

When it was just me trying to solve problems for the users of projects, it was my own online reputation at stake, and there was the intrinsic motivation to make my projects good so people would use them. As a founder, the stakes are a lot higher because there are salaries and incomes on the line. We’re also VC-backed, so there’s that whole element. When people have demands it’s because they paid money and there’s an agreement in place—which I’m comfortable with.

There are no promises or warranties on open source, even though I would have loved to give my users a warranty. I just had no idea how to do that. I was not a salesperson. I didn’t know how to sell an enterprise contract. The sponsorship model was less appealing because I couldn’t depend on it. With Scarf, I was ultimately trying to focus on some of these monetization and economic issues. All I knew for certain was that I wanted to help people participate in the value that they were creating.

Jumping in, getting to know your users, and tracking your impact

I encourage new developers to spend less time thinking, “what should I work on,” or “how should I go about doing X or Y or Z?” Just try something. If you have an idea for a project or you have five ideas for five different projects, just try one. I always build projects to solve problems I personally experience. And I learned programming by doing it: I could read 10 books on a topic, but it wouldn’t be as effective as if I just sat down one weekend and worked through a project. You’re going to learn the fastest by trying. It’s much less important to do everything the right way and more important to try it and then learn from it.

For people looking to take their project and grow it into something bigger: Talk to your users more. Sometimes you get the vision for what to build, but you don’t listen to what your users actually want. You really have to talk to people constantly about what they need.

And, of course, track how you do on the things that matter to you. Don’t just put your software out in the world with no observability and hope people will come and tell you about it. Some might, but they don’t represent your whole user base. If you tailor what you do to the loudest people on GitHub, you’re going to get a very skewed perspective of what your product is doing for your community and you may spend your time on the wrong things.

In open source, a lot of folks just like building stuff and solving problems, trying things and seeing the impact—and being able to do that with other people is really great. You can literally have engagement on a line of code and go back and forth on it, and merge these really fine grain changes. Software is one of the most distilled and pure forms of collaboration: It gives people a common way to work together and collaborate. Make it count.