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?
migrated from stackoverflow.com Jan 22 '11 at 17:56
This question came from our site for professional and enthusiast programmers.
closed as too broad by gnat, Corbin March, MichaelT, mattnz, GlenH7 Aug 23 at 3:11
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
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.
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).
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.
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.
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.
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.
http://openhatch.org/ is a site dedicated to getting ppl into open source development, have a look.
I wouldn't say that was essential when your starting out. As long as you basically understand source control ...
There are multiple mechanisms to contribute:
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.