How do I contribute to open source projects?

Question

What are the mechanics of contributing to open source projects? How are they managed? What exactly is meant by submitting a patch? Should I do some reading up on advanced version control techniques?

Answer 1

First step is Version Control, I recommend git in conjunction with github. The whole process has been made very painless there, and you can get started fairly quickly.

basic process at github

1. install and learn git basics

2. "fork" a project you want to contribute to

3. clone it to your local machine, edit, and commit changes

4. then submit a pull request to orignal author, and at that point they decide if they want to include your code in their project.

Note on contribution:

Contribution(like invention) is most commonly born out of necessity. You need a piece of OSS to do something it does not currently do, so you build in (invent) the functionality you require for your given project, it is then that you turn around and say, there is probably more people out there that would benefit from this, so you then turn around and share your progress.

I would say find something that interests you, but more importantly find something that you commonly use (and are familiar with) that you can envision yourself extending. This advice covers the fact that you are interested in it.

Answer 2

What can you bring to the table?

Asking, "how do I contribute" is like asking a capitalist how to get rich. There's no one good answer but there are a lot of steps you can take to start moving in the right direction. Let me see if I can help.

What are the mechanics of contributing to open source projects?

It depends on what you're contributing. It's important to make this distinction because contributions can come in many forms and contributing code may not the best entry point to join a project.

If you want to contribute code and the project uses git for version control, then you'll need to have a strong understanding of how to share/collaborate code using patches or via remote tracking branches (ie a 'fork' for the GitHub fans).

How are they managed?

There is always a dictator, either the original author or a project maintainer. How much power/control they grant to project contributors/developers is usually based on trust. Contrary to popular belief, write access to a project's public repository is usually granted to only a select few.

Typically, the project will have a roadmap planning the future direction. If a project has a good community following then creating the roadmap can be as simple as cherry-picking suggestions from user-submitted feature requests.

There almost always is some form of central feature/issue/bug tracking. It's usually the primary communication medium between the project team and the greater community. Most/all external feedback goes through this system because it provides a means for prioritizing and filtering the suggestions based on quality.

What exactly is meant by submitting a patch?

A patch is a diff between two commits in a repository.

AFAIK, every VCS platform has a way to create patches. In git you use the "git format-patch". If you're contributing multiple disparate changes, it's usually good to break the changes down into multiple patches so they can be accepted/rejected individually.

The other way to contribute code is via a remote tracking branch. Basically, you fork (ie clone) the main repo so you can gain write access to it, make it available publicly, and notify the project team that you have code that can be pulled from it for review. GitHub automates most of this process when you fork a project but the workflow is common among DVCS platforms.

If you want to contribute code, this is your first major barrier of entry. If you don't have a good understanding of version control software then you have a lot of reading to do.

Should I do some reading up on advanced version control techniques?

If you want to contribute code then yes. Don't expect the project developers to go out of their way to help you learn to use version control software, especially if you haven't contributed anything of value to a project yet.

You'll want to know how to clone, commit, create patches, how to work with branches, how to merge and/or rebase, how to push/pull, how to use remote branches, the difference between a hard/soft reset, cherry-picking commits, conflict resolution, and good practices for creating and documenting code commits.

**Note: GitHub makes it ridiculously easy to fork a project's public repo.I'd still recommend that you learn how to do things the non-GitHub way.

---

Intimidated yet? Don't worry...

I answered the questions you asked but not the one you should really be asking yourself.

What valuable skills do I have to offer to the project?

Open Source projects don't run on altruism any more than imagination is fueled by unicorns that fart rainbows. The software is free of cost and free for all to use but that doesn't make the time of the project developers worthless.

If your contribution isn't of a sufficient quality, then it may require further revision or be rejected outright. Even if your code works and is high quality, it could be rejected because it doesn't meet the long-term goals set out by the project maintainers.

A lot of people make the mistake of assuming that because they put a lot of effort into a contribution that it's intrinsically valuable to the project. The harsh truth is, contributions that don't meet a specific need are worthless.

If you really want to become a regular contributor to a project I personally suggest that you don't start by submitting code. Offer other forms of value, whether that be feedback, testing, supporting users, updating documentation, etc. Not only will it help you familiarize yourself with the project and it's goals but it'll start building a good standing with the team.

The hidden cost of OSS development is time. It costs time to produce anything of value and it takes time away from others when you don't. The hidden benefit is that OSS development is often carried out by very highly skilled developers, it teaches you how to effectively manage/coordinate a software development project, and it will most likely lead you to become a better programmer.

Merit is the currency of Open Source. When you're starting out you have none. Don't expect people to go out of their way to help get you up to speed. If you read nothing else in my answer just remember the following three points: contributions don't always come in the form of code; approach a project with a realistic idea of what you have to offer; and do your best to earn merit before you ask for help (you'll be shocked at how much better you will be received if you do).

Aside: It seems counter-intuitive to think that you need to earn the privilege to give your time/effort for free. The economy of merit feels strange and unnatural in a capitalist society but it holds a much deeper intrinsic value. Chances are, whatever time you put in starting off will pale in comparison to the work the project developers have put in. Invest time before demanding it from others and you'll find that the OSS project team will be much more open/receptive to your work/ideas.

Answer 3

There is no single answer to this question. There are many different models of FOSS development with many different procedures.

One flavor is the Apache Software Foundation; our web site has quite of a lot of process documentation. But we're only one flavor.

Answer 4

there are two simple answers. (a) If your contribution is a simple bug fix, just send it in to whomever you can identify as a principal in the project. If you are looking to join the team, start with (a) but expect to be challenged to prove your seriousness. Huge amounts of time are wasted on volunteers who vanish.

Answer 5

http://openhatch.org/ is a site dedicated to getting ppl into open source development, have a look.

Should I do some reading up on advanced version control techniques?

I wouldn't say that was essential when your starting out. As long as you basically understand source control ...

Answer 6

There are multiple mechanisms to contribute:

• Paypal
  But only do so if the project advertises specific uses for donations. Or pay someone to write a feature for you.
• Subversion
  Join the mailing list, contribute working "patches" against the development version. Patches mean modifications that you run through diff -u to get it in a readable comparison format.
• Forum
  It's often sufficient to help out managing user support, or to contribute documentation. Contributing ideas is often only asked for by small projects.

Answer 7

My advice to you is quite simple. If you want to contribute to a project you just have to find one that suits you in GitHub, CodePlex or any other site, read all the documentation they have about the subject (normally you'll find a "get evolved" link) and go from there following all the recommendations that the project's current contributors ask.

You can do code and submit patches, you can donate, you can test and report bugs... etc, etc, etc. Just try to find what the project you've choose needs the most and what's inside your capabilities to do.