The Palmetto Open Source Conference (POSSCON), currently happening in Columbia, SC, has a large number of students and people new to open source attending. Leslie Hawthorn of the OSU Open Source Lab gave them an introduction yesterday afternoon for how students can get started in open source.
Why open source?
According to Gartner (Feb. 2011), more than half of leading IT organizations are using open source software for its competitive advantage and lower costs. Thirty percent of software at these companies is open source, which is an increase from 10% only five years ago. Thus, employers value experience in open source when looking at potential hires. For an employer, it's one thing to interview someone and think it goes well. It's another to see a prospect's code, comments, and how they interact in a community.
For students, the benefits extend. Not only do you have a body of work to show when you're looking for a job, but you get the opportunity to nurture your passion for porgramming and to make a difference. How? With the projects that are really changing the world. Leslie offered a few examples:
- The projects that help those in need, like Sahana, OpenMRS, Ushahidi
- Those that focus on social justice causes, like Sunlight Foundation, Tor, Martus
- Those that support the missions of non-profits, like CiviCRM, HFOSS Project
Getting involved
The "traditional" way to get started in open source is something akin to trial by fire. But it doesn't have to be that way.
Conferences and unconferences are an easy way to get started. You'll not only get contacts and potential opportunities, but you'll also see the energy and passion behind open source. Unconferences in particular, where the agenda isn't determined until the day of the event, have a low barrier to entry since you have the opportunity to help guide the topics.
Leslie previously worked on the Google Summer of Code. In 2005, Google was evaluating their new engineering hires and finding that while they were great at theory and design, they knew little about version control or the software toolchain in general. Larry Page aimed to solve that problem with Summer of Code to match students with open source projects that needed their talents. They get paid $5,000 to complete a project, or as Leslie put it, "flip bits, not burgers." This year, 175 projects are participating with as many as 1,000 students. Leslie encouraged "apply early, apply often" as a strategy, as many projects find their new participants early on in the process.
Now for 13-18-year-olds, there's also the Google Code-In contest. Projects submit bite-sized tasks that can be tackled by people who don't have an extensive background in code, as well as all the other sorts of tasks that don't require coding, like documentation and design. In the first year, almost 2,000 tasks were completed in only two months.
Several similar programs have since been spawned, from the GNOME Outreach Program for Women to the Ruby Summer of Code and the New Zealand Summer of Code (which happens during the southern hemisphere's summer, as opposed to Google's program).
And of course, the most profitable way to get involved is to get a job with an open source company. You'll get all of the same aforementioned experience and exposure with a career to boot. Many of them offer internships for those just starting out.
Diving right in made simple
What if none of those approaches work? If you're looking for a project to get started with, Leslie recommends looking for one that has participated in Google Summer of Code. By doing so, they've stated that they're interested in new contributors and people who may not be vastly experienced. Some projects also have a mission statement or diversity statement that explicitly say they're interested in new contributors.
The next thing you should do is look at the project to see how active it is. Has nobody participated in five years? Is the mailing list active, or was the last message from a spammer months ago?
Looking credible in a few easy steps
A lot of open source work is done on a volunteer basis. Even those who are getting paid often volunteer a lot of additional time. So it's important to respect those people's spare time by doing your homework and establishing some credibility up front.
Read through the project's website. Learn about its objectives. Join the mailing list and lurk in the project's IRC channel. Know what the project is about before you start asking basic questions that you could have easily found an answer to.
Leslie recommended Eric S. Raymond's "How to Ask Questions the Smart Way," which she summarized as, "Give as much data as you possibly can to the person you're asking the question of." Explain everything about your problem from your OS to what you've done to try to find the answer. That both demonstrates that you're respectful of the person's time (by explaining that you've tried to help yourself first), and it gives them the information they need to point you in the right direction.
You'll make mistakes. And that's OK, because everyone does. In the open source community, it's called rapid prototyping--fail early and fail often. Just don't make the same mistakes over and over again.
Related posts
1 Comment