On an average day, Ryan McKinley gets about four job offers from companies that use — or want to use — the search engine Apache Lucene.

That’s because McKinley, as an early contributor to Lucene’s open source codebase, is one of a handful of developers with the authority to make high-level changes within the project.

McKinley, however, isn’t looking for work. He’s the VP of applications at recently formed Grafana Labs, which builds commercial-grade software atop the Grafana open source project. The company hired him because he was the project’s leading community contributor. 

After decades using open source to advance his projects and his career, McKinley has a few takeaways for engineers looking to parlay open source contributions into career growth.

 

 

Open source projects show how you collaborate

For companies that rely on a particular open source software product, it makes sense to bring on the people who are most familiar — who have watched the project progress and taken an active role. And for talented developers, open source presents an opportunity to spin ideas and contributions into a sort of personal brand, as opposed to the relative anonymity of a corporate gig. 

So McKinley checks out the GitHub profiles of every single candidate he interviews. 

“Seeing open source activity is so important, and it makes things so much easier as you’re hiring, mainly because you genuinely see not just work product, but how people participate in a community,” he said.

Seeing open source activity is so important, and it makes things so much easier as you’re hiring.”

Unlike working in a traditional office, open source collaboration relies on what McKinley calls “asynchronous written communication,” or the kind of messages you’d find on a Reddit thread. This, along with the emphasis on innovation and individual contributions, presents unique opportunities and challenges for open source developers.

In an open source repository, your work also has your name on it — whether that’s a bite size contribution or a full-fledged operating system. Make valuable contributions, and the people at the helm take notice. Make a bad showing, and that behavior could haunt you.

 

Skill matters, but so does the way you interact with fellow contributors

At Grafana, like any company, job candidates must have the technical skills needed to excel in their prospective roles. But that’s not why McKinley checks candidate GitHub profiles.

“When people are actually contributing in a community, you see how they respond to comments,” he said. “When I see people who are engaged in doing useful things and saying things politely, it’s a huge positive signal.”

While, in some spaces, open source retains an identity as the wild west of software development — a pure meritocracy, where there’s no dress code and no office politics — its progression toward the mainstream has brought with it some mainstream sensibilities when it comes to how participants communicate.

In fewer words: There’s less patience for jerks.

Just having a technical solution is almost never enough.”

Like on Twitter, YouTube, or any other corner of the internet, the relative anonymity that comes with a keyboard and screen makes it tempting to be less than kind. Some people point to inappropriate language and personal attacks to explain the lack of diversity in the broader open source community — one GitHub survey found that 95 percent of open source contributors are male. 

Expectations are shifting, however, especially when it comes to major projects. Today, more than 40,000 open source projects have adopted the Contributor Covenant, a code of conduct created by notable Ruby developer Coraline Ehmke that condemns sexual language, doxxing and any other conduct “which could reasonably be considered inappropriate in a professional setting.”

While Ehmke experienced intense pushback from some factions, major projects including Google’s TensorFlow and Linux implemented the guidelines. That means project maintainers, as well as hiring managers such as McKinley, are keeping an eye not just on what contributors say, but how they say it.

“Just having a technical solution is almost never enough,” McKinley said. “It’s a professional forum in which you’re lobbying for what you want. And in every community, people know who the bad actors are, who’s coming to a thing and just demanding attention and insulting people.”

 

 

Practice good communication by staying patient and receptive

So, aside from obvious points like avoiding inflammatory language, what are best practices for professionalism when you never meet your collaborators face to face?

One is to understand and respect maintainers’ roles. Maintainers oversee open source projects, but they’re not responsible for fixing the bugs you find or creating the features you need. 

“People often expect the maintainers to do stuff, as if they had paid them. Like, you're not submitting things to Microsoft, they're real people,” McKinley said. “You don't get motivated by people coming to your project and saying, ‘I asked for this feature four years ago and still no progress?’”

People often expect the maintainers to do stuff, as if they had paid them.”

Another is to keep in mind that contributors come from all over the world, and many use English as a second, third or fourth language. Intent is difficult to interpret in written messages, so give other contributors some grace if their messages seem curt or confusing. 

Lastly, stay open to feedback or opposing ideas from strangers. In an office setting, feedback comes from a boss or coworkers you know well — there is an established hierarchy, and the people you work with likely understand how you prefer to take criticism. In open source, community developers play a large role in the direction of a project, and that makes room for spirited debate and lots of feedback. Defend your good ideas, but be ready to adjust them or, sometimes, drop them.

 

Get involved by solving a problem that matters to you

If you want to add open source work to your resume, choose projects that address real problems you’ve encountered — or projects that simply would make your work easier. 

McKinley first became involved with Grafana as part of his job at a California renewable energy company. The company was developing a hydroelectric turbine, and existing system monitoring software was expensive and had many limitations. 

McKinley started using Grafana instead, which was — to his company’s delight — free, and he shared his solutions with the community at large. 

There’s no time that you can just say, ‘There, I fixed it and changed thousands of lines of code!’ and that’s your first contribution.”

