How to Start Contributing to Open Source Software

The Petabridge team (all two of us) just wrapped up a big two weeks. We launched Akka.NET V1.0 and then traveled to Portland to talk about .NET open source software at .NET Fringe.

One of central themes of .NET Fringe is open source communities - and there’s two sides to this coin:

• How does an open source project successfully attract contributors and make them effective?
• How does your typical software developer become an OSS contributor?

I’m going to touch on the former topic in a subsequent post, as that appeals to a more niche audience than the latter.

Why do open source?

All OSS contributors start off like any other typical software developer… So let’s start there.

You work in an office and you’re initially really satisfied with what you do. But engineering is as much a creative endeavor as it is a technical one… And your day job doesn’t really scratch your itch entirely.

You really have the languages, frameworks, tools, and design methodologies that you currently use down cold. At least you think you do. So, in your opinion, there’s not a lot of new or exciting stuff happening at your work place.

After enough time passes, you start to feel unsatisfied. Bored. Unfulfilled.

And thus, you choose one of following:

1. Switch jobs to someplace else and hope the environment is more stimulating; or
2. Become complacent (the “default” option) and stop being curious about software development; or
3. Take matters into your own hands and become responsible for your own happiness when it comes to software development.

Option 1 is the insanity option - repeating the same choices that lead you to where you are now and expecting a different result. Getting a job at Facebook, Google, Microsoft, Cloudera, or whatever might seem more stimulating than writing line of business apps for a bank but the honeymoon ends and the novelty wears off. Quickly.

Option 2 is the resignation option - the die is cast and you’re just going to have to get used to whatever your current environment is. You create a little prison cell for yourself based on the confines of your current environment, and at some point you may even begin to love the cell walls.

Let this go on long enough and you become that fat bearded bastard who incredulously defends using Visual Basic in production in 2015. That’s not a career worth celebrating or a life worth living if your resignation translates over to other areas of your life. As the saying goes, “the way you do anything is the way you do everything.”

Option 3 is the empowerment option - take responsibility for your own career and happiness by satisfying your curious and creative urges. This is the key to a happy career and life - don’t let your work environment be the sole determinant in your day-to-day programming experience and expression.

Contributing to open source is one of the most natural and common ways to take ownership of your self-expression as a developer and the fact that you get to share that experience with like-minded people, the other contributors and users, makes it even better.

Open source is a venue for discovery, self-expression, and most importantly: investing in yourself. It’s one of the most powerful choices you can make as a software developer. You’re not required to do anything - it’s entirely your choice. And that’s what makes you powerful when you do it.

And here’s the big irony - the “great” work environments that developers dream about where self-expression comes naturally… That comes about as a result of owning your self-expression and bringing the attitude with you to to work.

So how do you get started?

Getting started

Ok, so you’re ready to take ownership of your self-expression and blah blah. What are the literal, tactical steps for getting started?

Pick a project

The first step is to just find a project you want to work on.

Ideally it should be a project that’s already active, meaning that it has at least one other participant, gets updated frequently, and does releases regularly.

It really doesn’t matter what the project does or how big the project is - those are details that become more important when it’s time to make your first contribution.

The only criteria that really matters is this question:

Is this project something that I would want to use in my ideal day job?

If the answer is “yes” then you’ve found a great fit!

Become an end-user (if you aren’t already)

Before you can start making effective contributions, you should become an end-user of the project first.

Write a couple of small applications, maybe a blog post explaining how to use it, or whatever. You don’t need to become an expert on every nit-picking detail right away and you don’t need to do any production-grade deployments - but you need to get a feel for how the end-user is going to consume any of your contributions.

The whole point of contributing to this project is to be able to use it yourself, so have fun with it!

Start lurking the project (read-only participation)

Before you can contribute you need to get your bearings on the project. Here are some questions you can get the answers to just by reading and listening:

1. What are the goals of the project?
2. How’s the code organized?
3. Does the project have any standards? What are they?
4. Who are the key players responsible for X,Y, and Z?
5. Does the project have a published roadmap for future versions?
6. How do pull requests get submitted? What does the review process look like?
7. How do the contributors communicate? Google Groups? Gitter? Github issues? IRC?

The goal of read-only participation is to learn the rules of the road for the project. Learn how the code is structured and organized, but more importantly: start learning how the other people involved work together.

Once you’ve done this for a little while, you’ll have enough information to start actively contributing. This is where the real fun begins.

Working with other contributors

The hard part of any software project is working with other people, and open source is no different.

But learning how to do this well is a lot easier if you adopt the following ideas.

Assume good faith

When you’re interacting with other contributors, assume that everyone is acting in good faith by default.

If you make a contribution and a veteran contributor declines to accept your changes because they don’t meet some standard or don’t align with some other planned changes that are in progress already, don’t take it personally! Take the feedback at face value and see what you can learn from it.

Assume there’s a good reason for previous designs

Don’t come into a project and start refactoring everything without communicating with other contributors first - there’s often a history to the design that you may not be privy to right away.

