5 Replies - 3010 Views - Last Post: 13 May 2009 - 06:26 AM

#1 BlakeJustBlake  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 26
  • View blog
  • Posts: 441
  • Joined: 15-February 09

What's the best way to get into contributing to open source.

Posted 10 May 2009 - 05:22 PM

I consider myself of at least average programming ability and I've always wanted to get better at understanding software development and working on large scale projects. I've tried jumping into several open source projects before but usually with very little success. So I'm just wondering what the best way to get into these projects is?

Is it better to join onto a big one or a small one? How do you start trying to understand how the program actually works (which modules and objects do what in the program? If there's a bug that has to do with a certain part of the program where do I start to look for it?) How do I just become familiar with the project in general?

I've looked around but have never really found any help for this, it just always seems like something that you have to understand before you start or there isn't really help for you.

Is This A Good Question/Topic? 0
  • +

Replies To: What's the best way to get into contributing to open source.

#2 Martyr2  Icon User is offline

  • Programming Theoretician
  • member icon

Reputation: 4332
  • View blog
  • Posts: 12,127
  • Joined: 18-April 07

Re: What's the best way to get into contributing to open source.

Posted 10 May 2009 - 05:29 PM

I typically find it easier to get on board with a project at the beginning for several reasons...

1) The ones running the project are usually a little more desperate for help.
2) You can learn more because you grow through all the phases of the project from conception all the way to roll out
3) You help formulate the plans in the design phase so you have more of a say in what the end result is and you will also find yourself more engaged if you see some of your ideas coming to life in the project.

The con of the whole thing is that the earlier you get in, the less likely you will know how well the project team will gel and if the project will actually get off the ground. Thousands of projects are started and drowned in the first couple weeks, so be ready for it and only put in as much as you are willing to lose.

:)
Was This Post Helpful? 0
  • +
  • -

#3 Pwn  Icon User is offline

  • D.I.C Regular

Reputation: 19
  • View blog
  • Posts: 458
  • Joined: 25-November 07

Re: What's the best way to get into contributing to open source.

Posted 10 May 2009 - 05:42 PM

Are you saying there is a cost to a project to get started? I imagined opensource would be pretty much costless since people are not getting paid up front for the work, and pretty much all you would really need is a place to store the work. Care to enlighten me what exactly is involved with the process? I've thought about joining openoffice.org, but, like Blake, I get lost in the sea of content.
Was This Post Helpful? 0
  • +
  • -

#4 c0mrade  Icon User is offline

  • D.I.C Regular

Reputation: 20
  • View blog
  • Posts: 412
  • Joined: 16-November 07

Re: What's the best way to get into contributing to open source.

Posted 10 May 2009 - 09:39 PM

Quote

Are you saying there is a cost to a project to get started?

Your time is valuable (perhaps the most valuable thing we have), whenever you spend time on something it is an investment. If you learn something, enjoy yourself, or in any way come out better than you went in, your investment has paid off.


@Blake
I do not have much direct experience contributing to open source, but I think your largely asking about familiarizing youself with an existing project. I really don't think there is any way this can be taught, I'm still getting used to it. Just dive on in, pick a small bug, reproduce it, and go from there. I guess that is one tip that could come in useful. When fixing a bug, the first step is always reproduction.

Good luck!
Was This Post Helpful? 0
  • +
  • -

#5 NickDMax  Icon User is offline

  • Can grep dead trees!
  • member icon

Reputation: 2250
  • View blog
  • Posts: 9,245
  • Joined: 18-February 07

Re: What's the best way to get into contributing to open source.

Posted 11 May 2009 - 07:01 AM

If you are looking at a pre-existing project then begin to review the code and contribute to the community. Specifically the defect tracking. Try to figure out why various bugs occur and if you can see an easy fix then make a suggestion to the team on how it can be fixed. If you would like to see enhancements then show how they can be integrated into the current design.

The most important step is getting the source code, and getting the project to build locally.

Second most important step is to become familiar with the code.

Third, contribute -- be part of the community.

Do not, try to redesign the project, bad mouth other people's code, or expect things to be happening at a high pace.

If you really want to suck up then work on documentation for them. Many open source project have wiki's for documentation and contributing technical details to these can be a huge help.

For example, document what you had to do to get the project to build on your system.
Was This Post Helpful? 0
  • +
  • -

#6 mikeblas  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 43
  • View blog
  • Posts: 390
  • Joined: 08-February 08

Re: What's the best way to get into contributing to open source.

Posted 13 May 2009 - 06:26 AM

View PostBlakeJustBlake, on 10 May, 2009 - 04:22 PM, said:

How do you start trying to understand how the program actually works (which modules and objects do what in the program? If there's a bug that has to do with a certain part of the program where do I start to look for it?) How do I just become familiar with the project in general?
I don't think this is different for open source projects than it is for any other team-based development project.

You might be lucky, and there's some good and current documentation. If there isn't, or at the initial phase you don't know if you should trust the documentation, you should start working with the code. There's a proverb: "When the terrain and the map disagree, trust the terrain." Maybe there are people you can talk or chat with to help you come to understand what the code is doing.

You'll want to learn how to build the project first. This will involve creating a project enlistment, installing the tools the enlistment uses, and getting the directory structure setup right. Make sure you pick the right enlistment--there might be a stable enlistment, a beta enlistment, and a research enlistment, for example. For large projects, there's probably several different build modes; debug and release at least, plus different OSes and processors, and then differente feature and diagnostics enabled within the debug build. You have to figure out which one you want.

You should set yourself up so that it's easy for you to use both the release build and some debug build. That lets you use the product that you've actually built in release mode without the frustrating inefficiencies of the debug code; and have the debug code handy for actually getting work done.

With that done, you'll want to start looking at code. Everyone does this differently, I suppose. I like to find a feature and figure out how it works. In my head, I might have some hypothesis of its design based one how it works. What the code does is just as important as what the design goals are and the UI is, so you'll want to play with the feature in the actual product before you go diving into the code.

Once I can isolate some feature, I like setting it up to run under a profiler. That shows me what code is calling what other code, and how often. I can quickly get a sense of both flow-of-control and structure this way, and also quickly see any glaring inefficiencies. It's fun to run simple stress tests in this scenario. You can also make similar progress in a debugger. Most people seem to think debuggers are for code that's broken, but it's important to use them to inspect code that works--otherwise, you'll never know how it worked in the first place.

You might follow other checkins, too. Most OS projects have open bug reporting, so you can see what bugs have come up in the past. You should be able to correlate them to checkins that fixed the bug. Review the code change that claims the fix; what did it do, and how did it do it? It's also an opportunity to talk with and meet other guys on the team. Ask them about their fix; can they help you learn the involved classes and functions and data structures? Would you have fixed it a different way? Did they leave another bug behind, or only implement a partial fix?

Almost all of these techniques work on large-team projects, too, even if they're not open source.

Helping with documentation might be one good low-level way to contribute, but it's actually one of the ways that I think projects fail. Leaving grunt tasks to the noobs means that the grunt tasks--even if they're very important, like setup or documentation--are going to be done by someone with little experience, not much investment in the project, and not much direction towards the project's overarching goals.

I hope that helps.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1