For example, when McKinley wanted to monitor the deflection of a component inside the turbine, he found that Grafana wasn’t set up to display the kind of high-resolution data typical of industrial monitoring networks. The software was created to monitor servers, so there was no initial need for a feature that can show one thousand data points per second in real time. 

McKinley and his collaborators changed Grafana’s API to an RxJS observable, which allows the data source to send continuous data in response to a request, rather than one response per request. 

That adjustment solved McKinley’s issue. After officially joining Grafana Labs, he pushed to make that structure available for all users, and now it is, he said.

 

 

Start small with your first contributions

Your interest in an open source project may extend beyond its applications to your work. In that case, there are other ways to get involved. If you’re new to a particular project, McKinley’s advice is to start small. 

“There's no time that you can just say, ‘There, I fixed it and changed thousands of lines of code!’ and that’s your first contribution. That’s never going to happen. No one’s going to read it,” he said.

Before jumping in with new ideas, get familiar with the project. Read the “contributing” file at the top of the repository, and read through the project’s archives to see what’s already been proposed and implemented. Learn the project’s governing system and recognize key players, and sign up for any associated release notes or newsletters.

Perhaps most importantly, review the project’s documentation and notice how it’s structured, and find out if there’s a template for pull requests. If there is, follow it.

 

Code isn't the only thing you can contribute

Keep in mind that code changes are just one way to participate. Writing or updating documentation, compiling newsletters and organizing conferences are helpful contributions, as well. In fact, one study found 28 percent of casual contributors stick to fixing typos and grammatical problems in documentation. 

McKinley said one of the best ways to contribute to a project is to notice the features you struggle to use correctly and update the documentation to make the directions clearer. Another way is to submit failed tests and help find a fix. 

“You can say, ‘I tried to follow this thing, and it actually didn’t work the way you said it would work. If I had read this, I would have been on the right track,’” McKinley said. “That’s perhaps the quintessentially perfect example of just learning the tools, learning the structures, and understanding what the community is like.”

With open source, there are big advantages to starting small. By building your reputation in the project’s community and showing you understand its trajectory and can work well with others, you earn the cache to make larger changes later on.

“There’s no golden ticket anywhere, but I’ve always found that working as an individual and extending projects for what you need but still being sympathetic to what the community is trying to do is positive for everybody involved,” McKinley said.

 

 

Stick to a clear structure when you pitch new ideas

When McKinley reviews candidates’ GitHub accounts, he looks closely at how they present and justify their suggestions. 

Since fresh proposals need support to be implemented, an idea likely won’t make it far without a well-crafted pitch. Furthermore, with multiple issues and pull requests happening at once, maintainers and contributors need plenty of context to see how your idea fits into the big picture. 

“Unlike a really structured corporate environment where you can have clear goals, like this product should achieve A,B,C, in an open source world, you're always having lots of contributors that are saying no, it should also do X,Y,Z,” McKinley said. “And those aren’t always good ideas, which makes it hard.”

Some projects have templates for issues and pull requests, but even if yours doesn’t, commit to a clear structure for your communications. For more involved fixes or suggestions, break your proposed idea down into manageable chunks, and outline what needs to happen at each stage.

Even the most respected people within the community will be pushing for things that don’t happen.”

Other contributors will review each unit of work you proposed to determine if it’s a step in the right direction for the project and if your solutions are understandable enough for other people to test. The clearer your explanations, the smoother that process. 

“It sounds like a science when it’s described that way, but it’s also pretty rare to be able to do it well,” McKinley said. “And it takes training to have clear chunks of understandable code and contributions.”

Even if it takes a while to get good at partitioning your projects, there are other ways to spruce up your issues and pull requests in the meantime. First, respect maintainers’ time by doing your research before firing off questions and by using project-specific threads to communicate, rather than email. If you encounter a problem you’d like to solve, provide some context like a failed test or the exact scenario in which a bug happened. If you open an issue or pull request, keep an eye on it until it’s resolved — or nixed. 

In this way, open source projects are excellent places to build product management skills to complement your technical ones. Pay attention to how accomplished contributors frame their suggestions, and learn from what doesn’t go over well. 

“Even the most respected people within the community will be pushing for things that don't happen,” McKinley said. “Happens all the time.”

 

 

Strong open source contributors get job offers

In a traditional interview for a software development position, candidates complete coding challenges and brain-teasers, hoping their skills will shine through to hiring managers. 

Open source gives developers a chance to show potential employers what they can do without even walking in the door. As more companies turn to open source for fast innovation and top talent, expertise with particular software will become increasingly marketable. But it’s up to individual contributors to hone their communication and product management skills enough to make an impression. 

McKinley turned to Lucene after realizing his own attempts to build a graph database would benefit from the community’s collective knowledge. Two decades later, he’s at the helm of Grafana Labs’ efforts to harness the open source ethos to make the software as flexible and functional as possible. He works with a global team of developers, and, often, he hires them.

“If people get engaged in the Grafana source code, wherever they are, and start making actual contributions, like all of those people get offers,” he said. “Same thing is true of every company I’ve seen. They will hire people who become relevant in the community.”