25

I've been struggling to develop momentum contributing to open source projects. I have in the past tried with gcc and contributed a fix to libstdc++ but it was a once off and even though I spent months in my spare time on the dev mailing list and reading through things I just never seemed to develop any momentum with the code. Eventually I unsubscribed and got my free time back and uncluttered my mailbox. Like a lot of people I have some little open source defunct projects lying around on the net, but they're not large and I'm the only contributor. At the moment I'm more interested in contributing to a large open source project and want to know how people got started because I find it difficult while working full time to develop any momentum with the code base. Other more regular contributors, who are on the project full-time, are able to make changes at will and as result enter that positive feedback cycle where they understand the code and also know where it's heading. It makes the barrier to entry higher for those that come along later.

My questions are to people who actively contribute to large opensource projects, like the Linux kernel, or gcc or clang/llvm or anything else with say a developer head count of more than 10.

  • How did you get started? Was there a large chunk of time in your life that you just could dedicate to working on the project? I know in Linus's case he had a chunk of time (6 months) to get it started.
  • What barriers to entry did you encounter?
  • Can you describe the initial stages of the time spent with the project, from when you had little understanding of the code to when you understood enough to commit regularly.

Thanks

sashang
  • 1,076
  • 1
  • 7
  • 18
  • 3
    I've just started a project, I'll give you an answer in a few months time. – dan_waterworth Jan 06 '11 at 13:29
  • What, in particular attracted you to contributing to gcc in the first place? – Tim Post Jan 08 '11 at 15:58
  • @Tim: Can't really remember, it was about 5 years ago. It was a mixture of having an interest in languages and compilers as well as wanting to improve my own knowledge of c++. – sashang Jan 08 '11 at 23:16
  • Title tip: Your current title misrepresents your question. It sounds like you're asking how to get other people to contribute to an open-source project. A few alternative titles: "How did you join a large OSS project?", "How did you become a major contributor?", or "How should I join a large OSS project?" – Evan Kroske Jan 09 '11 at 04:43

7 Answers7

21

  • Start small and start with documentation, tests and other activities that allow you to get into the culture of the open source project.

  • Barriers include lack of documentation, no quick start-up for developers, no mentors and no issues specifically geared for newbies to tackle.

