131
107
|
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.
| ||||
|
88
|
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:
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.
| ||||||||||||||||||||
|
22
|
Here what I suggest to do in order to find your perfect match:
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.
| ||||
|
7
|
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.
| ||||||||
|
6
|
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.
|