Don't use the mailing lists

I think "mean" maintainers in open source are also often a result of burnout, and if he's been working on it for 25 years, perhaps it's time for him to take a break.

This just made me think, if the maintainer is just part of a process - maybe compilers should be more polite, too.

"Syntax error at line 57" sounds very harsh. Why can't the compiler say "dear developer, it shames me to point it out but you might have slipped in a typo on line 57. Your continued effort in straightening it out would be much appreciated" I would be much more motivated to continue debugging.

What I am getting at, maybe the maintainer sees his role more technical than social. He considers his job to maintain the code base, not the user base. I actually think that's OK, and submitters shouldn't take a brief response personal.

I'd be at the very least nonplussed if an error caused a compiler to say "do your own homework" or the like. There's technical and succinct, and there's unnecessarily rude; that's pretty clearly to one side.

It could be a solution but that already kind of exists (with forums/IRC etc).

However, these "gatekeepers" can be just as unhelpful.

I have been studying this behavior for some time - and it's very interesting. I have found that C++ communities to contain members that talk down to new members, yet in Assembly language communities (which is arguably a harder more advanced language than C++) I have seen members offer extremely helpful advice and even sample code.

Sometimes though people can be too friendly - in some communities people post something they are working on (which is basically a copy/paste from the sample code provided by the language/library) and the other members are like "THAT IS AWESOME".

I'm not saying library/language/framework developers have to remote into people's computers and hold their hands - but at least try to show some professionalism and respect. Instead of replying with "this has been asked a 1000 times - please use the search" and close/lock the thread, reply with "Have you seen these other threads? They may contain what you are looking for - otherwise let me know". The later will go a lot further in encouraging new members to join and current members to stay. To me, in my opinion, the first indicates a lack of knowledge and/or maturity on your part.

From what I hear, the subversion guys are always polite and have used this to battle off trolls. Be immature as the trolls and you are just feeding the trolls...and the sign is clearly posted "Don't feed the trolls".

This is probably a hard post to evaluate from the outside: is he right, or just overly sensitive? Earlier I would have been skeptical, but I've recently started on a project in R, and based on my experience so far I think he's mostly right: there are some real problems with R development. But I'd put less emphasis on individual "bad apples", and more on a culture that is dealing poorly with the approach of "development in the open". I think this recent exchange on the list illustrates nicely: http://r.789695.n4.nabble.com/PATCH-Makefile-add-support-for...

The R source repository is in Subversion. A new contributor offers a very small patch to allow source downloaded from a git mirror to compile correctly. The response (not from Ripley) is "I think we are unlikely to accept this change. Nobody in R Core uses git this way, so it would never be tested, and would likely soon fail." A reasonable position in some cases, but seems odd for a two line patch a Makefile that opens development to new contributors. Even stranger, it turns out that the patch is mostly working around a commit from several years ago (by Ripley) to explicitly prevent compilation from git: https://github.com/wch/r-source/commit/4f13e5325dfbcb9fc8f55...

Even stranger, this commit is commented "trap HK Leung misuse", where Han-Tak Leung is an earlier mailing list participant who had problems compiling as a result of using the "git-svn" compatibility layer. The thread discussing that earlier issue concluded (not Ripley): "The generic point is that you are given access to a working tool that is internal to the core R developers. We are not putting restrictions on what you do with that access, but if you want to play the game by other rules than we do, you need to take the consequences. If things don't work and you start complaining about them being "broken", steps may be taken to make it clearer who broke them."

Considering the source repository and ability to submit patches as "access to a working tool that is internal to the core R developers" strikes me as a short-sighted approach. Spiking your source to refuse to compile if not checked out directly from svn seems like a bad strategy. Explaining the purpose as to "trap misuse" by an individual might be pathological. It makes me pessimistic about R's future.