yakking/ posts/ Contributing to someone else's project by Lars Wirzenius
← Unix philosophy | posts | Twelve days of coding →
← Apr 2024 →
S M T W T F S
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

Blog

Contributors

Recent Comments

Archives

Suggestion box

Tags

Blogtrottr

Non-article content is copyrighted to the regular contributors. Articles are copyright to their authors. Comments on articles are copyright the comment's author.

By contributing a comment to the site you implicitly grant the same licence to your comment as is shared by the rest of the site.

Creative Commons Licence
Yakking Blog by Yakking Team is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

There are a lot of free software projects out there, and you'll likely want to contribute to at least one of them. It might be in the form of a good bug report, a fix for a bug, some documentation, a new feature, translation to another natural language, or something else. There are numerous forms of contributions, and they're all valuable and necessary.

A contribution may be a quick, one-time thing, or a long-term committment to the project. Both are good. Free software thrives on drive-by patch submissions, but of course some people need to participate in each project more or less permanently.

As a very important point, note that you do not need to be an expert to contribute. Nobody cares if you have a PhD or not, as long as you make things better. Even if it is only a teeny, tiny little spelling mistake, it's almost always welcomed.

There are some things to keep in mind though, for things to go well.

  • First of all, be polite. Don't show up on the project mailing list telling everyone how stupid they are for not having fixed this problem already.
  • As part of being polite, be patient. Don't push, don't nag. Many high-visibility free software projects are developed by people who are very busy people, and it may take a while for them to have time for you. You don't need to wait forever, but give people some reasonable time to respond before pinging them.
  • Talk to the project developers to make sure they welcome your contribution. If you're going to be making a large change, do this before starting work. For example, rewriting the Linux kernel in Python turned out to be something Linus wouldn't accept, whereas fixing a segmentation fault in gcc is always welcome.
  • As the first part of your contribution, explain why you think it's a good idea. Explain the bug, or why a missing feature is needed, or whatever it might be. This allows others to understand your motivation and hopefully gets them into the right frame of mind.
  • Be prepared for negative feedback. It's possible that the way you've done things isn't acceptable to the project, for some reason. It might be stylistic, or perhaps they can see a better way to design things, or maybe they can see a mistake you've done and want you to fix that. You'll need to adapt your changes based on feedback. That's OK, that's how peer review works. If you're convinced the feedback you get is wrong, you can argue against it, but do it politely.
  • License your changes the same way the project already does.
  • If the project has contribution guidelines or paths, follow them. These usually exist in large projects, such as the Linux kernel. Smaller projects tend to be more flexible.

Some related reading: