19

I am heading into my senior year in computer engineering and have gotten a internship for this summer and fall. Since I will not be doing homework I would love to take this opportunity to get involved with an open source project of some sort. I am proficient with C, C++, Java, and Python. I am also reasonably familiar with Linux, using it on my laptop at the moment and all of my classes this semester focused on it.

I was considering taking a look at Android or Ubuntu but in the past I have felt a little overwhelmed. Does anyone have any advice? Interested on what would be a good project to work on, where to get started, and if I will really able to contribute much.

And in the end how often are peoples changes actually accepted? How often would I be writing code just to have it rejected?

tl:dr Looking for more programming experience by contributing to an open source project. New to the scene need advice.

Tarmon
  • 291
  • I'd say landing here is certainly worthwhile! – squillman Jan 23 '11 at 01:25
  • 6
    Sounds like a good idea, but do check the "moonlighting" rules at the company where you are doing your internship. Some places, especially if they are software shops, will be very restrictive on what you can do - even in your own time and on your own PC. – Steve Apr 28 '11 at 10:28
  • 1
    perhaps consider learning a new programming language that is more declarative then the ones you mention. Like haskell or scala. Then work on an open source project. – mrsteve Sep 27 '11 at 00:43

6 Answers6

15

+1 to Steve Haigh for mentioning moonlighting.

If you work for a software shop, you may find yourself in a situation where your employer claims ownership of the software you worked on in your own time. Before beginning, consult your employer to clarify the moonlighting policy at your company.

A good place to get started could be OpenHatch. They're a website devoted to helping people get involved with Open Source projects. They'll be able to give you a list of "bite-sized" bugs to get started on any of the projects that have signed up with them, and can help get you in touch with other contributors who are willing to mentor you on the project and/or language of your choosing.

Upstream acceptance of your patches will and nearly always does hinge on the quality of the patch, and if it has accompanying test cases. Many projects in fact will not accept patches unless they include a test verifying the patch.
Since the quality of your code is something that will be subjectively judged, be prepared to work with constructive criticism from upstream maintainers to improve your code.

Jeff Welling
  • 1,289
  • 1
    Their policy on moonlighting is something I had not even considered. Also OpenHatch.org looks rather cool. Signing up right now to check it out. – Tarmon Apr 28 '11 at 21:05
  • 2
    Another note about moonlighting, if do ask your employer, you may want to do so via email for the paper trail. Otherwise, what's to stop them from changing their mind later and saying they never renounced their claim to your project? Just a thought. – Jeff Welling May 06 '11 at 06:09
  • I can't believe this question was closed, especially since it has so many great "answers," opinion-based or not! – Raydot Jun 02 '14 at 23:59
7

As the manager of an open source project (FireBreath) I would suggest that you simply find a project that you use or that interests you and look for ways you can help. There are a lot of things you can do without even writing any code. In our project, we need people to help:

  • Test and report bugs
  • Update documentation on the website
  • Help write secondary tools
  • Hang out in the IRC room and help new users
  • Create example plugins using FireBreath for new users to look at

These are specific to my project, of course (and you're welcome to help! ;-) but all projects have things like that that new users can contribute. My most recent contribution to another project was to add a tool for better management of wildcard repository permissions on gitolite. Stick with projects that you find interesting or can use!

Good luck!

taxilian
  • 171
  • I didn't even think about things like that. Thanks for the suggestions. I'll go do some searching around for a newer project that needs those types of things. – Andrew Jan 23 '11 at 03:33
  • +1 for documentation. As a coordinator for SharePoint SUSHI, one of the most tedious and hardest things to write are docs, but they are also the most important for new users. Helping there will also get you familiar with the features of the project and how it works. – Ryan Hayes Jan 23 '11 at 23:45
3

I can't tell you what project you should choose - this is up to you actually. However, I can tell you how to get involved: if you feel a passion for some project, i.e. been using application for quite a while (for OS it might not be as easy), you can always submit patches with suggested changes (enhancements, bug fixes) and ask project owners for review/integrate.
That is fairly easy with projects on GitHub - just create your patch and submit pull request.
Anyway, the more valuable patches you submit, the more likely is they would welcome you to the core team.

Paweł Dyda
  • 1,508
2

If you are not expert in a particular language there are still many activities that are highly valued. They include testing, writing tutorials, writing API documentations, doing the website for the projects etc. If you have a special interest find a project in that area and contribute domain knowledge. (For example we have an active community of chemistry OS projects).

2

For getting into Open Source projects, have a gander at OpenHatch - that is their entire mission:

an open source project with the goals of lowering the barriers to entry into open source contribution and increasing diversity. We achieve these goals through a number of initiatives...

gnat
  • 21,213
  • 29
  • 113
  • 291
James
  • 1,813
1

For example, Mozilla is always looking for C++ programmers for developing and testing their projects. It is overwhelming for a new comer to download the massive code base and spend hours building it. Then it takes in the neighborhood of six months where you spend an average 10+ hours a week to get acquainted with it and understand a bug or defect or such a thing. Then, soon you should be able to understand how to look reproduce, isolate, fix, test, regression test, get the patch applied. As you do this more, you may get direct write access to the code base, oversee a feature or so. I believe this is true for every project that is mature with lots of people working on it.

On the other end, there are many projects dying because there is no one to develop them. It could be hard to find people who can help you or documentation in these kinds of ones.

To strike a balance between these extremes, you can find a program that you need to use often or everyday. Keep using it enough that you max out its feature set soon. Perhaps develop some kind of affinity toward using it over other options. Then, you could either submit a feature request or take it upon yourself as you are likely to be the one with most understanding of the feature you propose. On the surface, this option makes you feel like you are never going to max out a program's features. If you stay with it long enough, you will need the program to do more than what it can actually do. It could be a security/privacy fix, or a subtle thing or a usability improvement.

vpit3833
  • 1,320