Open source is like a second job

When I started working as a software engineer, I really wanted to work full time in open source. I've been lucky enough to spend a decent chunk of my career doing exactly that, and my thinking on open source work has shifted over the years. Much of that work has been incredibly rewarding, but for readers interested in taking a similar path, I want to share an insight and a warning. First, succeeding in open source is less about code and more about human relationships. Second, it's hard to get paid to work in open source, so be sure you have support or you'll burn out.

Why open source appealed to me

Before I finished grad school in 2010, open source seemed like the place to solve the most interesting technical problems. People were building new operating systems, compilers, and new infrastructure. A thousand flowers were blooming. Not all survived, but many did, and we take them for granted today: Android, Chrome, Go, and Rust were all launched within a few years of each other. In contrast, proprietary software seemed boring at best (office apps, ecommerce) or predatory at worst (ad tech, high frequency trading). My views were naïve, but they were reinforced as I worked in proprietary software for the first several years of my career.

At my first job, I worked on an operating system for flip phones. Smartphones were rapidly gaining popularity, so Android completely ate our lunch. Although we had many of the same features, Android had a better model: as open source, it could easily be adopted and integrated by more manufacturers. My department shut down a year after I joined.

At my second job, I worked on a proprietary fork of an open source web browser. This was fun and interesting work, but at the same time I saw our partners at other companies cheat benchmarks, accidentally introducing severe security vulnerabilities in the process. That didn't seem to be making life better for our users.

At my third job, I worked on an office app suite. Among other things, we added conversion-tracking code for apps we paid to be force-installed onto people's phones. Surely, this was not in the users' best interest? Would people actually tolerate this if they could see and change the source code?

What work in open source looked like

I joined the Go team at Google in 2017. It was my first job working full time in open source, and it was a dream job in many ways. I got to work on a product I admired in an area that really interested me (compilers, languages, build tools). I had more opportunity to work directly with users on what was most valuable for them without focusing too much on whether it would make money.

I grew more as an engineer during those years than at any other point in my career. My programming skills were fine by then, but communication, writing, and project management mattered a lot more.

My first project at Google was Go support for Bazel (rules_go and Gazelle). I worked for a while with one other engineer (who later became my manager) and a technical manager (who became the CEO of EngFlow where I work now). We worked directly with the Kubernetes engineering productivity team and implemented features they needed in Bazel. Unfortunately, Kubernetes' use of Bazel didn't work out, but rules_go and Gazelle are still well used in many other projects today.

Later, I worked on Go modules and a number of other features in the Go command. The addition of modules has been the biggest change to how people use Go, bigger than generics. We took a lot of feedback from users but ultimately decided to take a risk and design in a different direction from other tools. I'm very happy with how it turned out, and I think today most users are too. Go modules are best in class for their simplicity, speed, and security.

We got a lot of very negative feedback on modules early on though. I learned the importance of having a thick skin and good community managers who are willing to ban people. But perhaps more constructively, I learned that good documentation is crucially important. We wrote a series of blog post tutorials and thorough reference documentation. Without exaggeration, writing the reference documentation was the most important thing I did while at Google. Within a few months, the attitude of the community shifted from very negative to very positive, and nearly all projects migrated to modules.

An insight

Open source is a big commitment of time, energy, and mental space. I was very lucky to get paid to work on open source full time. For most people, open source is often like having a second job: if you are paid to work in open source, it's often as a secondary responsibility in addition to your "day job". You have a second set of coworkers: the community of contributors outside your company. You have a second set of projects: those that are important to the community but not to your business. You have a second set of bugs to triage, changes to review, and releases to manage. You may also spend time attending conferences and building community outside your normal work.

As is usually true for your first job, your connection to your users and your collaborators is the most important thing for getting things done and having impact. Active communication is your best strategy for strengthening that connection. Good technical writing is more important than good coding.

Communication skills are actually even more important in open source than they are in a typical office environment. Your collaborators tend to be all over the world working at odd hours, and face-to-face meetings are rare. You need to be comfortable with asynchronous messaging, which usually means overcommunicating a bit to avoid unnecessary back-and-forth. Your collaborators tend to work for many different organizations with different priorities, so you often need to be able to resolve disputes yourself since there's no manager to escalate to. Power structures tend to be more diffuse and less defined. Tyranny of structurelessness is more common than not.

A warning

I ended up leaving Google in 2021. There were several reasons behind that, mostly pandemic burnout, but relevant to this article, I felt that open source impact outside Google wasn't rewarded at higher levels, and I didn't see a good career path for growth. Put another way, it's straightforward to get promoted for saving Google money and improving the lives of Google engineers; it's hard to get promoted for saving other companies money and improving the lives of their engineers.

Most companies don't directly support their engineers in open source much at all. That second job metaphor breaks down because it doesn't come with a second paycheck. It takes time away from your main job. There's tension between what your business needs and what your community needs.

Some balance is possible, but it's difficult to sustain. When I lived in New York, I served on a grand jury, which required me to be in court three hours a day for a month. Court was a short subway trip from my office, so I still worked five hours a day. To my surprise, I was still able to get most of my job done. I was still pretty effective even though my office hours were reduced by 40%. So it is possible to work like this, temporarily. It's hard to actually be good at either job though. I'm sure I wasn't on track for promotion at the time, and if Google or the state of New York had asked more of me, I would have been in trouble. Forget having hobbies and exercising regularly.

I think the actual best case scenario is when you can get sponsored to work in open source full time, either by a single company that employs you or through multiple companies paying consultancy fees, ideally without attaching too many strings. This is a platonic ideal, not achieved in the real world, but I've seen some people come close. A former coworker left Google to become a professional maintainer of Go cryptography projects. Last year, I met some people from GerritForge who seemed to be doing well. And I know a colleague at a competitor who works full time on an open source product that both our companies sell services for: the goodwill and benefit to the ecosystem justify the expense for them.

The challenge with this model is that your work still needs to be aligned enough with what your sponsors want that it's easy for them to justify paying you. It's often easy to find alignment in theory, but it's hard to quantify business impact. For example, good cryptography libraries benefit everyone, but how much should you pay your independent friendly neighborhood cryptogopher? This is a problem when you're employed by a single company, too: how do you justify a promotion when your work mostly benefits people outside the company?

The other major issue with this model is that you need to achieve some level of fame and notoriety first. That takes time, effort, expertise, achievement, and a good professional network. It's certainly possible to get there, but you have to establish yourself as an expert first, without much support.

Closing

I still think, perhaps naïvely, that open source gives the best opportunities to work directly for people who use your software. It is hard to get into, but it can be personally fulfilling if not always financially rewarding. You'll meet many interesting people and build an expansive professional network outside any one company. You'll develop more leadership, community building, and communication abilities than you expected, which are valuable skills in any context. And hopefully you have some fun, solve some interesting problems, and get paid along the way!