And you might be surprised at the difference between what it's like to contribute to any random project compared to what a "news" blogger that needs to generate hits wants you to think the average project is like.
And you might be surprised at the difference between what it's like to contribute to any random project compared to what a "news" blogger that needs to generate hits wants you to think the average project is like.
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.
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.
It wasn't until I had an overarching purpose that I found success. It took about 5 years.
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.
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...
"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.
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.
I've never experienced such condescension online as from the pricks on the Fedora IRC channels.
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.