Open source exception monitoring tool Sentry held their first Sentry Scouts Meetup in January, bringing together open source experts from Stellar, Uber, Algolia, and more. If you weren't at the event, don't worry- we're bringing all the insights to you.
It’s probably not news to anybody that open source can open a lot of doors in your life and career. But what’s also true is that many developers aren’t contributing to open source software either in their free time or at work. Maybe you don’t know how to get started. Or maybe you can’t convince your manager of the value of open-sourcing your next project.
Whatever might be holding you back, there are many who have gone before you and have advice for being a valued open source contributor, no matter your circumstances. We have advice from engineers at Uber, Algolia, Docker, and more, all with extensive open source experience and plenty of stories to tell.
You can start with a small contribution
Anybody who’s done it will agree: you can get started with open source software contribution at any time, even in the smallest of ways. “Scratch your own itch,” advises Nathan LeClaire, Senior Engineer at Honeycomb.io. If you run into a bug while using open-source software, fix it! Senior Software Engineer of Android at Uber Zac Sweers points out that your contributions don’t always have to be code. You might begin with a project’s documentation, correcting spelling errors to get your feet wet. However you choose to jump in, the only thing that matters is that you take the leap!
LeClaire used to work at Docker. A developer in the Netherlands, he remembers, began commenting on a lot of issues, eventually becoming almost a project manager and organizing issues into groups, tracking their progress. He wasn’t submitting pull requests at all, but he was still contributing; Docker ended up hiring him full-time.
Scott Chacon, one of the cofounders of GitHub (and current CEO at Chatterbug), recommends you find a project that interests you and go through the issues, or even email the maintainers and ask them what they’d like fixed and how you can help. Being helpful goes a long way.
We all experience imposter syndrome at some point. But Ali Finkelstein, Developer Evangelist at Stellar.org, says not to let it keep you from contributing where you can; it’s easy to assume that whoever wrote the code has already thought of everything, but that’s simply not true, she says. "Everyone comes from a different background. The way you view a problem might be absolutely different from the way the people who wrote the code view the problem."
“Before I started contributing to open source,” says LeClaire, “[I thought] it’s for smart people or more advanced developers. But really, anyone can throw a project up on the internet. We assume that if we’re using this abstraction, those people know what they’re doing and they’ve thought of everything. But they’re human beings like you and me and they need your help.”
It's all about community
Another thing to remember is that any open source project you come across (or any open source project you build yourself and invite others to contribute to) is a group effort. "It's teamwork," says LeClaire. "It's collaboration happening here. It's community." And that community is global; open source is a great way to meet people you’d never have a chance to speak with otherwise, to make connections and expand your network across distances and cultures.
When Sweer was at Flipboard, his team began using a Material Design library written by a developer in Beijing. They began contributing to the library and ended up collaborating with the maintainer quite a bit. Eventually Sweer was able to meet him in real life when he began working full-time for Flipboard; this friendship could never have happened without open source software.
What if you are the maintainer? What if you’ve built a product or tool, and a community has formed around it? Sometimes this happens almost by accident, and you need to be ready to handle it. The community aspect of open source can cause tension and confusion when people don’t agree, so it’s important to develop interpersonal and communication skills.
"A lot of tension has to do with lack of clarity," says LeClaire. Franzisca von der Goltz, Software Engineer at Buoyant, agrees: "Be really specific in the issues" of your own projects, she advises. "Be as specific as you can, which will take away the barrier of entry from someone looking at the issue. They'll see it's really detailed. I know exactly what steps to follow, exactly what to do. I'm going to do it."
Josh Dzielak, formerly of Algolia, stresses the importance of having an explicit code of conduct, and believes your decision-making process can also be made explicit. Avoid alienating your contributors by being very clear about your decision-making process and you how you make the calls regarding which PRs are accepted and which are rejected.
"’If you don't like it then fork it’ is a really bad way of doing community management," says LeClaire. "Open source is about the people involved," agrees von der Goltz. "A project can be really great, but if people are not nice you’re not going to want to get involved. It’s about the people, not just the code.”
While it's possible for a community to spring up on its own, it's more likely you’ll have to work for it. Dzielak speaks to this challenge: "When you build a community, the first 1, 5, 10, 20, 50" come by hand-to-hand outreach, emailing and texting. "You have to bootstrap the community," he says. And then, if you want your community to thrive, you have to treat them well and foster a culture of respect.
Open source at work
One of the biggest challenges developers face is convincing their companies and managers to embrace open source development. But the benefits are undeniable. Sweer says Uber uses Square's libraries often in their Android development. "They're wheels we don't have to reinvent, and they're really good wheels!"
Chacon agrees. "Everything that we go to do, there's something online to do it and we can take that and make it better. In the ecosystem almost anything that you're doing, there's something to start with and something to contribute to as opposed to starting your own thing from scratch."
Dzielak and von der Golzt both say their companies (Algolia and Bouyant, respectively) use open source as a feedback channel. Algolia's customers are developers themselves, so they can observe in real time how developers are working with their product and what kinds of changes they're requesting. "Is the developer experience good? Is it friendly? What are we missing? What are people trying to do with the search engine? We actually get a lot of that feedback coming through issues and PRs" as opposed to more traditional user feedback channels.
Bouyant is a small team, unable to use the tools they build at the same scale as some of their larger customers. Since they're completely open source, those larger customers are able to come back and tell them not only "this doesn't work at scale,” but “here's a PR to fix it."
Chacon points out that it's easier today to get management buy-in, since everybody from Microsoft to Facebook is open sourcing their software tools. He advises telling a reluctant manager, "This is going to save us time, to use this library and contribute to this library rather than rolling our own."
Dzielak agrees: "Describe it in terms of the impact it can have in your company’s ability to recruit. The manager’s job is to ask about impact. How is this going to help us meet the objectives of the team. I think in a lot of cases contributing to open source will help you meet the objectives of your team. If your manager is spending a lot of time sourcing candidates to hire and you go out on an open-source project and you meet some amazing people who you think would be great engineers to work with, then you’re potentially saving your manager’s time there. If you can frame any of that in terms of the impact or in terms of the time that you can save your leadership, then you can make, I think, a stronger case for it.”
Sweer recommends getting your whole team excited about open source through hackathons. "Embrace things like that when they come along," he says, or throw your own. If somebody on your team is building a new product, ask them what they think about open sourcing it. "Chip away at it and try to make it a cultural thing, or if you have a smaller company you're there on the ground floor trying to make that part of your policy" from the start.
If you’re interested in pursuing open source outside of work, on your own time, but have trouble fitting it into your schedule, von der Golzt recommends attending open source meetups. "You can carve out a few hours of the day you're not at home," she says. "You're not distracted by your family in general. And there are mentors there. They'll help you get set up and then you have a working version on your laptop and it's easier to work in small pieces when you're home."
A few don’ts
One thing you shouldn’t do, advises Chacon, is spend a lot of time making sweeping changes, like changing every sentence to a different tense, and then submit them all in one massive pull request. Make your changes in small bursts, he advises, or reach out for guidance, before you pour hours into a single direction with no input from the maintainers. After all, if they don’t agree with what you’ve done, you’ve just wasted a lot of time.
Dzielak cautions against the opposite: making changes so small they become annoying. “Small PRs are one thing,” he says, “But don’t just spend all your time fixing white space.”
Another don’t is making unreasonable requests of maintainers. “Don’t just email the maintainer,” says Finkelstein, “like hey, do you think you can write this entire functionality for me for free?” Open source software is a wonderful thing, and it’s definitely possible to customize it to your liking. But chances are the maintainer has his or her own vision, and remember nobody is paying them to build this stuff. If there are major functionalities you want to see, offer to help build them yourself. Open a conversation with the maintainers; you never know where that may lead you!
Andy Tuba of Reddit is a prime example. “There was a feature missing in Reddit so I added it,” he says, “and it got released. That was my first PR in GitHub...I made friends that way and kept contributing” until he was eventually hired by Reddit full-time.
Final thoughts
There are countless opportunities for developers at every level to make their mark and contribute to the industry through open source software. Whether you’re developing your own project and and building a community around it, or joining somebody else’s community and contributing to their work, the beauty of open source is that it’s welcoming to everybody. It can foster connections and friendships, build skills, and open doors.
Quotes from Sentry’s Sentry Scouts Meetup on Open Source, January 17 in San Francisco.