Tips When Applying to an Open Source Project

July 17, 2012 Gian Computer Science, 0

Over the years, I’ve had a host of hopeful applicants ask to be a part of an open source project that I managed. By far, the majority of people who have applied to a project would have benefited from taking the time to do a few things before they applied. This brief blog post is just a short list of tips I have for open source developer hopefuls that should go a long way toward helping you land your dream open source development project position.

1. Treat it like applying to a job.
   I’ve had many people wanting positions of development on a project that weren’t within their current skill set. Many times, this is OK as we can handle the “spin up” time it takes for someone to get current with the source code they going to be working on. The problem is when the person treats the application process too lightly, and doesn’t give it the importance (in their schedule, their dedication, whatever) that it is due. So, look at application to an open source project like an application to a “real” job. The following points tie into this concept.
2. Do your research.
   Before applying to an open source project team or position, do some homework. Unless the project is just forming, there are probably a corpus of literature and documentation or source code that is already available. Take some of your time to look through this source code, their Wiki documentation, their ticket and issue management sites to see how far they’ve come, what their design philosophies are and whether they closely align to yours, and so on. This is just basic due diligence  to show that you are a sincere interest in the project and that you have already devoted some of your personal time to read and learn what they’ve already accomplished and where they’re planning to go (and how they are planning to get there).
3. Be articulate.
   This means being able to accurately and succinctly say what you are wanting out of the position, what skills and abilities you can bring to the group, and how you are planning to help the project succeed. Take the time to craft a well worded introduction of yourself, your experience and knowledge, and why you think having a position in the open source project would be a good benefit all the way around.
4. Familiarize yourself with the technology.
   Open source projects in-progress have already made a conscious decisions on what technology they are using, or planning to use, to reach their milestones and goals. Maybe they’re using the gcc toolset with Eclipse on Linux, or maybe the default environment is Visual Studio C# on a Windows platform with .Net technology. Take the time to discover what technologies you will be using and whether this will be able to hold your interest and be something you can work with.
5. Learn to make and use patches.
   Patches are small (although some are largish) changes to a codebase to fix a problem or augment the code. Patches can be created with your new code against the code in the repository and you would submit your patch and a developer might look it over then apply it to the source repository without you having to commit your working directory. This becomes very important when open source projects have standardized on giving new developers only patch capabilities when first starting out and only later allowing full working directory commits to the source repository.
6. Have an idea of what you’d like to do.
   This can’t be overstated enough and goes hand in hand with researching the projects existing body of work. I can’t count the number of applications I’ve received where the person says they want to work on the project but has no idea of what area of the project they could contribute to. My best advice on this is to go with what you love. If you like network coding, research their network code, if they have it, and see how they’re doing it and how you could help the project achieve their goal in this area. If you don’t know what you want to do for the project, its a fair bet that the project manager will not know where to place you in the project.
7. Decide whether NDAs, CLAs, etc are OK.
   Some open source projects may require Non-Disclosure Agreements to protect the projects information getting out before it’s been fully tested and ready for release. This means that people could be getting code that is not meant for public consumption and if used could reflect negatively on the project (since it’s not designed for public use yet). Code License Agreements are becoming more common and simply ensure that the open source project has the right to use the code you develop now and perpetually. It doesn’t take away the developer’s copyright in any way whatsoever, but ensures that the developer, maybe a few years down the road, doesn’t decide he doesn’t want the open source project to use his code anymore. It takes no rights away from the copyright owner at all. If a project has any of these in place, you need to make up your mind about whether these are OK for you before moving forward. If you are adamantly against them for whatever reason, just write the program manager or development team and tell them that you don’t think it would be a good fit.
8. Join the relevant websites, groups, etc.
   Many open source projects have discussion groups, mailing lists, forums, and wikis where information is freely shared between developers and between developers and users. If this open source project has any of these types of websites and groups, be proactive and create an account on them so that you can begin participation immediately. It reflects positively that you take your application to the project seriously.

And that’s all I’ve got, but follow these simple eight rules and it will take you much closer to picking up that open source project position that you are excited about and want to contribute to.

Cheers!
Gian

foss, open source, project management

Government Sanctioned Gets Binary Protocol and OOB Signaling Classless Advancements Coming to Government Sanctioned