So I started on PCGen by:

  • Tidying up some of the docs, which got me lots of kudos from the rest of the contributors (no-one likes docs).

  • Providing short simple test cases for issues

  • Being a friendly voice in the community (answering simple Q's, building an FAQ etc)

  • helping triage bugs/issues etc

After 2 months of that I was part of the community, understood how the various bits connected and had contributed towards a developers start-up guide which I then followed to get a fully fledged local dev environment going.

  • I then spent time picking off low level bugs so I got used to the coding style, how to submit patches etc

Got into meater stuff after that and the rest is a long boring tale about me, so I'll stop there :).

Martijn Verburg
  • 22,006
  • 1
  • 49
  • 81
8

I got started in the Mozilla project almost two years ago. I was employed this past summer by the Mozilla Corporation as an intern and am now a "module peer", meaning that I have some responsibility for a certain part of the project and do code reviews for that (in my case, the build system). I'd imagine this position as a respected contributor to a major project is where you want to be, so I hope my story is of use.

Getting into open source development had been something I'd wanted to do for a while, but something I never got around to doing. I got started by fixing an almost trivial bug. Fixing that bug taught me how to build Mozilla (on many large open source projects, building the project is non-trivial), navigate bugzilla, get patches reviewed and committed, etc. I fixed a few more trivial bugs before I tackled my first hard bug.

Without going into too much detail I spent a couple weeks on a pretty nasty bug that required digging through some third-party drivers and coming up with hacks to keep them functioning, and then tweaking our hack code to fix regressions and other issues. That was the first bug I fixed that was in the critical path of a release, and it was a great experience. The timing was somewhat serendipitous; I happened to have the relevant hardware and the time to commit to it (this was during the summer in college, so I had plenty of free time).

I spent a lot of time tracking down the fallout from that bug and then from there I spent some time messing around with the Windows drag and drop code because I found it a lot easier to hack on code that had very well defined interactions with other pieces of code. Eventually I branched out into some build performance work (because building Mozilla on Windows is so slooooow). Over time I became competent enough in the codebase to work on major refactorings and feature additions in both C++ and make and I contributed patches frequently enough that I was given direct commit access.

The primary issue I ran into was a lack of documentation. Most open source projects are poorly documented unfortunately. This is one of the reasons I found it easier at first to hack on code where one "side" if you will was well defined by MSDN.

The secondary issue was finding bugs to work on. Finding a bug that is challenging enough to be interesting but doesn't require in-depth knowledge of the codebase is generally difficult in Mozilla. Mozilla has a list of good first bugs that is generally decent, though sometimes it's a dumping ground for trivial changes or projects that nobody cares enough to tackle. If you're interested in Mozilla specifically, log on to our irc network in #developers and ask around or ping "khuey" and we'll find something for you. Other projects probably have similar "getting started" guides or people who can help guide you.

One word of warning: I had the advantage of already being competent in C++. If you're trying to get started on a project where you don't know the language (or a closely related one) you may find this substantially more difficult.

I'd post more links but it won't let new users do that, so I've left the most important one in.

Kyle Huey
  • 81
  • 1
  • Thanks for that. I found finding a bug that's not taken by other developers who've been on the project a while also a challenge. – sashang Jan 08 '11 at 23:19
6

You might want to contribute to OSS software you use everyday. See which of your tools are open sourced, and if there's anything you would like improved in those. Then see if there's anything you could do about it. Two birds with one stone - you improve your tools AND you're contributing to OSS community.

Mchl
  • 4,103
  • 1
  • 22
  • 23
3

You need a strong community before having strong developer momentum.

Watch this talk by Jono Bacon called The Engines of Community, I think he has a book about this too.

Ways you can achieve this is to use Google Groups (it is easy for the community to stay connected through email) and also by hosting and maintaining your code in a place like github or bitbucket. A forum (SMF, MyBB, phpBB) can be quite an useful tool too.

dukeofgaming
  • 13,943
  • 6
  • 50
  • 77
  • I just realized the title might be misleading, so I've reworded it. The question's not about an open source project gaining momentum, but more about improving my momentum on an open source project. – sashang Jan 09 '11 at 04:26
2

I think all the answers to your questions are in this book : http://producingoss.com/ It's free to read online. I'm reading it at the moment for almost the same questions. It's definitely an excellent source of information on the subject.

Klaim
  • 14,832
  • 3
  • 49
  • 62
1

All my contributions to fairly large open source projects came from stuff I needed myself. I never went out and said, "hey, I have so much free time, I want to contribute to something, where can I apply?"

user281377
  • 28,352
  • 5
  • 75
  • 130
0

I began by looking into the sourceforge's help wanted section . I would look for projects that needed my skills , but usually it would be projects where i could build up some badly needed skills.

The next thing I would do is learn to set up the code base and get a working copy running.

Then try to figure out an complete end to end workflow. This way i would understand how the code is written and would be rest assured the same pattern would be used in other workflow . By pattern i mean things like action --> service --> dao etc.

Then i would hunt around for bugs related to the workflow i have just completely understood and try to write a fix . Before that i would look for the unit tests written for the workflow ( if there isn't any i would write one myself)

Then the next thing would be get hold the last guy who had commited the code in the particular module to review my fix.

The ensuing discussions would definitely help in increasing your understanding about a lot of things.

Now you have had a good start and well aware of atleast one tiny particular part of the project. Take control of it and try digging / branching out into other areas.

Also like many have said before try documenting whatever you find and get it reviewed by the person who last committed that part of the code.

These are my little nuggets, good luck. Happy coding.

Cheers, Goutham Rao

Goutham Rao
  • 1