28

I'm new to the open source community. I've always wanted to contribute to successful existing open source projects. I thought that contribution to good open source projects was meant only for experienced great programmers. Since there is an open source community on Stack Exchange now, I thought I would ask here.

  1. How can someone new to the open source community (like me) start?

  2. How does the contribution flow work in open source projects? (Like first maybe you monitor activities in that open source community, then read through the bugs list or contribute to documentation, etc. I don't know, I'm just speculating.)

  • 4
    Hi @ynos1234 and welcome to the site and thanks for your participation. This question seems very broad to me as it is, but as far as I can tell has not been asked yet. This could provide a valuable general reference for people starting with Open Source, but we'll have to discuss this among the community before allowing this. So I'll vote to close for now keeping in mind that we might reopen this question with some changes and possibly as a Community Wiki. – overactor Jul 15 '15 at 6:23
  • 2
    I've posed a question regarding this question on meta, feel free to weigh in. – overactor Jul 15 '15 at 6:36
  • 3
    I know that many would-be contributors to free software wonder about this, so I hope this is not closed as "too broad". It is a question that should be answered! – Free Radical Jul 15 '15 at 6:37
  • 1
    @FreeRadical closing a question doesn't mean "we don't want this question", it means "this question needs some work before it can be answered". – overactor Jul 15 '15 at 6:42
  • 1
    ynos: You've seen the meta post, and I think this could be a really good canonical question. Suggestion: point 4 in your question should be split off into a separate post. Then I think we can reopen this and get some great answers. – ArtOfCode Jul 15 '15 at 8:43
19

Where can I start contributing?

There are two obvious stages to this: pick a language, pick a project.

Pick a language

You should pick a language with which you are familiar and proficient. I'd advise not trying to contribute to projects in languages you're not that great in - yes, it is a good opportunity to improve your skills in that language, but it's also a good way to annoy the developers because you're doing things in a way that the language could do much better. A good example of this is Python:

some_list = ["a", "b", "c"]
if hasattr(some_list, "a"):

This seems to be correct to many new in the language: the documentation suggests that hasattr returns true if the given list has the given attribute. However, it won't work as expected, and could actually be done in a much more 'Pythonic' fashion:

some_list = ["a", "b", "c"]
if "a" in some_list:

Moral of the story: pick a language you're good at, so you don't have to worry about your coding style or practices being the cause of your pull requests getting rejected.

Pick a project

Now you pick a project, written in your chosen language, that you want to contribute to. If you've had some exposure to the language, you may already have come across useful utilities or tools that you use that are open-source: these are good choices because you'll be motivated to contribute well.

You should always pick a project which interests you. If you're not interested in crunching data, don't pick a graphing library. If machine learning gets you going, try to find something in that area. Maybe you can even contribute to a project you're already using.

A good resource for finding projects if you're stuck is Code Triage, which lists repositories on GitHub by the number of open issues they have. Pick your language, pick an interesting project, pick an issue and try to solve it.

What's the contribution flow?

This really depends what you're good at, though there are some givens. You should always start by familiarising yourself with the project: read the documentation, read the codebase. If the hosting supports it, you should clone the repository and build the software on your local machine, and have a play around with the code to figure out what each part does.

Once you're familiar, you can choose what you want to do. If you're a technical writer, writing documentation is probably a good choice for you. If you hate writing long documents, but you're good at programming, pick an issue and try to fix it.

Whatever you do, make your changes in a fork of the project's repository somewhere you control. Test them (see Whose responsibility is it to test contributions? for information about who does what testing) and make sure everything works. Make sure your code style conforms to that of the project: developers aren't going to be happy with ten thousand different styles in their project because they've got lots of pull requests. Make sure you've read any contributing information the project has. If you've conformed to everything, you can submit a pull request to the project's developers, who will review your changes.

Expect rejection.

You're not perfect and neither is your code; the project developers may well find some issues with it or some style point they don't like. It's your work, so it's your responsibility to fix these: monitor the feedback on your pull request, and use it to change anything they ask you to. When that's done, you can resubmit your pull request and have it merged. Wash, rinse, repeat.

  • I might add that it's good etiquette to open an issue detailing the change you'd like to make, why you want to make it, how it's a useful change, and stress that you're happy to do the work of the maintainers are open to a pull request for it. – RubberDuck Sep 9 '16 at 0:52
11
  1. How and where should a newbie like me start?

Pick a project you use, and that you think can be improved (a bug needs fixing, there is a feature that you would like to see added). Make sure your contribution is small and focused.

  1. How does the contribution flow works in open source projects? (Like first maybe you monitor activities in that open source community, then read through the bugs list or contribute to documentation, etc. I don't know, I'm just speculating.)

You're on the right track. The details depend on the project. Drupal, for instance, offers a detailed description of novice workflow. Look for similar guidelines in whatever project you're interested in contributing to.

  • Thanks Free Radical. I was hoping for an answer like, taking a particular open source project and explain how the contribution works there and how you started contributing in a TLTR answer. – Sony Mathew Jul 15 '15 at 6:57
  • Your two last points should not be in an answer but rather a comment, since they don't answer the question but instead talk about the question. – overactor Jul 15 '15 at 9:02
  • @overactor I removed the last point and asked it as a separate question. Should I remove the other one also.? – Sony Mathew Jul 15 '15 at 9:08
  • @overactor & Free Radical, Done..!! – Sony Mathew Jul 15 '15 at 9:40
  • 3
    This answer touches on a critical point that is missed by the accepted answer: that contributing to OSS projects shouldn't be an end in itself. Improve something that you use, or write something that you want to use, and chances are at least a few other people will like it. Writing what you think other people would like just leads to boring software that nobody likes. I've written some pretty esoteric stuff that's used by, like, four people on the entire planet. But I wrote it for me, so that's okay. – Kevin Krumwiede Jul 21 '15 at 19:08
6

The first thing you should do is select a project. A good place to start would probably be a project you already use, or are at least passionate about.

Second, I'd do some lurking - subscribe to the mailing list(s), and read a bit so you get the "vibe" of the community and get an initial feeling of what's acceptable and what's not, what kind of patches are welcome, etc. Once you get comfortable with that, start participating - answer simple questions you feel you understand fully, share your opinion on open questions, etc.

Now you're ready to start getting your feet wet. Don't expect your first contribution to be re-writing the entire thing from scratch. Baby steps is the way do to it.
Before starting anything, read the submission guide (e.g., here's git's, just as an example) and the coding standards (again, git's). Following them will (hopefully) prevent your patches from just being out-right ignored, not to mention it's just common courtesy. The more "outgoing" projects have an open task list, and the really outgoing ones have it broken down by skill/knowledge levels. If your choice project doesn't have such a list, it's bug/issue tracker is a good place to start. (Simple) bugs are usually well scoped, and even if the solution isn't always obvious, the requirements usually are.

And most importantly - be ready for feedback. Very few patches get accepted in their first iteration, and although the feedback you get may be worded harshly, remember to take it as feedback on the patch ("this isn't good enough to be merged yet"), and not personally.

2

Before you start contributing to an open source project make sure doing so is something you want to do and aren't doing because you think you need to.

Andre Arko has three questions you should answer before diving into an open source project: https://www.cloudcity.io/blog/2017/01/25/is-contributing-to-open-source-right-for-you/

If answering the questions, open source is a fit for you, dive into Andre's 15 minute a day plan for going from newbie to core contributor on an open source project: http://andre.arko.net/2016/11/12/how-to-contribute-to-open-source/

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.