How To Work With Open Source Projects

Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.

Why do people contribute to open source? Plenty of reasons!

Improve software you rely on

Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that’s the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.

Improve existing skills

Whether it’s coding, user interface design, graphic design, writing, or organizing, if you’re looking for practice, there’s a task for you on an open source project.

Meet people who are interested in similar things

Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it’s running into each other at conferences or late night online chats about burritos.

Find mentors and teach others

Working with others on a shared project means you’ll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.

Build public artifacts that help you grow a reputation (and a career)

By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.

Learn people skills

Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.

It’s empowering to be able to make changes, even small ones

You don’t have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.

What it means to contribute

If you’re a new open source contributor, the process can be intimidating. How do you find the right project? What if you don’t know how to code? What if something goes wrong?

Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.

You don’t have to contribute code

A common misconception about contributing to open source is that you need to contribute code. In fact, it’s often the other parts of a project that are most neglected or overlooked. You’ll do the project a huge favor by offering to pitch in with these types of contributions!

avatarI’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.

— @orta, “Moving to OSS by default”

Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.

avatarI first reached out to the Python development team (aka python-dev) when I emailed the mailing list on June 17, 2002 about accepting my patch. I quickly caught the open source bug, and decided to start curating email digests for the group. They gave me a great excuse to ask for clarifications about a topic, but more critically I was able to notice when someone pointed out something that needed fixing.

— @brettcannon, “Maintainer Stories”

Do you like planning events?

  • Organize workshops or meetups about the project, like @fzamperin did for NodeSchool
  • Organize the project’s conference (if they have one)
  • Help community members find the right conferences and submit proposals for speaking

Do you like to design?

  • Restructure layouts to improve the project’s usability
  • Conduct user research to reorganize and refine the project’s navigation or menus, like Drupal suggests
  • Put together a style guide to help the project have a consistent visual design
  • Create art for t-shirts or a new logo, like hapi.js’s contributors did

Do you like to write?

  • Write and improve the project’s documentation
  • Curate a folder of examples showing how the project is used
  • Start a newsletter for the project, or curate highlights from the mailing list
  • Write tutorials for the project, like PyPA’s contributors did
  • Write a translation for the project’s documentation

avatarSeriously, [documentation] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.

— @kittens, “Call for contributors”

Do you like organizing?

  • Link to duplicate issues, and suggest new issue labels, to keep things organized
  • Go through open issues and suggest closing old ones, like @nzakas did for ESLint
  • Ask clarifying questions on recently opened issues to move the discussion forward

Do you like to code?

  • Find an open issue to tackle, like @dianjin did for Leaflet
  • Ask if you can help write a new feature
  • Automate project setup
  • Improve tooling and testing

Do you like helping people?

  • Answer questions about the project on e.g., Stack Overflow (like this Postgres example) or Reddit
  • Answer questions for people on open issues
  • Help moderate the discussion boards or conversation channels

Do you like helping others code?

You don’t just have to work on software projects!

While “open source” often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.

For example:

Even if you’re a software developer, working on a documentation project can help you get started in open source. It’s often less intimidating to work on projects that don’t involve code, and the process of collaboration will build your confidence and experience.

Orienting yourself to a new project

avatarIf you go to an issue tracker and things seem confusing, it’s not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.

— @shaunagm, “How to Contribute to Open Source”

For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they’ll probably look at you a little strangely.

Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.

Anatomy of an open source project

Every open source community is different.

Spending years on one open source project means you’ve gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.

That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.

A typical open source project has the following types of people:

  • Author: The person/s or organization that created the project
  • Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
  • Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
  • Contributors: Everyone who has contributed something back to the project
  • Community Members: People who use the project. They might be active in conversations or express their opinion on the project’s direction

Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information.

A project also has documentation. These files are usually listed in the top level of a repository.

  • LICENSE: By definition, every open source project must have an open source license. If the project does not have a license, it is not open source.
  • README: The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
  • CONTRIBUTING: Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
  • CODE_OF_CONDUCT: The code of conduct sets ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
  • Other documentation: There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.

Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.

  • Issue tracker: Where people discuss issues related to the project.
  • Pull requests: Where people discuss and review changes that are in progress.
  • Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, “How do I…“ or “What do you think about…“ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
  • Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.

Orienting yourself to a new project

avatarIf you go to an issue tracker and things seem confusing, it’s not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.

— @shaunagm, “How to Contribute to Open Source”

For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they’ll probably look at you a little strangely.

Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.

Anatomy of an open source project

Every open source community is different.

Spending years on one open source project means you’ve gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.

That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.

A typical open source project has the following types of people:

  • Author: The person/s or organization that created the project
  • Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
  • Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
  • Contributors: Everyone who has contributed something back to the project
  • Community Members: People who use the project. They might be active in conversations or express their opinion on the project’s direction

Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information.

A project also has documentation. These files are usually listed in the top level of a repository.

  • LICENSE: By definition, every open source project must have an open source license. If the project does not have a license, it is not open source.
  • README: The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
  • CONTRIBUTING: Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
  • CODE_OF_CONDUCT: The code of conduct sets ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
  • Other documentation: There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.

Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.

  • Issue tracker: Where people discuss issues related to the project.
  • Pull requests: Where people discuss and review changes that are in progress.
  • Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, “How do I…“ or “What do you think about…“ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
  • Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.

This will create a copy of the project on your local machine. Now that you have cloned the repo we will need to do two things:

First is to make the necessary changes/contribution and commit those changes. After making your changes and adding new files, its time to add those changes into a separate branch before pushing them to remote.

Similar Posts

0 Comments

No Comment.