4 ms·

It's a valid question, but you may want to start by contributing to OSS projects that you actually use. The story in the article is about the author and his co

It's a valid question, but you may want to start by contributing to OSS projects that you actually use. The story in the article is about the author and his cofounder contributing to a library they used heavily. You already have a vested interest in things you use. The next step would be to visit the git repo and see how you can help.

watwut 9y ago
Why? This answer is most common one and always puzzled me. Just because I like to use something does not mean it is good project for me to contribute to. They tend to be very different categories. Plus, the pool of people who have time to spare and want to do something is different then pool of people who have scratches all around the projects.
- UncleEntity 9y ago
  > Why? This answer is most common one and always puzzled me. If you don't use it how do you know you're solving actual user problems? I used to contribute to an OSS project and there were a lot of times where the devs and users had differing opinions on how a feature should work.
  - figgis 9y ago
    > If you don't use it how do you know you're solving actual user problems? There are many (many) ways to contribute to a project that doesn't require you to be solving actual user problems. I'd suggest just finding new projects, review code, create pull requests for those small mistakes you see. Provide feedback if applicable. Etc.
  - watwut 9y ago
    > If you don't use it how do you know you're solving actual user problems? You can fix uncontroversial bug/feature request from issue tracker. Not everything us contested, most of it is not. Also, I would expect the project to welcome someone doing the work more then just another one that came to argue .
- echolot 9y ago
  It puzzles me why anyone would go around fixing bugs in libraries they would never use themselves. If you don't like my answer, then go read Kierkegaard or Sartre and contemplate the essence of your existence, and then go do what fulfills you as an individual.
  - figgis 9y ago
    It puzzles why anyone would go around picking up trash from parks they never use themselves. If you don't like my answer, then go watch idiocracy and contemplate the essence of your existence, and then go and do what fulfills you as an individual. -- It puzzles me why anyone would go around in a santa suit cheering up kids they'll never see again. If you don't like my answer, then go read How the Grinch Stole Christmas and contemplate the essence of your existence, and then go do what fulfills you as an individual.
    - echolot 9y ago
      Kierkegaard is smiling from the afterlife.
- pm215 9y ago
  I think one reason is that if you already know a project as a user you're a long way up the learning curve for understanding it. You know roughly what its feature set is, you know how new features would fit in with the existing ones, you know how to do basic "does this thing work" testing of it. You probably have an idea of what changes are likely to be small tweaks to existing functionality and what are bigger and harder. Knowing the shape of the outside of something makes it easier to understand the inside of it. If you start out with a contribution to a project you don't use, you don't have that initial base to build on and so it's harder. Which isn't to say it's impossible, of course -- people getting new jobs working on proprietary software have to get up to speed with programs they probably never used before. It's just time consuming. The "what should I work on?" question implies that the asker has no preference, so answers optimising for what's easier to get started with make sense.

watwut 9y ago

Why? This answer is most common one and always puzzled me. Just because I like to use something does not mean it is good project for me to contribute to. They tend to be very different categories. Plus, the pool of people who have time to spare and want to do something is different then pool of people who have scratches all around the projects.

UncleEntity 9y ago
> Why? This answer is most common one and always puzzled me. If you don't use it how do you know you're solving actual user problems? I used to contribute to an OSS project and there were a lot of times where the devs and users had differing opinions on how a feature should work.
- figgis 9y ago
  > If you don't use it how do you know you're solving actual user problems? There are many (many) ways to contribute to a project that doesn't require you to be solving actual user problems. I'd suggest just finding new projects, review code, create pull requests for those small mistakes you see. Provide feedback if applicable. Etc.
- watwut 9y ago
  > If you don't use it how do you know you're solving actual user problems? You can fix uncontroversial bug/feature request from issue tracker. Not everything us contested, most of it is not. Also, I would expect the project to welcome someone doing the work more then just another one that came to argue .
echolot 9y ago
It puzzles me why anyone would go around fixing bugs in libraries they would never use themselves. If you don't like my answer, then go read Kierkegaard or Sartre and contemplate the essence of your existence, and then go do what fulfills you as an individual.
- figgis 9y ago
  It puzzles why anyone would go around picking up trash from parks they never use themselves. If you don't like my answer, then go watch idiocracy and contemplate the essence of your existence, and then go and do what fulfills you as an individual. -- It puzzles me why anyone would go around in a santa suit cheering up kids they'll never see again. If you don't like my answer, then go read How the Grinch Stole Christmas and contemplate the essence of your existence, and then go do what fulfills you as an individual.
  - echolot 9y ago
    Kierkegaard is smiling from the afterlife.
pm215 9y ago
I think one reason is that if you already know a project as a user you're a long way up the learning curve for understanding it. You know roughly what its feature set is, you know how new features would fit in with the existing ones, you know how to do basic "does this thing work" testing of it. You probably have an idea of what changes are likely to be small tweaks to existing functionality and what are bigger and harder. Knowing the shape of the outside of something makes it easier to understand the inside of it. If you start out with a contribution to a project you don't use, you don't have that initial base to build on and so it's harder. Which isn't to say it's impossible, of course -- people getting new jobs working on proprietary software have to get up to speed with programs they probably never used before. It's just time consuming. The "what should I work on?" question implies that the asker has no preference, so answers optimising for what's easier to get started with make sense.