How can I find a good open source project to join? [closed]

My first open source contribution was for a library that I had previously used (and would've suffered greatly without) on a previous paid project. During my initial use I had spotted a bug in the code so I created a patch, joined the project, and submitted it for review.

About 8 months later when I had some free time I decided that I would give back (and work on my development skills) by contributing more to the project. So I cloned the repository and started getting familiar with the codebase. After a few weeks of submitting minor patch fixes to the codebase and monitoring the feature requests, I picked up a feature request to add a pretty substantial module to the project.

Since generating many individual patch fixes is pretty tedious for any significant development I cloned the repository to a branch on git hub and started punching away code. A few weeks and several thousand lines of code later the project leader and me worked through integrating and testing my fixes into the library in a way that worked consistently with the rest of the codebase.

It was an invaluable process that I learned a lot from:

• When I started I didn't know how to use Git, by the end I could proficiently create remote tracking branches and merge or rebase them into the master branch without breaking a sweat.
• I started in VS 2008 and ended up migrating to Linux and Monodevelop to work on writing code (because VS is unicode retarded and line endings are such a pain in git). It turns out that theres not much you can't do in *nix that you can do in *dows.
• I had never really done any unit testing before, Nunit is a piece of cake to use and writing unit tests is pretty elementary stuff.
• I had to learn to swallow my tongue and listen as well as practice patience. There's no point in standing a firm ground on your position on an open source project because everybody involved is knowledgeable (probably more so than yourself) and capable of accepting/rejecting your ideas based on substance not delivery. It's extremely humbling and rewarding at the same time.
• Just having one other skilled developer's eyes on a large base of my code pointed out flaws in my style that I had never considered before (as well as I pointed out flaws in his code). For me, I learned that it's easier/better to define constants than it is to use a bunch of magical numbers with detailed commenting.

That particular project was based around generating and decoding networking packets on all levels of networking protocols. I have a personal interest in lower level networking so it was great to have discussions with another developer with shared interest and knowledge in the domain.

If you want to just get your feet wet: find a project that you already use; clone the repository; and start seeing if you can fix some bugs and/or add some unit tests. It seems intimidating to look at someone else's codebase with fresh eyes but it's an extremely valuable skill to learn. Submit some patches. You can expect your code to be closely scrutinized at first. Don't worry about it, it's a normal part of the process to gain the trust of the project admin(s).

After establishing a base of merit with the projects admin(s) start seeking more responsibilities such as, proposing new features, or asking to be assigned to implementing feature requests.

If you can't find an already existing project on one of the main open source repository networks (github, sourceforge, google code) think of an app that you'd really like to use that doesn't exist yet and start your own.

Be prepared to be humbled and expect work to be rejected in favor of further revisions. The myth that anybody can add code to an open source project is completely false. There's always a gatekeeper between you and push access. The better your code, the less it will be scrutinized in the long run as you gain trust of the project admin(s). If it's your project, you'll be that gatekeeper.

Update:

I just thought about it and realized that I didn't bother to mention which project that a lot of my answer is referencing. For those who want to know, it's SharpPcap. The lead developer Chris Morgan is very professional and on point. He does a hell of a job managing the project and taught me a lot about what it takes to mature a OSS project.

Due to personal time constraints I haven't been able to contribute code in over a year but I still try to give back by lurking on Stack Overflow and answering questions about SharpPcap occasionally.

Here what I suggest to do in order to find your perfect match:

1. If you have an open-source project that you already use, know and care about, it should be your first candidate to try. Otherwise think about what you would like to do in general and search for a project in this area.

2. When you have found a potential project, do not rush into it. Try to use it yourself. Is it as good in action as it seemed from description and reviews? If not it isn't a complete show-stopper; maybe it is an opportunity for you to jump in and really make a difference. After all nobody needs another developer for a perfect product. But it will give you a important insight whether you want to be part of this project, while you gain first hand experience with new technology in an area you are interested in.

3. Also before starting to invest too much time in the project and learning its ins and outs, consider hanging around in the project mailing lists, forums, even bug tracking system for a couple of weeks. If you will start contributing to the project on the regular basis you will spend a lot of time there.

Figure out: do you enjoy hanging around there, or is it a drag for you? Does it feels like this project has a good and energetic community or is it slowly dying? Do core people there seem to encourage and mentor newcomers or you will be on your own?

Do these steps for several projects, potentially in different areas and you are less likely to experience disappointment that comes when you join a wrong team. Such an experience can potentially discourage you from doing it again in the future.

A few more thoughts:

If the project you are really interested in is a high profile one with a lot of developers and activity around it, you probably will have a hard time establishing a sufficient reputation there to get, say, commit rights or an interesting role in the community. In this case consider joining a related spin-off project with lower visibility. For example instead of trying to start contributing to jQuery, try to find jQuery plugin that will be a good fit to you. Later you can consider "moving up".

If you like a project but feel intimidated by its size, complexity, or code quality requirements, consider starting from supporting roles, like testing, documentation maintenance, or bug report verification. If you ask in the project mailing list what kind of help they need most at the moment they will be more than happy to guide you there. :)

