Ask HN: Jumping onto the moving train of an active and large OSS project? | Hacker News Reader

Ask HN: Jumping onto the moving train of an active and large OSS project?

26 pointsilovecaching7 comments

Looking for both advice and anecdotes on joining well known, large public projects. Some friction points I have discovered and would like to address:

- Maintainers already have mature code and are far up the mountain of domain expertise. Playing catchup is hard.

- Open work is either too trivial, picked up too quickly by maintainers, or not documented. The, "I wish I had an idea for a feature I could contribute in the first place" problem.

- Medium plus sized projects require lots of domain knowledge, which means a new contributor will be slow. Often not able to ask many dumb questions to busy maintainers to unblock oneself.

- Putting work out into the public and getting scrutinized by old time maintainers can be daunting.

I'm asking, because I've realized that the only time I've successfully onboarded onto a large project has been with physical proximity to a developer and hand holding as I joined a new team driven by corporate interests. I'm interested in learning how to tackle the hard mode of making this jump into maintainership in open source.

Don't look for a project to contribute to. Pick a real problem you have - maybe a bug you can reproduce or a feature you'd like - and fix it. If you approach a maintainer with a stackoverflow-like question "I'm trying to achieve X, I got up to point Y and am stuck on Z", it's likely they will point you in the right direction.

If you still feel like you want a specific project and you don't necessarily have a problem to solve, go into their bugzilla/issues-db and start helping moving all the bugs forward: try to reproduce them, ask users for more info, fix the tags, etc.

What is your actual goal, beyond joining the project? Is it to upstream a fix or feature you find useful and don't want to maintain as a fork? Is it to build a personal portfolio of contributions? To learn close-up about technology the project is using? Would you eventually like someone to pay you to contribute to the project? Etc.

What if poster wanted these twi outcomes. How would they go about it?

Is it to build a personal portfolio of contributions?

Would you eventually like someone to pay you to contribute to the project

This was my question as well. I was myself directly involved for about 10 years in the development and maintenance of a medium-sized open source project, and am still part of the community, and there was never really any form of "external contribution", appart from the occasional user who found a problem in the docs or a small bug and was knowledgeable and kind enough to fix it and submit a PR (less than a handful in 10 years). And we typically would already know the guys from conferences or similar.

I feel that the user is coming from a place of wanting to gather experience and show it, and read somewhere that open source is great for this. But lots of projects are open source not to favor external contributions, but for other reasons. And external contributors will typically be long term users of the software, who already have deep knowledge about it and a personal interest in moving it forward.

If the aim is to get experience, I am actually convinced that it is easier to get an entry-level job than to invest the time and effort to be able to make significant contributions to big open source projects. Of course if you manage to get a job where you can contribute to open source, even better.

Good luck!

Find something you’re interested in and spend weeks/months reading, running, debugging the code on your own. If you’re still interested, you won’t need all the hand holding because you’ve already been working with the code. Pretend it’s like a real work situation that I’ve been in several times - there is no documentation and nobody to ask - read and run the code til you understand it.

You say that, but the surface is large with many, many corners - like a fractal.

If you just use the project for a bit you will find things, some of them might be things people will fix, others won't be fixed.

Django is something I've used for work projects for over a decade now, and there are all sorts of tickets that are older than that, just waiting to be picked up again.

Other projects of similar age and size are the same.

Yep. Should be hundreds of tiny issues that need fixing on any mature project. I sometimes fix a handful of them when I'm working in that area/feature again but otherwise they can sit for years.

Reply on news.ycombinator.com