This is really the correct answer: Why do you want to participate in an open-source project in the first place?

If it's to gain brownie points for your CV, it's quite likely that you'll get nowhere, because that's a motivation right along with "earn money".

The difference to just getting a random software development job for earning money is that at the random job, you will be in a team where tasks will naturally flow towards you. In a random open source project, this will not be the case. So most people will not stick with it unless they have a better motivation for contributing to the project in the first place.

So try to find a project that you find interesting first. You should actually be able to find many of those if you're into software development, and then take a look at the communities yourself.

Another tack: look for employers that have already demonstrated a commitment to open source software / hardware. (This is, of course, a difficult chicken-and-egg problem for those looking to bolster a CV.)

I think starting at the language level, and then digging deeper for sub-projects in your interest sphere is a good strategy. I'm partial to the Perl and Python communities. Both have BDFLs that are kind people who lead by example. Projects associated with these languages often seem more accessible (IMO), and I think Larry and Guido deserve a lot of credit for that.

I'll also throw in a plug for jabber.org and telehash.org because Jeremie is one of the nicest people I've ever met.

edit: and exercism.io because Katrina is brilliant and dedicated to community building.

This, so much this.

Working on Open Source absolutely requires individual contributors to be self-starting. New contributors who lack drive require constant direction and/or hand-holding, undermining the time/effort commitment of existing contributors.

Most Open Source projects invest a lot of time/effort coaching new contributors. If a new contributor receives the coaching but doesn't produce anything useful; it's a net loss for the project, users, and community.

I always tell people who want to start contributing to OSS to start with simple/easy tasks like documentation updates. It minimizes the negative impact of poor quality contributions and allows existing devs to identify and correct workflow inconsistencies during peer review.

The other growing pain is new contributors who bring their 'ideas' but put zero effort toward contributing. 'Ideas' are like assholes, meaning everybody has one. They're not particularly useful unless there's a person ready/willing to implement them. Even then, a new idea may not follow the intent of the project and/or its culture.

Endlessly discussing the 'future possibilities' of a project is extremely counterproductive and distracting to existing developers.

I have somewhat different perspectives on "ideas". People discuss ideas first because if they do the implementation first, there is a large risk of wasted effort because it "may not follow the intent of the project". Discussion is in part effort to divine the intent of the project.

As a concrete example, I implemented break and continue for OCaml compiler because having for loop without break/continue seems to me obviously a bad idea. Although I learned a lot about OCaml compiler internals, this went nowhere. I learned my lesson, and now I will certainly "endlessly discuss" possibilities of break/continue first, without writing a single line of code. In my opinion, berating people for this is placing undue burden on contributors.

http://caml.inria.fr/pub/ml-archives/caml-list/2008/04/ce14d...

An idea followed by an implementation is awesome and exactly what OSS projects need from contributors.

"I learned my lesson..."

I read the mailing list and don't see how that was a negative experience. Only one of the contributors had an unfavorable response.

Even if they don't implement your code as-is, it looks like you had a good idea including a good implementation that led to a lot of productive discussion.

Only one of the contributors had a strong objection and despite that, the conversation continued.

Don't take it personal if your code isn't directly incorporated into a project. Despite that, your contribution led to further discussion and helped better focus the intent of the project.

Working on an OSS project is very much about collaboration. Code contributions may not always be incorporated into the codebase, especially on projects like ocaml that have a specific focus and changes have far-reaching impacts on the userbase.

That's not a bad thing. You did well.

:cringe: Apparently I, need to expand the comment text field and re-read my comments before posting. Hopefully, you could infer my meaning from the word vomit.

It was hard for me to find projects I found interesting enough to contribute to.

It wasn't until I had an overarching purpose that I found success. It took about 5 years.

I understand where you're coming from but the open source community as a whole has a reputation (though whether it deserves this is another question) for being a potentially toxic thing to interact with.

I guess I read it as implicit in the question that they're looking for a bunch of open source projects that will be supportive of their contributions to then select one that they find interesting in order to avoid picking an interesting project, working on an issue couple of days only to be told to go %&@# themselves because the PR isn't formatted correctly or something.

Some big projects (Fedora, OpenBSD etc.) are deserving of their reputations for having toxic communities.

I've never experienced such condescension online as from the pricks on the Fedora IRC channels.

I spend my life first and foremost in a community. I think it makes perfect sense to look for a good community first and then check in on their project.

That said, I've noticed that all of my favorite communities are centered around good work, and that good work makes it easy to find and share joy. A great community isn't going to be working on something stupid.