Oh, I absolutely agree that there are projects that aren't suitable for beginner work. Something like the Linux kernel, or MySQL, or any of the other complicated, highly-technical infrastructure projects that exist out there, probably won't have an abundance of the suitable-for-beginners tasks that I'm talking about -- that particular piece of advice is more geared towards projects that exist as helper applications for other hobbies or things that people get passionate about, not projects that are technology infrastructure projects that require people to be passionate about the technology itself. A project such as -- oh, say, book cataloging software -- can recruit brand-new developers from the people who use the project, but who've never programmed before, and use the tiny cleanup tasks to lure them into "leveling up" and taking on harder, more complex issues.
The tiny tasks I'm talking about are things like dialog changes, altering preferences, changing the way the page renders (for browser-based apps) -- stuff that people can do quickly and easily as a beginner, stuff that has a really high 'wow' factor. If you get a patch accepted into a project you use regularly, one that scratches your particular itch (however modest), every time after that you use the product or the app, you see your change and think, "I did that!"
From there, a little effort on the part of the maintainer can nurture that accomplishment glow and make the beginner really think that their contribution is valued and appreciated, no matter how little it is (on DW, we get one-line -- hell, one-character -- patches with about as much frequency as we get the big sweeping patches). Once you get someone used to the feeling of accomplishment, once you provide them with an atmosphere of unalloyed positive safety to make mistakes and ask questions and try things out one by one until something works, they gain the confidence necessary to try the harder stuff, because they know that they won't be judged or shamed if they get something wrong.
It's the shift in conceptualization -- hell, the shift in cultural/project worldview -- necessary to turn flawed or incomplete patches from a detriment to an asset (because they indicate interest in the project and someone who's passionate enough about the end result to spend their time/energy/effort learning things in order to contribute). Using this method, the project maintainer absolutely has to ride herd on everyone involved, because it's fairly common in the OSS world (from what I've seen in my forays, at least) for active contributors to view mistakes with scorn. Project contributors are expected to do things right the first time, because otherwise it just wastes everyone's time.
And it's true that this method of doing things does place an incredible burden on the project maintainers, on the active contributors, and on the people doing code review and commit to mentor and encourage others, or at the very least to tame their worst expressions of annoyance, and that is a time-suck. It's also true that the rate of return on this method is nowhere near 100%, and there will always be instances where your thinly-spread maintainer is going to spend an incredible amount of time and effort on someone only for that someone to disappear without any tangible gain being returned to the project.
This method is more of a "bread cast upon the waters" method, where you have to look, not at the rate of abandonment, but at both the rate of return and the rate of exponential growth: if 50% of the people you mentor at bootstrap turn around and get lured into the project, and those people then turn around and mentor others with another 50% rate of success, and so on and so forth, the maintainer's initial outlay of time and effort will start building up concentric circles of mentorship, where people who have been given a hand up will then turn around and do the same for others, etc. After that initial bootstrap phase, it takes the burden of handling the basics off the maintainer, freeing him/her up for the more complicated technical bits and allowing the basic education to stay in the hands of those who have just recently gone past it themselves. (The other benefit of that is that if it's someone who's just learned teaching someone who's learning, the teacher knows and remembers all of the pitfalls, because they went through it themselves so very recently -- someone with 20 years of experience isn't going to remember all of the things that confused them in their first six months!)
I disagree that being clueless is inherently a form of rudeness -- I disagree vehemently, in fact; rudeness is something culturally defined and not at all concurrent from culture to culture. Cluelessness is a form of rudeness in the most-prevalent open source culture, true -- but I submit to you for consideration the proposition that that very socially-construed definition of rudeness is part of what makes so many OSS projects unwelcoming. There are certainly ways to gently deflect someone with more enthusiasm than experience to the existing newbie documentation for self-education.
It really doesn't take that much more time to type out something like "That's a great idea, and not something that I'd ever thought of before. I'm overbooked right now in terms of tasks that I personally need to get done for the next release, so I won't be able to get to that myself, but if you want to put together a patch, I'd eagerly accept it. (I don't know your experience, so if you need some suggestions on how to get started, check out $newbie_documentation_url for some pointers.)" than it does to type "agreed; can you write a patch for that?" (After a while, it just sort of rolls off your fingers without you having to think about it.)
The former acts to a). validate the person's suggestion, which to them is of course going to be the most imporant thing in the universe; b). provide the person information about why you aren't immediately leaping to implement it, because of course they feel you should see the light of their genius and drop everything to go do it; c). let them know that you aren't just blowing them off, that you do want to work with that person to improve the product; d). provide pointers to implementation information that makes no assumption about the experience level, or lack thereof, of the questioner. (Thus neatly avoiding both the "I've been doing this for twenty years, how dare you assume I don't know what I'm doing" reaction and the "I've never done this before, how dare you assume everyone is as experienced as you are?" reaction.) The latter operates from a number of different assumptions that might have been true in the infancy of the OSS culture (that everyone reading has a certain skill/ability/interest level) but aren't as true now.
Existing OSS culture, in my experience, is predicated around newcomers already understanding existing OSS culture, and reacts swiftly and violently to those who don't. It's also -- and I think this is a little harder to spot, especially for the people who suffer from it -- a culture where the focus is placed on the individual, not on the project: where most projects are centered around the maintainer, not the end result. These two things combine to create a culture where innocent mistakes made out of desire to improve the project are shot down with a vehemence totally out of proportion to the weight of the error, and leave people smarting (and way more likely to say "fuck you, I don't need this kind of crap in my spare time").
You say "the real task in hand [...] is to develop and maintain useful software", which is absolutely true, but which also carries an unexamined assumption: who defines 'useful'? Obviously, the answer to that is going to be different for each project, depending on what the projected use case is, but I've seen a lot of projects where the implicit answer to that is "the maintainer", not "the people who are using it". There's always going to be an element of that in any project, since the maintainer is God for all intents and purposes, with the final say about what goes in and what direction the project is going to be taking, but I think there are ways for a maintainer to keep that leadership role and shepherd the project without conforming to a very narrow personal vision and interpretation of what the software should be. I know that with DW, there are tons of people working on things that Mark and I never imagined that people would want, but which they get incredibly passionate about -- so we let them go for it, and take the end results gladly! That makes the end-result software more broadly usable and useful.
(This is, of course, only applicable to really broad applications. For smaller projects, a narrower focus is far more appropriate.)
I dunno, I'm just sort of noodling around these really big and amorphous concepts, trying to analyze why we've been so successful in recruiting such a broad base of contributors and how those lessons can be abstracted to fit the OSS community as a whole. I've been passionate about OSS use and OSS advocacy for over a decade, but I've never found a project where I felt that my contributions would be welcomed. I've been trying lately to put my finger on why, and why DW would feel different even if I weren't half-owner, so as to be able to articulate it for others. So much of our work with DW has been to actively oppose the unwelcoming cultural practices we've both seen over the years (such as the ones that killed LiveJournal's open source contributor culture), while retaining and strengthening the cultural practices that let LiveJournal's other volunteer cultures thrive and develop.
Thanks for the thoughts, and for letting me poke at some more of my ideas in response to yours. :)
Re: Good ideas, wrong target?
The tiny tasks I'm talking about are things like dialog changes, altering preferences, changing the way the page renders (for browser-based apps) -- stuff that people can do quickly and easily as a beginner, stuff that has a really high 'wow' factor. If you get a patch accepted into a project you use regularly, one that scratches your particular itch (however modest), every time after that you use the product or the app, you see your change and think, "I did that!"
From there, a little effort on the part of the maintainer can nurture that accomplishment glow and make the beginner really think that their contribution is valued and appreciated, no matter how little it is (on DW, we get one-line -- hell, one-character -- patches with about as much frequency as we get the big sweeping patches). Once you get someone used to the feeling of accomplishment, once you provide them with an atmosphere of unalloyed positive safety to make mistakes and ask questions and try things out one by one until something works, they gain the confidence necessary to try the harder stuff, because they know that they won't be judged or shamed if they get something wrong.
It's the shift in conceptualization -- hell, the shift in cultural/project worldview -- necessary to turn flawed or incomplete patches from a detriment to an asset (because they indicate interest in the project and someone who's passionate enough about the end result to spend their time/energy/effort learning things in order to contribute). Using this method, the project maintainer absolutely has to ride herd on everyone involved, because it's fairly common in the OSS world (from what I've seen in my forays, at least) for active contributors to view mistakes with scorn. Project contributors are expected to do things right the first time, because otherwise it just wastes everyone's time.
And it's true that this method of doing things does place an incredible burden on the project maintainers, on the active contributors, and on the people doing code review and commit to mentor and encourage others, or at the very least to tame their worst expressions of annoyance, and that is a time-suck. It's also true that the rate of return on this method is nowhere near 100%, and there will always be instances where your thinly-spread maintainer is going to spend an incredible amount of time and effort on someone only for that someone to disappear without any tangible gain being returned to the project.
This method is more of a "bread cast upon the waters" method, where you have to look, not at the rate of abandonment, but at both the rate of return and the rate of exponential growth: if 50% of the people you mentor at bootstrap turn around and get lured into the project, and those people then turn around and mentor others with another 50% rate of success, and so on and so forth, the maintainer's initial outlay of time and effort will start building up concentric circles of mentorship, where people who have been given a hand up will then turn around and do the same for others, etc. After that initial bootstrap phase, it takes the burden of handling the basics off the maintainer, freeing him/her up for the more complicated technical bits and allowing the basic education to stay in the hands of those who have just recently gone past it themselves. (The other benefit of that is that if it's someone who's just learned teaching someone who's learning, the teacher knows and remembers all of the pitfalls, because they went through it themselves so very recently -- someone with 20 years of experience isn't going to remember all of the things that confused them in their first six months!)
I disagree that being clueless is inherently a form of rudeness -- I disagree vehemently, in fact; rudeness is something culturally defined and not at all concurrent from culture to culture. Cluelessness is a form of rudeness in the most-prevalent open source culture, true -- but I submit to you for consideration the proposition that that very socially-construed definition of rudeness is part of what makes so many OSS projects unwelcoming. There are certainly ways to gently deflect someone with more enthusiasm than experience to the existing newbie documentation for self-education.
It really doesn't take that much more time to type out something like "That's a great idea, and not something that I'd ever thought of before. I'm overbooked right now in terms of tasks that I personally need to get done for the next release, so I won't be able to get to that myself, but if you want to put together a patch, I'd eagerly accept it. (I don't know your experience, so if you need some suggestions on how to get started, check out $newbie_documentation_url for some pointers.)" than it does to type "agreed; can you write a patch for that?" (After a while, it just sort of rolls off your fingers without you having to think about it.)
The former acts to a). validate the person's suggestion, which to them is of course going to be the most imporant thing in the universe; b). provide the person information about why you aren't immediately leaping to implement it, because of course they feel you should see the light of their genius and drop everything to go do it; c). let them know that you aren't just blowing them off, that you do want to work with that person to improve the product; d). provide pointers to implementation information that makes no assumption about the experience level, or lack thereof, of the questioner. (Thus neatly avoiding both the "I've been doing this for twenty years, how dare you assume I don't know what I'm doing" reaction and the "I've never done this before, how dare you assume everyone is as experienced as you are?" reaction.) The latter operates from a number of different assumptions that might have been true in the infancy of the OSS culture (that everyone reading has a certain skill/ability/interest level) but aren't as true now.
Existing OSS culture, in my experience, is predicated around newcomers already understanding existing OSS culture, and reacts swiftly and violently to those who don't. It's also -- and I think this is a little harder to spot, especially for the people who suffer from it -- a culture where the focus is placed on the individual, not on the project: where most projects are centered around the maintainer, not the end result. These two things combine to create a culture where innocent mistakes made out of desire to improve the project are shot down with a vehemence totally out of proportion to the weight of the error, and leave people smarting (and way more likely to say "fuck you, I don't need this kind of crap in my spare time").
You say "the real task in hand [...] is to develop and maintain useful software", which is absolutely true, but which also carries an unexamined assumption: who defines 'useful'? Obviously, the answer to that is going to be different for each project, depending on what the projected use case is, but I've seen a lot of projects where the implicit answer to that is "the maintainer", not "the people who are using it". There's always going to be an element of that in any project, since the maintainer is God for all intents and purposes, with the final say about what goes in and what direction the project is going to be taking, but I think there are ways for a maintainer to keep that leadership role and shepherd the project without conforming to a very narrow personal vision and interpretation of what the software should be. I know that with DW, there are tons of people working on things that Mark and I never imagined that people would want, but which they get incredibly passionate about -- so we let them go for it, and take the end results gladly! That makes the end-result software more broadly usable and useful.
(This is, of course, only applicable to really broad applications. For smaller projects, a narrower focus is far more appropriate.)
I dunno, I'm just sort of noodling around these really big and amorphous concepts, trying to analyze why we've been so successful in recruiting such a broad base of contributors and how those lessons can be abstracted to fit the OSS community as a whole. I've been passionate about OSS use and OSS advocacy for over a decade, but I've never found a project where I felt that my contributions would be welcomed. I've been trying lately to put my finger on why, and why DW would feel different even if I weren't half-owner, so as to be able to articulate it for others. So much of our work with DW has been to actively oppose the unwelcoming cultural practices we've both seen over the years (such as the ones that killed LiveJournal's open source contributor culture), while retaining and strengthening the cultural practices that let LiveJournal's other volunteer cultures thrive and develop.
Thanks for the thoughts, and for letting me poke at some more of my ideas in response to yours. :)