This way you will learn the project and build your reputation there while contributing way more to it than if you started to submit sub-standard patches that would be rejected multiple times until they were ready.

The last and the most important: if you get burned in one place, move on; don't give up.

Hope that helps.

I would strongly recommend that you find an open source project that has your sincere interest and that you actively use.

The reason is simple: It makes the difference between a chore and a hobby.

Have a look at your computer. What software have you put on it that is Open Source? A guess would be Chrome or Firefox, or perhaps Open Office or an Instant Messenger client. Are they perfect or is there just some tiny thing that you would like to change if you could?

If there is, then now is the time to do something about it.

I would suggest finding (or starting) a project just like people have been doing for years, start using Open Source software to do things. That may seem trivial to you, even perhaps over simplified. Yet, it is really hard to describe the satisfaction of using something, finding a bug, grabbing the source and fixing it. Or, perhaps changing it so it works the way you want it to work.

Also, don't just hack for the sake of getting 'involved'. 95% of my patches to the Linux kernel will never see the light of day, I know for sure that nobody would want them but me, and I'd probably be forced to undergo psychiatric evaluation if any other competent kernel hacker ever saw them. But I still enjoy my implementation of piglatin_printk() which started as an April 1 gag several years ago :)

While yes, getting your code and your thought process in front of many other competent people is priceless, so is learning how to communicate and collaborate. A solo project is a great way to show you what not to do. Hint, there's more to it than just using version control software, mailing lists and a bug tracker.

To get started, I suggest digging around Ohloh to find software that you might be interested in using, first. Download it, build it, play with it. Then go grab something else. Eventually you'll come to wanting to improve something, or realize that you have the urge to implement something completely differently than what you found.

The other thing that helps is working for an open friendly company. My company uses Xen extensively, so they have no problem with me finding interesting bugs and fixing them, since we'd need to do that anyway. They also don't mind employees participating in things like RFC's and draft specifications, since we'll ultimately be using the result.

OpenHatch was created specifically for this.

To quote:

OpenHatch is a non-profit dedicated to matching prospective free software contributors with communities, tools, and education.

You can browse projects by type, technology, skill level required etc. and find what matches your level.

One thing that I've repeatedly noticed when it comes to people looking to get started with open source development is that they get overwhelmed at the sheer complexity and magnitude of big projects. I faced the same problem a couple of years ago, and from my experience, its best not to look at the bigger projects right away.

After spending sometime looking at projects that I might like, I realized that they were still out of my reach and then started to work on very small projects on my own. I make it a point to just release the code on Github, irrespective of whether its really relevant or whether other people will start using it. Eventually, people might start taking interest in what you do. Even otherwise, you will gain confidence and technical ability to slowly move to bigger and more popular projects.

There is a new website out there specifically for this called Code 52 that encourages new developers to get involved in open source by starting a new OSS project every week.

The idea is that it will seem a lot less daunting for people who have never been involved in open source before and hopefully will feel more inclined to get involved in other OSS projects as well.

I recommend reading : http://open-advice.org/.

It aims at helping those who create and maintain communities, and those who are not confident about which one they want to join or how to do so.

Failing that, find a project which has a mission that resonates with you, or fork and contribute to one that is already useful to you.

Good luck.

When I started, I searched online for options and it proved challenging to find something you can sink your teeth in as a beginner.

Some projects are difficult to contribute to not because they are too advanced but because the community is not welcoming. So, don't be discouraged when you hit a wall.

During the search, I decided to put together a list of 10 open source projects that beginners can start supporting without much stressful processes. Here is the link to use:

Ten Projects for beginners to support and learn from

I hope you find it helpful and you can always add more if you find cool ones!

I suggest to start a project on your own on a topic that you're interested in.

A lot can be learned by working on a project in general. It is not needed to see how someone else codes to learn how to code better. And sometimes you'll actually see what not to do as the other people are often no more experienced than you are.

It usually helps to see other's code, but you will encounter other people's code in your own project just via the libraries and components you use.

Experience will teach you what is good and bad practice.

I am a project owner on google code, and I am looking for contributors. (Yet I will not misuse this answer for advertising.) Hence my opinion might be interesting for you.

You'll first have to find out what you're interested in. Then develop some expertise in some fields that are related to your interests. Then find a project where your expertise is demanded and needed.

The smaller the project, the less contributors are already there, the greater the chances that contributors are sought and you can contact the authors/project owners directly. Tell them a) what your expertise is b) where you see it could be applied in the project c) what you think you can achieve.

Remember: just knowing one or two mainstream programming languages is not expertise.