43 ms·

"Contribute or shut up" seems to be a common response. My experience, not extensive mind you, is mixed on the matter. The people who make the communication pos

by talmand 11y ago

"Contribute or shut up" seems to be a common response. My experience, not extensive mind you, is mixed on the matter. The people who make the communication positive gets my attention, even if they so no. Otherwise, I'll still possibly use the project as needed but I don't feel the need to contribute even if I could.

agibsonccc 11y ago
I think it depends on the project. I get a ton of feature requests that are off the beaten trail. I basically give people the feed back of: We have limited bandwidth, but I'm happy to point you in the right direction. "Contribute or shut up" worded differently may not be an ideal answer but it's an understandable one. Imagine if you were a resource constrained engineer having hundreds of queries and emails a day about certain things users want and then not only have that feature not be something of interest to anyone but that user but also have it be something that isn't even on your road map. Technology that's general purpose enough (in our case machin e learning/scientific computing) will give you this. There's a huge delta between say: a resource constrained but heavily used project and a javascript lib that only provides a slightly better basic widget. It's no excuse for OSS devs to be rude but I hope you can understand what it looks like from our side a bit.
technomancy 11y ago
My experience is that often even when the user comes with a suggestion backed up with a patch, it can be rejected because either they didn't understand how it interacts with other features in the codebase, or the maintenance burden would be too high for too little gain. Essentially even when you're asking to contribute a patch, you're requesting that someone maintain some code you wrote for an indefinite span of time. My experience has been that it's much more productive to say "I can't merge that patch into the core, but here is how it would be implemented as a plugin" and ensure your plugin interface is powerful and stable enough to allow people to do what they want.

by talmand 11y ago

agibsonccc 11y ago

I think it depends on the project. I get a ton of feature requests that are off the beaten trail. I basically give people the feed back of: We have limited bandwidth, but I'm happy to point you in the right direction. "Contribute or shut up" worded differently may not be an ideal answer but it's an understandable one. Imagine if you were a resource constrained engineer having hundreds of queries and emails a day about certain things users want and then not only have that feature not be something of interest to anyone but that user but also have it be something that isn't even on your road map. Technology that's general purpose enough (in our case machin e learning/scientific computing) will give you this. There's a huge delta between say: a resource constrained but heavily used project and a javascript lib that only provides a slightly better basic widget. It's no excuse for OSS devs to be rude but I hope you can understand what it looks like from our side a bit.

technomancy 11y ago

My experience is that often even when the user comes with a suggestion backed up with a patch, it can be rejected because either they didn't understand how it interacts with other features in the codebase, or the maintenance burden would be too high for too little gain. Essentially even when you're asking to contribute a patch, you're requesting that someone maintain some code you wrote for an indefinite span of time. My experience has been that it's much more productive to say "I can't merge that patch into the core, but here is how it would be implemented as a plugin" and ensure your plugin interface is powerful and stable enough to allow people to do what they want.