How to Be an Effective Open Source Contributor

I’ve been working in open source for a while now, but I still remember what it’s like to start out. Joining even the most interesting sounding open source project can seem intimidating at first. You’ll likely see a ton of code you aren’t familiar with, perhaps written in languages you don’t yet know, about an area you’ve yet to explore in-depth. It can be hard to know where to begin, let alone how to get up to speed and eventually become a key contributor.

So, what do you do? Here are six things, based on my own experience, that can help you quickly make a positive impact in whatever communities you decide to join.

1) Communicate clearly and openly

Open source teams rarely occupy the same office, city or even time zone. They need clear channels of communication if they are going to be effective. The same goes for you. You need to be clear with other team members about what tasks you are working on, the progress you are making and what you are delivering.

So, before you take an issue, note that you are taking it on in a comment. Otherwise, someone else might be working on it and you’ll duplicate their effort (this happened to me when a bunch of new contributors joined a project at once and none of us shared what we were working on). If you want to propose a pull request (PR), first create an issue for it, ask for feedback and agreement on it from the community and only start on the PR when you have the okay.

Secondly, keep all your communication public. Avoid discussing your issue, progress or any problems you’re having in private messages. For one thing, that limits your pool of potential helpers. But it also prevents others from finding documentation that could help them when they have similar questions or problems.

Lastly, canvass team members to see if your estimates for how long any piece of work might take you are right. If, based on their feedback, you likely won’t have the time to deliver the work, it’s best not to start. In other words, take on jobs that you know you can deliver.

2) Manage your time

In my mind, there are five major ways to waste time in open source. You can:

  • Work on the wrong thing
  • Be distracted
  • Have writer’s block
  • Not know where to start
  • Not know what to do next

I’ve struggled with all of these, but I’ve also learned a few strategies to mitigate them.

First, you must prioritize. For that, you need a good task management system. I note everything I’m working on in a tracking document, but the main thing is not to keep everything in your head. When new tasks come in, you need to be able to place them in a logical (and therefore most effective) order of action. When it’s not clear what to prioritize, closing out some smaller tasks will help you feel like you are making progress. Or, you can do some of the tasks that you’d rather avoid just for the satisfaction you’ll get from having them behind you.

Next, you need a strategy for staying focused. Set yourself a period of time during which you can commit your full attention to a task. The longer the better, since it can take time to pick up the thread of where you were in an issue. But also get to know what it feels like when you stop being productive. When that happens, go do something different and give your brain a rest.

And don’t forget point one above: communication. When you aren’t getting anywhere, don’t keep it to yourself. Reach out for help. Remember, there are no bad questions—just describing a problem to someone else can help you see how to solve it. And always check to see if anyone’s dealt with the same issue before—this can save you hours.

open source contributor

3) Simplify your process

Once you start working on your contribution or issue, first see whether someone has already addressed a similar problem, either in the project itself or others. Can you follow their lead, and perhaps even improve upon their solution in some way? If you can, grab the opportunity—it can save you hours.

Try to not start coding, debugging or testing without a clear idea of your overall goal. It’s easy to go off on tangents once you are in the code/test/build weeds. Take the time to map out the discrete steps that you want to take and then it’s much easier to stay on track as you complete each step.

A related point: don’t over-engineer. Our industry tends to admire people who implement complex ideas. But complexity is really something you should be looking to avoid—aim for the simplest, shortest path to a solution instead. In addition, breaking a complex problem down into the simplest possible set of steps is a good way to see where the challenge really lies.

4) Improve your technical skills

Our technical skills don’t tend to plateau. Instead, we’re usually either getting better or worse. You want to be on the right side of this equation. So, make a point of figuring out what else you need to learn about the technologies used by the projects you’re interested in, and then go find that information. And don’t be afraid to take on something new and difficult. It’s the only way to grow beyond your current area of expertise.

The most powerful way to keep improving is to take on real issues and solve them. In my experience, it’s a better way to learn than reading a book or coding on your own (but do that too!). It also helps you get over the sense that there’s so much to learn that you will never master the subject. Just master one issue at a time and before long you will actually know more about the project than most people on the team.

5) Keep things in perspective

In some of my previous roles as an engineer, I was expected to be 100% focused on the technical details of a software problem. But that didn’t necessarily help me come up with optimal solutions. It’s a cliché, but inside-the-box thinking really does make it harder to think your way out of whatever box you are in. You need to make sure that you have that wider view.

You can do that by talking with colleagues about the project you are working on and the work you are doing. You can read articles about the technical fields you are engaging with, attend relevant talks and conferences or meet with anyone from the industry who might have a useful perspective, like architects or end users. Check out projects in related areas and think about what’s going to come next.

With a sense of the wider landscape, you can make your everyday work easier and more productive. You will be helping your project since open source efforts rely on their communities to help establish their direction. And by taking the time to bring a wider perspective into a project, you can increase your own impact as well.

6) Be patient with yourself

This last point is perhaps the most important of all. Nobody becomes an expert overnight, so don’t expect yourself to be one. It’s common – normal, even – to feel like you aren’t getting anywhere at first. Don’t give up on your aspirations if they are hard to achieve at first.

Again, I know this from my own experience. When I was invited to work on OpenFaaS, I didn’t know anything about containers, Docker or Kubernetes beyond their names; I hadn’t heard about serverless frameworks; I hadn’t written in Go. So, I felt really out of place at first. But within about five months, I was a top-five contributor on the project and after five more I felt fully up-to-speed.

In conclusion: there’s a lot you can do to maximize your chances of making an impact in open source. Be deliberate, focused and patient—you’ll surprise yourself at how quickly that feeling of being overwhelmed turns into the satisfying sense that you are making a real contribution.

Stay tuned to the Open Source Blog and follow us on Twitter (@vmwopensource) for all the latest open source news and updates.


Leave a Reply

Your email address will not be published. Required fields are marked *