How to advance your career by contributing to open source projects

My 16-year-old son, Prahlad, just walked into our apartment. "What did he say???" I ask. "He said 'Yes'."

Understated, playing it cool, like many teenagers do with their parents. But I know he's deeply excited, and probably a little bit scared. He just got a gig working at the tabletop and role-playing game store in the building next to our apartment block in Brisbane, Australia.

I coached him on how to get it. I saw that he was enthusiastic about the games they sell there. He plays Magic: The Gathering (MTG) there with his friends, and a couple of weeks ago I came home to 20 teenagers (yes, twenty!) in our apartment playing the game. He went to the recent MTG pre-release and played it all day.

"Why don't you ask Sean if you can do some part-time work in the store?" I suggested. Sean is the owner of the store.

Prahlad asked Sean, and Sean said that he doesn't have any work that needs to be done there.

"Go back and tell him that you want to get work experience," I told him. "Tell him you'll do it for free. That way you can learn from him. He is running a successful business, and you can learn that. You can learn how to be a dungeon-master, how to run events, and how to do customer service. You might find ways to expand the business. And if it doesn't turn into a paying gig, when the time comes you can get a job at another store, based on your experience."

So he had that conversation, and he starts tomorrow.

The impact GitHub is having on your software career, right now

In 2017, I wrote my (so-far) most popular article of all time, "The Impact GitHub is Having on Your Software Career, Right Now…," on Medium. In that article, I cast the vision for how you can develop your career through open source contributions. It clearly struck a nerve—it got 382 points and 237 comments on Hacker News. Many of the comments hated on it so hard—they disagreed with my main premise—but I felt they had missed the point. At the time I was a recruiter with 10 years of engineering experience, working at Red Hat.

They said:

• My experience at my job was atypical. There are no other opportunities like that.
• I didn't know what I was talking about because I was a recruiter (they must have skipped my "10 years in engineering at Red Hat" part).
• It was unrealistic advice for developers with a day job in companies working in BitBucket.
• It wasn't possible for devs who work in companies in the financial sector with high regulation and security.
• It wasn't possible if you weren't willing to sacrifice your life outside work.
• It just wasn't possible.

There is nothing I love more than a challenge, so I went "deep cover." I quit my job as a recruiter and got a job as a software engineer in a pure closed-source company that uses BitBucket and has PCI-compliant security. Fourteen months later, I got hired by Camunda to work as the developer advocate for Zeebe, a workflow engine for orchestrating microservices, purely based on my open source contributions while working at that job. I just did everything I advised readers to do in the comments of my original Medium article.

While I was doing that, I didn't sacrifice my hobbies nor my family. In fact:

• I kept building my side hustle Magikcraft.io
• I did a launch event for Minecraft for Type 1 Diabetes that was filmed for Mojang's YouTube channel.
• I trained for and competed in three physique competitions with my wife—it was on her bucket list to win a bikini-modeling competition. She won her division, and I eventually placed second in a state-level competition.
• I trained to lead a personal development course.
• I did a three-month-long course with my son.

I don't say this to brag, just to show that it's not a zero-sum game, as some people paint it: "Oh that's easy to say, but it privileges people who are willing to work for free and sacrifice their time with their family."

False.

Of course, for the person who starts with the conclusion that "it's not possible," no amount of evidence is ever going to be enough—and to that person, I say: "What do you want to see now?" Not because it will change their mind, but because it's a fertile source of inspiration for me.

Misconceptions and strawman arguments

Before I sketch out how to do it, I want to explicitly state a couple of common objections that miss the point:

• You can't tell anything about a developer from their contribution graph on GitHub.
• I've hired lots of developers and never looked at their GitHub profile.

Let me just say this: You aren't going to get hired through your open source contributions by these people. That's all those things say. There is more I could say about that, but I'm not going to address them any further. I also want to make it clear: I'm not saying that you have to do this. Just that you can.

How I did it

As I pointed out to commenters on the original Medium article, in your day job, you can either use open source libraries or may be able to introduce some to your stack on new projects. If you don't have a day job, then you can introduce them to your stack easily.

While doing research for a new project at my day job, I tried a number of different projects, including a TypeScript gRPC server. I found a bug in it and opened an issue. Then I wrote a patch for it that got merged in. We didn't use that project, but it was just part of being a member of a global community, like picking up a piece of paper in the hallway of our apartment building or on the street. We eventually did use a gRPC library, and we needed it to support gRPC streams. So I wrote a patch for that, and it got merged. That contribution was enough to get me a mention in the contributors on npm.

