Comment by radarsat1
7 years ago
As a maintainer I've also had weird situations come up where someone suggests something perfectly good, and even includes code with an implementation, maybe even something they've spent significant time on, but even though it's a good idea and potential contribution, it just doesn't "fit" with the idea we're going for.. it's actually hard to say no to people for reasons like, "Your code is good but we don't want it because that's not the right interface according to the use case our software is designed for." Clearly the code is good for the person proposing it, and I can't even reject with the excuse that it's bad code in any way, all I can say is, that's not what we want to do right now. It's kind of heartbreaking to reject things on that basis.
I've even found myself having to reject contributions purely for the reason of, "your code is good but it's too much.. I don't want to maintain that."
Believe me it sucks to reject a significant contribution, but the fact is that what often happens from experience, is that someone scratches their own itch, submits a huge patch, and then walks away once it is accepted. And then it does indeed become my job to maintain a bunch of code that I didn't write and aren't familiar with.
So I find that these silly practical issues crop up a lot that have nothing to do with code quality per se, but more to do with being pragmatic about maintenance and the goals for a given code base. It's hard to know how to give the right answer, socially speaking, and I think I have definitely come off as snarky in the past doing so, but it's not intentional. Sometimes acceptance or rejection simply doesn't depend on the code but on other factors that are hard to convey properly on an online forum.
At least the message for contributors is, small one-off fixes are one thing, but if you're going to spend significant time working on something, please discuss it upstream before proposing a huge patch that might not even be something we want to integrate.
That is somewhat unfortunate, but if I take a bit of time to think about it, it seems like a necessary consequence of a successful open source project/movement. Perhaps, in cases like those, you could find a way to split the base project into two or more modules, making it possible to share code with the new fork, but such splitting has non-negligable cost in terms of ossification of internal APIs and maintenance overhead.
Interesting you say so, in one particular project this has become such a problem that I have indeed been thinking along those lines.. of breaking it up into more than one repository so that people can just build their own extensions and I would just maintain a kind of "kernel interface". I do think it's a useful way to go, but it does take some time to redesign with that in mind. It's hard to know when it's "time" to do it, because it's usually only after a project gets to a certain size and has some popularity that it becomes simultaneously difficult to (a) integrate external work and (b) to rewrite the project to make (a) easier. The only answer in some cases seems to be to start a parallel project, but then you're back to the problem of whether this gets any traction in the community, or is seen as "hostile" somehow.