7 ms·

I've never contributed to open source before - this might be just enough of a 'its easy just do it - like this' type tutorial to get me started.

by rrrhys 16y ago

jim_dot 16y ago
you really needed someone to tell you that it's easy to contribute to open source?
- moultano 16y ago
  Yes. Don't be a jerk. Even knowing that it isn't technically difficult, it can be socially difficult, and this is a useful guide. Knowing the social protocol of how to get started in the community lowers the mental barrier substantially.
- rrrhys 16y ago
  No - I've got enough shit to do that I haven't really made time to give my effort to someone elses project. Maybe this is why.
- dreaming 16y ago
  yes, it is necessary to be told it is easy to contribute top open source when it is against a backdrop of being told how difficult it is to produce good code, and the difficulties around software development that are frequently reported
- jamesaguilar 16y ago
  Stereotypically it's not very easy. Open source projects are frequently schizophrenic about the code they will accept, saying one day that it's a great idea and the next day rejecting your patch because it's not something they want to do. (This is standard for multi-agent systems, but it's still quite discouraging.) And then there are the attitudes involved. To say nothing of the overall difficulty of writing software. It's not merely a question of needing to be told that it's easy to contribute. That's not even the right way of looking at it. The question is whether it is easy at all, and I say no. If someone told me it was easy to contribute to open source software I'd know they were either lying or delusional.
  - aliguori 16y ago
    I've found few projects that are even close to schizophrenic. I think the thing that people often miss is that getting a patch that works is really only 50% of the process of getting a bug fix/feature merged into an Open Source project. In a company, the hiring process is an initial crap filter (or at least is supposed to be). In an Open Source project, the filters work very differently. You won't find a lot of (community driven) projects that spend a lot of effort putting together detailed documentation about how to build a project and submit patches. That's because figuring this out is the first level filter. The second level filter is figuring out the architecture of the project. This can be difficult in a subtle way. In a company, you can usually sit in a conference room and have someone explain to you all of the details of the project such that you have a pretty good idea of how a patch or feature should be implemented. In most Open Source projects, you generally have to code up an initial version of the feature and then you'll attract enough eyes that you'll get the feedback about how to do the feature properly. If you're a long term contributor, you skip most of these steps and the process is fast. If you've never contributed before, it's almost certainly going to take a lot of effort. It's all about scalability. Open Source projects significantly reward people that are self motivated and can figure processes out without a lot of hand holding because that's the type of person you need to build a successful project when there aren't any managers, program managers, or formal architects. I think that's probably the biggest value of the proposed plan. If someone has gotten 50 patches into a major project, it says a lot more about the individuals personality and motivation than it does about their programming skills.
    - jamesaguilar 16y ago
      Don't get me wrong, I think the plan would work just fine. I just don't buy the view that it's easy contribute to open source projects. It's not, nor should it necessarily be.
    - jrockway 16y ago
      That's because figuring this out is the first level filter. Absolutely not. It's because it's boring and it's time for bed now so let's do that tomorrow. Eventually it does get done, though; all the big-name open source projects have this sort of documentation available. (And now, thanks to Github and the implicit fork-and-pull-request model, so does almost everything else. Reuse++!)

I've never contributed to open source before - this might be just enough of a 'its easy just do it - like this' type tutorial to get me started.

by rrrhys 16y ago

I've never contributed to open source before - this might be just enough of a 'its easy just do it - like this' type tutorial to get me started.

jim_dot 16y ago

you really needed someone to tell you that it's easy to contribute to open source?

moultano 16y ago
Yes. Don't be a jerk. Even knowing that it isn't technically difficult, it can be socially difficult, and this is a useful guide. Knowing the social protocol of how to get started in the community lowers the mental barrier substantially.
rrrhys 16y ago
No - I've got enough shit to do that I haven't really made time to give my effort to someone elses project. Maybe this is why.
dreaming 16y ago
yes, it is necessary to be told it is easy to contribute top open source when it is against a backdrop of being told how difficult it is to produce good code, and the difficulties around software development that are frequently reported
jamesaguilar 16y ago
Stereotypically it's not very easy. Open source projects are frequently schizophrenic about the code they will accept, saying one day that it's a great idea and the next day rejecting your patch because it's not something they want to do. (This is standard for multi-agent systems, but it's still quite discouraging.) And then there are the attitudes involved. To say nothing of the overall difficulty of writing software. It's not merely a question of needing to be told that it's easy to contribute. That's not even the right way of looking at it. The question is whether it is easy at all, and I say no. If someone told me it was easy to contribute to open source software I'd know they were either lying or delusional.
- aliguori 16y ago
  I've found few projects that are even close to schizophrenic. I think the thing that people often miss is that getting a patch that works is really only 50% of the process of getting a bug fix/feature merged into an Open Source project. In a company, the hiring process is an initial crap filter (or at least is supposed to be). In an Open Source project, the filters work very differently. You won't find a lot of (community driven) projects that spend a lot of effort putting together detailed documentation about how to build a project and submit patches. That's because figuring this out is the first level filter. The second level filter is figuring out the architecture of the project. This can be difficult in a subtle way. In a company, you can usually sit in a conference room and have someone explain to you all of the details of the project such that you have a pretty good idea of how a patch or feature should be implemented. In most Open Source projects, you generally have to code up an initial version of the feature and then you'll attract enough eyes that you'll get the feedback about how to do the feature properly. If you're a long term contributor, you skip most of these steps and the process is fast. If you've never contributed before, it's almost certainly going to take a lot of effort. It's all about scalability. Open Source projects significantly reward people that are self motivated and can figure processes out without a lot of hand holding because that's the type of person you need to build a successful project when there aren't any managers, program managers, or formal architects. I think that's probably the biggest value of the proposed plan. If someone has gotten 50 patches into a major project, it says a lot more about the individuals personality and motivation than it does about their programming skills.
  - jamesaguilar 16y ago
    Don't get me wrong, I think the plan would work just fine. I just don't buy the view that it's easy contribute to open source projects. It's not, nor should it necessarily be.
  - jrockway 16y ago
    That's because figuring this out is the first level filter. Absolutely not. It's because it's boring and it's time for bed now so let's do that tomorrow. Eventually it does get done, though; all the big-name open source projects have this sort of documentation available. (And now, thanks to Github and the implicit fork-and-pull-request model, so does almost everything else. Reuse++!)