Ask HN: How to get started with open source contributions?

To answer the title question, it might be best to look for smaller projects in a language that you're very familiar with with issues marked specifically for external individuals to complete. Smaller scope issues should be easier and they would give you some more experience in reading code which would appear to be the issue at hand.

For the larger codebases, generally you would want to get a vague idea of the architecture and then blind yourself to most of the complexity. Let's say that you wanted to work on a network based data serialization library and the issue marked out as 'contributor friendly' was adding unsigned integer support building off existing signed integer support. For that target, there's a large portion of the code that you shouldn't need to understand too deeply and there's a section that is going to be relevant to making the modification. Try to find the code that is relevant and trace the execution just by reading the code.

As long as you limit the scope of your work and the codebase is somewhat compartmentalized, you can shrink the time it takes to go through large projects by a fairly large amount.

My comment pertains to the part of your question about understanding a large code base...

- First attempt to use and compile the project

- Figure out where the entry points are for the app. Generally this would be a 'main' function and any sort of event handlers. Frameworks complicate this a bit because they're responsible for calling code and do it in any number of arbitrary ways.

- Get a feel for the organization of modules/packages etc. Try to find the naming structure/patterns and how everything is laid out conceptually.

- Focus on a few features (just a random sampling) and grok how those work. Hopefully at this point there's some semblance or order in the project, so that if you understand how a few parts work, you can start to build a model in your mind how everything works, without trying to study everything in the codebase. And an architecture diagram from the project owners would help too, if an up-to-date one exists (doubtful).

- Make a very simple/trivial change, compile it and try to observe the result (that your change successfully compiled).

- Choose a bug or very small feature to work on.

- Success?

Edit: I just read the comment by 'fundamental' which I happened to basically restate with bullets. Anyhow, good luck. It took me about 2 years of full-time programming before I got comfortable reading large codebases.

First, to be a good contributor, you almost always have to be a consumer of the library. Once you understand how the library usage works, then you can work on improving the api, fix bugs, or even just improving the documentation.

Read the source code, and see if you can find any small wins such as optimizations or better api.