Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I just started working a year ago, and I want to join an open source project for the same reasons as anyone else: help create something useful and develop my skills further.

My problem is, I don't know how to find a project where I'll fit in.

How can I find a beginner-friendly project? What attributes should I be searching for? What are warning signs that a project might not be the right fit? Are there any tools out there to help match people with open source projects?

There's a similar question here, but that question has to do with employment and is limited to PHP/Drupal.

share|improve this question

closed as primarily opinion-based by MichaelT, GlenH7, gnat, Bart van Ingen Schenau, Dan Pichelman Nov 5 '13 at 19:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

9  
Cool, I just took a look at ArsTechnica and saw this question featured as an article. Here's the link. arstechnica.com/business/guides/2012/03/… –  Evan Plaice Apr 1 '12 at 9:16

11 Answers 11

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.

share|improve this answer
35  
+1 to "find a project that you already use" –  Pavel Shved Mar 14 '11 at 5:57
    
can you suggest some popular site in this regard? –  Aditya P Mar 14 '11 at 6:08
2  
@AdityaGameProgrammer I'd place more emphasis on looking for a specific project not open source hosting site. Hosting sites are just a dumping ground for open source projects and some projects will migrate to different sites if better features can be found (Ie specific licenses supported, better version control support, better bug trackers, etc...). I've already named a few. IMHO, github, google code, and sourceforge are the most popular. Launchpad (uses bazaar version control) is where you'll find most Ububtu/linux development taking place. –  Evan Plaice Mar 14 '11 at 21:55
2  
@AdityaGameProgrammer (cont) Github, sourceforge, and google code are all seething masses of projects. Because sourceforge has been around longer you'll probably find a lot more dead/orphaned projects. It's a lot easier to find a project to join if you take some time to consider what you're interested in first. The exception is, if you're looking to host your own project. Then, take some time to shop around for the features that best fit your usual development workflow. –  Evan Plaice Mar 14 '11 at 22:03
    
Thanks .My earlier attempts at finding one on sourceforge lead me to a vast number of dead/orphaned projects. –  Aditya P Mar 15 '11 at 4:36

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.

share|improve this answer
1  
+1 for "consider starting from supporting roles." Writing tests is really easy and a close look at the tests gives a good idea about what the code is trying to accomplish. Documentation is a good way to gain an understanding of the 'bigger picture', and verifying bugs is a good low-barrier point of entry to break the ice. Working on the stuff that developers typically neglect demonstrates that your focus is to improve the project and your contributions aren't just ego-driven. Ego issues can make life difficult for project maintainers so they watch out for that sort of thing. –  Evan Plaice Mar 20 '12 at 20:08

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.

share|improve this answer

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.

share|improve this answer
    
+1 piglatin_printk()? Sounds hilarious. I'd like to see that in action. It's no surprise that most of your Linux Kernel patches have been rejected, there's not much room for fun/creativity in a project that critical. Fortunately, there are a lot of smaller projects that have a much lower barrier of entry to accepting code - even if the contributions need some work before being committed. –  Evan Plaice Nov 14 '12 at 3:06
    
@EvanPlaice They weren't rejected, just never submitted ;) –  Tim Post Nov 14 '12 at 8:41

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.

share|improve this answer

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.

share|improve this answer
1  
I've been looking into it and have a few notes to add. Code52 is headed by 3 developers from the company Readify who claims to have won the title 'Microsoft's 2012 Partner of the Year'. Although the projects are hosted on GitHub every one of the projects is written in WinJS (ie target Win8) and carry the Microsoft Public License. From a cursory look MPL is copy-left but carries certain restrictions requiring derivatives to inherit the same or similar license. Ie it's more like GPL license than the much less restrictive MIT license. –  Evan Plaice Nov 14 '12 at 4:38
    
The project looks very appealing but I can't shake the feeling that this is the newly founded Open Source Developer Digital Sharecropping program created by Microsoft to populate the new Windows 8 ecosystem without spending a dime. Not to sound like a tinfoil hat wearing neck bearder but MS doesn't exactly have the best reputation when it comes to integrating with Open Source. –  Evan Plaice Nov 14 '12 at 6:16
    
-1 Looks this site basically died (no more updates) over a year ago –  Michael Durrant Nov 4 '13 at 20:20

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.

share|improve this answer

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!

share|improve this answer
    
would you mind explaining more on what it does and why do you recommend it as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange –  gnat Aug 28 '13 at 4:33

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.

share|improve this answer
    
Great little site :) One could also check out freecode.com –  nha Jun 11 at 12:15

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.

share|improve this answer
1  
While I think this is a great idea, doing it as a beginner project can be intimidating. Especially when you don't have code reviews or other people that can add input. My own projects have gone through many rewrites and thousands of lines of code because nobody told me X was better, a problem I still have. Joining an established project will accelerate learning much better –  TheLQ Sep 2 '10 at 2:42
    
@TheLQ: It depends on your experience level I guess, doing something from scratch yourself will teach you a lot of lessons and things you wouldn't learn by joining a team which already has many things done. There's goods and bads about your own or someone else's project in my opinion. –  Brian R. Bondy Sep 2 '10 at 11:41
    
@TheLQ I completely agree. It's a very valuable experience to join an already existing project because it gives you an idea of how open source projects are managed and how the organization is structured. After working on someone else's successful project, making the leap to creating one of my own was a walk in the park. –  Evan Plaice Sep 12 '10 at 10:33

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.

share|improve this answer
    
How would you advise someone to go about determining what they're interested in or building up expertise in those areas? –  Anna Lear Mar 14 '12 at 16:16
1  
@Anna I am not sure I understand your question. I mean there are hundreds of topics - from low level stuff like network protocols or inner workings of a GPU to highly abstract, nearly mathematical topics (parsing, type systems, category theory, etc.). The greatest genius will not master them all and will be happy to have someone that is an expert in a field where he, the genius, is not. But what your interests really are, who can tell that but you? –  Ingo Mar 14 '12 at 16:28
1  
Yeah, discovering the interests is perhaps fairly personal (or the advice amounts to "try different things and see what you like"), but what about gaining expertise? You say it's more than just knowing a couple languages. So, given a new topic/subject matter, what would you do to gain that expertise? To me, joining an OSS project would be a part of that process, but if I'm reading you right you're suggesting that one should be an expert before joining a project. –  Anna Lear Mar 14 '12 at 16:34
    
What would I do? Read books. Read PDFs. Discuss with someone you know, or in the net. Try something out. Practice. Answer all questions on SO that come up regarding that topic. Then one day notice that few know better than you. -- Don't take me too literally regarding the "expert", but remember, in open source projects, as it is voluntary, there is no way to force someone to do work - hence people who know what they are doing and who want to do just that are most welcome. –  Ingo Mar 14 '12 at 17:52

protected by MichaelT Nov 4 '13 at 19:33

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.