4 ms·

The answer is "all of them!" ESR wrote "Every good work of software starts by scratching a developer's personal itch." You'll be much more effective working on

The answer is "all of them!" 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."

joe_the_user 12y ago
This is seriously not true. 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.
- mordocai 12y ago
  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.
  - joe_the_user 12y ago
    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".
    - click170 12y ago
      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.
bluedino 12y ago
You need motivation of some sort to create a feature or fix a bug. Whether it's a monetary reward, notoriety, or your own need for the feature.

joe_the_user 12y ago

This is seriously not true. 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.

mordocai 12y ago
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.
- joe_the_user 12y ago
  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".
  - click170 12y ago
    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.

bluedino 12y ago

You need motivation of some sort to create a feature or fix a bug. Whether it's a monetary reward, notoriety, or your own need for the feature.