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.
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.
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.
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++!)
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.
Not really. You are confusing code and ideas. People like to discuss what they "will do" or what they are "almost done" with, and these ideas get approved and rejected fairly arbitrarily. But small, simple, easy-to-understand patches that come with a test case? Thanks, applied. Always.
If you are getting a lot of pushback on your changes ("it's not indented right"), there is probably something else that's wrong. And sometimes, there is administrative triva to deal with.
(The other day, someone sent me a patch for ibuffer-git via a github issue. I'd prefer a pull request, but fine, whatever, easy to apply anyway. The problem is that I need to keep a list of contributers in case I decide to contribute the extension to the emacs core. This person had no contact information, so I couldn't just apply his patch. I really needed the fork-and-pull-request so that the author information would be properly recorded. Annoying for a 2 line patch, but a necessary evil. And even then, the patch is applied in my repo, it's just not pushed yet :)
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