ESR wrote "Every good work of software starts by scratching a developer's personal itch." You'll be much more effective working on a program that you use and want to make better, compared to a beginner-friendly project that you have no interest in.
Instead of looking externally for projects, look inwards. Think about the software you already use, and how it could be better: that stupid annoying behavior, or that obvious improvement, or your idea for a cool feature. And then set your sights on that!
An example: I was a big fan of the game Angband, which I played on Mac OS 9. When OS X came out, I wanted to play Angband again. So I "carbonized" it, so I (and others) could play it on OS X. I had never carbonized a program before, and that's how I learned.
I apologize for not really answering the question, but I have known aspiring programmers give up because they got bored. "Not being bored" is really important, more important than "not being frustrated."
I've had experiences of projects I tried to get involved because I liked the software but where the maintainer had zero interest in involving any new people. It's lovely that developers scratch itches and create cool software - there isn't anything that implies those same people want to work with other new people.
I'm glad you had a good experience and maybe I was unlucky or whatever but I don't think mere interest in the software is enough, the project has to be in a state where the developers want other programmers involved (lots of projects would like some testers and documenters but nothing else and to an extent understandably).
I mean, I'm not sure why guidance towards accessible projects is a bad thing.
Edit: Oh I knew I'd get reactions. Counter-arguments?
A lot of professional software teams have a hard time adding new people. Why would any old open source project be easy to get involved with?
Edit2: I love the idea of open source, I want to get involved again in a larger project when I have time but the "no problems" guidance approach seems itself a problem. Lots of projects are even infamous for problems. There's clearly more to what project you'd be a fit for than "what you love" and just leaving that as the advice seems like a characteristic problem of open source itself.
Well, the idea is that if you start working on a project specifically because it is noobie friendly you are likely to burn out quick since you don't have that itch you are scratching.
I think the parent is correct in that you should try to work on projects that scratch an itch. If it turns out it is a hard community to work with then fork it or move on to your next itch.
If it turns out it is a hard community to work with then fork it or move on to your next itch.
Some people might unlimited energy to program and infinitely thick skin. I think a lot of people find putting energy into a project that rejects their efforts to be somewhat traumatic and something that can impel them to give up rather than bounding on to this next adventure.
I agree that getting involved with a project that interests you should be one factor in choosing what to involve yourself with. But the OP said "any of them!" concerning what project to get involved with where as I'm arguing one should be selective and that people involved in Open Source already should be giving some guidance on the question beyond just "whatever you want".
I think this is a bit of a non issue. Wouldn't a bad community or developer become evident when you started looking around at how to help and contribute to the project?
Just recently I decided I was bored with my routine at home and wanted to challenge myself. So I set a task: pick a public repo that I don't already maintain (preferably that I use), find a bug I would like to see fixed (emphasis on would like to see the bug fixed), and to fix it.
I ended up choosing a program that I use but is written in a language I'm not familiar with. Regardless, I jumped right in.
First I looked around for any mailing lists or chat rooms where development discussion is carried out. I joined and asked how I can help, and was directed to the bug tracker and told to go nuts. I can see how this can be a daunting task, but I found the easiest way forward is to put those feelings of being overwhelmed aside and to just start. I cloned the repo and grepped for a tag I hoped would get me to the code I needed, luckily it was a good guess.
I spent the weekend reading the code for no less than three different projects and learning a lot about erlang, and by yesterday evening I had a patch created and a pull request submitted. And I feel fantastic for it and am looking forward to setting a similar challenge next weekend.
My point is that I think part of looking around the project and bug tracker should help you figure out what the attitude of the Dev team is like. I don't doubt there are sour devs our there but IMO they are few and far between, more likely is the unresponsive maintainer who lost interest in the project but still has the keys to the kingdom.
What's the worst case scenario? You create a patch and the project maintainer refuses to merge it? If he doesn't provide good reasons for not wanting to merge it, he looks bad. If he says your code quality needs improvement you can ask for specifics and learn some new tricks. If he says he just doesn't want that feature then leave your code up on github and see if other people start advocating for having your issue merged. This seems like a tempest in a teacup to me.
When you are just starting out, you don't know what is normal and you can't tell whether the project is poorly run or whether you are just bad at programming and should give up.
I think if you don't know what's normal yet, set the bar.
What I mean is, when you're trying to contribute, how do your interactions with that project and the developer(s) make you feel? At the end of the day, if you're not enjoying yourself and what you're doing, drop the project and find something you enjoy. Might be a different more-receptive project, but it might be a different hobby too, I would encourage you to try multiple project before giving up though.
> "if you don't know what is normal yet, set the bar"
What do you actually mean by this? I'm pretty sure I'm misreading you here.
What I'm reading is "when you come into a new organization and you see people doing things that make you feel bad, force them to change their culture." However, arguing against that feels like arguing against a strawman because it seems obvious to me that you can't effectively change an organization as a random novice and that trying to do so is going to make people really dislike you. Even if it would happen to work, doing it requires being the sort of person thats willing to be called an asshole.
Your level of energy for programming does sound pretty impressive compared to mine. I will admit that if everyone else has energy to churn out patches willi-nilli, worries about whether they would get pushed would not be a non-issue. I'm not so sure that's true, however.
> I've had experiences of projects I tried to get involved because I liked the software but where the maintainer had zero interest in involving any new people.
That's absolutely true, but, given that this is open-source, there's always the option of maintaining it yourself. Of course, for someone who's an absolute newcomer, it's better with a buddy.
Tell you what. I'm interested in projects in C or Python doing systems-y things and that can be compiled on Debian (think stuff in the space of GLib, NetworkManager, apt... but also anything tinier, obviously). If you find a maintainer who's wholly uninterested in adding people, you've got a new feature you want, and you want someone to work with, shoot me an email, I'll probably be up for helping out with it.
Chances are that the maintainer will be interested in the feature, just not in mentorship. And even if the maintainer is just antisocial, chances are maintainership will change, or the world at large will benefit from a fork, or the Linux distros will be willing to take your patches even if the original maintainer isn't.
A problem is that for many projects, the maintainers don't bear any cost when someone new tries to join a project, invests a bunch of time+effort and ends up nowhere. Therefore, even if they really don't have time, energy, or inclination to spend time mentoring, they can just say "welcome to the team" and toss the new member into an ocean of code to sink or swim. Some will in fact swim.
Conversely, if they do spend a bunch of time on detailed mentorship, the new contributor doesn't have to stay
My point is not that every programmer should be welcomed with open arms by every project. There are go reasons for the projects themselves to be selective.
But that is not a reason for a would-be contributor to be unselective themselves. It's a reason for a contributor to also be selective and not just choose any project that suits their fancy. This is my point.
I strongly agree with you. I think that selectivity should be explicit and that there are currently incentives for maintainers to merely implicitly and quietly be selective
This is a good idea, but be sure to clarify that you are a beginner and are looking for mentorship. Otherwise you might get a response that contributions are welcome, but no guidance.
ESR wrote "Every good work of software starts by scratching a developer's personal itch." You'll be much more effective working on a program that you use and want to make better, compared to a beginner-friendly project that you have no interest in.
Instead of looking externally for projects, look inwards. Think about the software you already use, and how it could be better: that stupid annoying behavior, or that obvious improvement, or your idea for a cool feature. And then set your sights on that!
An example: I was a big fan of the game Angband, which I played on Mac OS 9. When OS X came out, I wanted to play Angband again. So I "carbonized" it, so I (and others) could play it on OS X. I had never carbonized a program before, and that's how I learned.
I apologize for not really answering the question, but I have known aspiring programmers give up because they got bored. "Not being bored" is really important, more important than "not being frustrated."