It’s exhausting for project owners to regularly battle with new contributors who insist on imposing biases from previous and usually inapplicable experiences onto the project. Don’t be that guy - be the person who seeks to understand why things are the way they are.

Assume there’s a history to these changes and find out what it is - who knows? It might be sloppy code from early on in the project before clear standards were established, and you should refactor it. Or it may turn out that there’s a previously unfamiliar programming principle at work or a weird environmental bug that contributors had to work around.

You will be treated with a great deal of respect if you ask thoughtful questions, even if the contributors have had to answer them dozens of times before.

Be coachable

The single most important thing you can do as a potential new OSS contributor is to become coachable. You’re doing OSS for the sake of learning and becoming a more powerful developer and thus you must be open to suggestions from others in order to do this effectively.

Learn to acknowledge shortcomings with your own code without assigning any moral weight or attachment to them.

Accept that the tools and concepts that you know today aren’t the best solution for all problems.

Explore ideas without making instant “right” or “wrong”, “should” or “shouldn’t,” and “better” or “worse” judgments.

Actually listen to other contributors - don’t just search for a reason to make yourself right or them wrong.

And review the Taxonomy of Terrible Programmers - avoid any behavior on that list.

Don’t be afraid of being “wrong”

I’m an experienced OSS leader and contributor and I screw up all the time. Software is a process, not a product - and part of that process involves discovering bugs and design flaws, including your own!

Don’t be afraid of making a mistake - whether it’s in your code, your speech, or whatever. You’re going to become a much more powerful contributor if you don’t assign moral “right” or “wrong” weight to everything.

If you make a mistake, it’s not a big deal. Apply that standard to everybody else too.

Follow the rules

If the project has standards and guidelines… Follow them. They’re usually pretty small and not very complicated. If you don’t understand why a rule exists or what it means, just ask.

Be a part of the conversation

Stay in touch with the other contributors on the mailing list, Gitter, IRC, Twitter, or whatever. We’re all just people! Just relax and be yourself - ask questions, tell stories, make jokes, post animated gifs, or whatever.

Act like a person, get treated like one.

Dealing with jerks

A lot of developers are shy, introverted types - so the prospect of dealing with some belligerent asshole developer (The Agitator from the Taxonomy of Terrible Programmers) on a public forum can be pretty intimidating.

Here’s a simple set of guidelines for dealing with jerks.

If the project is run by jerks, then it’s a toxic project. Don’t get involved.

Nothing sucks the fun out of open source like stepping on eggshells around the core contributors; I recommend just avoiding projects like these.

OSS contributors who run successful projects and act like jerks are victims of their own success in a way - deeply insecure about their own code, which a lot of people now use thus putting them under even more pressure, so they overcompensate by trying to dominate and belittle others.

Just avoid these projects - no one has time for other people’s drama.

“Jerks” usually aren’t jerks 1 (cultural differences)

One of the things that will come up often in successful OSS projects is cultural differences. Americans and Germans are extremely direct when we communicate, so we can come across as giant assholes to people in other cultures when we’re expressing ourselves the way we normally would.

Develop an awareness of how different cultures communicate and how you communicate with them. Many of the contributors on Akka.NET are Swedish, and they have a much more communal / softer tone when they communicate. Americans like me are hyper individualistic and direct.

Without being aware of the differences in how we communicate with each other, this could be a source of drama. So give people the benefit of the doubt; it might just be a cultural thing after all.

But take the time to account for those cultural differences in your own communication too, and if necessary - learn what those cultural differences are in their communication and educate them on yours. It’s information that stands to benefit all parties.

“Jerks” usually aren’t jerks 2 (perspectives)

In addition to the cultural differences, you should try to gauge the perspectives of other contributors who might be acting a little “jerky.”

What if the contributor who’s being a “jerk” is also responsible for a massive production deployment of this OSS project at his or her company and is being criticized heavily at work for how it’s performing. Do you think that’s going to have an impact on their tone with other contributors on the project? Of course it will.

Again, operate on the assumption of good faith - try to figure out what’s really going on with that contributor one on one. I guarantee you’ll get better results from these contributors if they feel like they’re understood - a little empathy goes a long way.

Actual jerks

They do exist, but they’re exceedingly rare in my experience. Actual jerks are deeply insecure and take it out on other people by trying to make themselves right / others wrong.

Don’t be afraid of them - pity them. They’re more afraid of you than you are of them.

If an actual jerk comes after you, the best practice is to not engage. Just dismiss them.

If the harassment gets really bad or happens in private, make sure you let other contributors know. You shouldn’t have to put up with assholes - so don’t allow it.

Actively contributing

If you nail all of the above, actually contributing is as easy as just asking more experienced contributors “what can I do to help?”

Every OSS project needs help! It might be in the form of more documentation, fixing bugs, upgrading the build system, or building a new feature.

When it comes to open source the technology is easy - the people part less so.

So master and practice the above - enjoy the new things you’ll learn from the project and the other contributors. And bring those new attitudes to your work. You’ll be immensely more powerful and more satisfied with your career for it.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..

Tweet Follow @Aaronontheweb