I opened issues and submitted patches to Netflix Conductor. Nothing earth-shattering, just contributing to the environment I live in.

One of the things I explained to management was that a key decision-making factor in which technologies we should adopt is how fast issues get addressed and, if we patch something for our own production use-case, how amenable the maintainers are to accepting our pull requests to the mainstream. No one involved in hiring me at Camunda looked at these (callback to the peeps who say they never look at people's contributions on GitHub: "X-Factor" judges don't watch you practicing in front of the mirror either, just sayin'). I will say, however, that smart recruiters at Google and Facebook would hit me up based on watching my activity. It's not enough to land a job, but it does have people come looking for you, especially as you build up a history.

The big break

The big break came when we landed on using Zeebe as the orchestration engine for our new microservices project. I was over the moon, because Zeebe had an officially supported Go client, and this was my chance to get our team coding in Golang. I'd done some proofs of concept and side projects in it, but we coded in JavaScript. No one else on the team of six was keen to make the move, however, so we needed a JavaScript client.

I managed to get alignment on using TypeScript for the new project, so I created a TypeScript client library. I had logged some issues and contributed some small patches to Zeebe, as part of the civic duty/evaluation. Now, I pitched to management the idea to make the client library open source. My argument for it had two parts:

1. It means that our library has the opportunity to become the most widely used one, which means it gets more eyeballs on it and the possibility of patches from the wider community. In other words, we don't end up maintaining something internally and finding out later on that there is a more widely used/supported one that we have to rebase on.
2. It is a good developer-marketing tool to raise our profile, build our engineering brand, and differentiate us in the market when hiring.

I got alignment. However, the company had no GitHub presence. I got that by explaining that we needed a GitHub organization in order to collaborate with the engineers at Camunda. This is a company with no prior experience in open source. I had the advantage that I spent 10 years working in it, so I knew both that it works and how it works. Looking back, I probably wouldn't have stood for it the way I did if I had an ounce of doubt—if I "listened to the haters" in the comments.

Once that was in place, we pushed the library live and published it to npm. One of the things that can you develop over time participating in open source as a civic member is a sixth sense for opportunities. I could see that this was an exciting technology that was poised to land on a rising wave—and we were about to ride that wave too. And there was no JS client.

It took over a year for the factors to align, but if I were sitting at my desk committing to BitBucket only (yes, I was committing code to private BitBucket repos, too), then I wouldn't see an opportunity like that in 10 years.

I wrote an article on Medium.com announcing the library. I actually got in trouble for that. I jumped the gun and didn't get alignment for it before publishing. Lesson learned. However, the library, the article, and my participation in issues, patches, and the Slack channel got me noticed by the folks at Camunda. Enough so that, when I was looking for another role, they acted fast to hire their first employee in Australia—faster than local companies moved, even with their time zone and established infrastructure advantage. On a call with Berd Rücker, one of Camunda's cofounders, I shared why I thought it was a good match: at Red Hat we would often hire or acqui-hire (bring an entire project in, people and tech—it's a portmanteau of "acquire" and "hire") from the community.

We would find someone who was already doing it and just pay them to do it for us. Normally when you hire, you find someone, pay them, and hope that they will enjoy what they are doing and be good at it. Hiring open source contributors reduces the risk. They still might turn out to be terrible to work with, but you have a sense already of how you work together and you know what their work is like.

It's a universal principle

So, it's the same thing for my son. He has the opportunity to demonstrate value, build trust, and gain skills at the gaming store. And when the time is right, he will start getting paid—either there or elsewhere.

At the career fair for Red Hat in 2004, I brought along a 20-page paper I had written where I predicted the future of tech: open source eating the world; devices shrinking to hand-helds; emergent network effects. I wrote it on breaks while working on a help desk, between installing Linux on old computers I bought for $20 a pop.

In a recent Slack discussion, someone said: "The problem with open source contribution is that it privileges those who have time to do it." First, that's the opportunity of open source, not the problem. Second, everyone has the time—and I would say the civic duty if they use it—to contribute something. And last: Yeah, that's right. It's just like people who have the time to play clubs and pubs every Friday night and practice their chops in their bedroom are privileged to be able to be discovered by an A&R talent scout and get a record deal.

The Beatles played for two years straight in Hamburg to hone their skills. As a professional software developer, if you are going to hone your craft anyway, you might as well do it in a way that contributes to a greater civic good and your own portable, public reputation.

Or not. Whatever. I'm just saying that it is possible.

This article was originally published on DEV Community and is revised and reprinted with permission.