3 ms·

I have experience on open source projects, and this is the typical open source "limbo" effect. In general, there are different reasons, depending on the projec

I have experience on open source projects, and this is the typical open source "limbo" effect. In general, there are different reasons, depending on the project size, and of course the maintainers' personality. On small projects, time is limited. As a consequence, maintainers need to generally take decisions (about merging) in short times. In this case, unless maintainers are very dedicated to expanding the adoption (of developers), or they have very quick decision skills, minor choices will be postponed, possibly indefinitely. On large (/famous) projects, reasons are different. The context is different; in this other end of the spectrum, there is a flurry of patches, and many low quality ones in absolute quantity. Maintainers, and volunteers, again can put a limited/minimal amount of effort. Since on a large project no change is easy, the limited amount of effort is frequently spent on iterating the patch until it's completed or almost, paradoxically causing it to "disappear in the sea of irrelevance" at the right moment. Or maybe it's completed, but not the way a maintainer has in mind, and he has no intention to spending further effort. Of course, those are just factors; I don't imply that all open source projects have [also] these mechanics, but they are frequent reasons why a patch may not be upstreamed even if it's acceptable.

js2 9y ago
I've contributed to a handful of well-known open-source projects over the years, some more, some less. It has always required quite a bit of effort to land patches. That usually gets easier the longer you're involved in a project and the maintainers see that you care about the project and you have a reputation for working with them to contribute quality improvements. I appreciate that a project can't just allow contributors to "throw code over the fence" as it were. There's a delicate balance between maintaining code quality and not accepting everyone's pet feature, moving the project forward, and not turning contributors away. I think sometimes a bit of friction is a good thing insofar as it requires contributors to have some skin in the game. All that said, this really looks like a minor issue here. That's why this one in particular makes me sad. The effort to land it vs effort to fix it is completely out of whack. There ought to be a simpler process for trivial fixes. Yeah, I know sometimes what seems trivial may be hard to assess or ends up introducing regressions. I'm still shedding a tear.

js2 9y ago

I've contributed to a handful of well-known open-source projects over the years, some more, some less. It has always required quite a bit of effort to land patches. That usually gets easier the longer you're involved in a project and the maintainers see that you care about the project and you have a reputation for working with them to contribute quality improvements. I appreciate that a project can't just allow contributors to "throw code over the fence" as it were. There's a delicate balance between maintaining code quality and not accepting everyone's pet feature, moving the project forward, and not turning contributors away. I think sometimes a bit of friction is a good thing insofar as it requires contributors to have some skin in the game. All that said, this really looks like a minor issue here. That's why this one in particular makes me sad. The effort to land it vs effort to fix it is completely out of whack. There ought to be a simpler process for trivial fixes. Yeah, I know sometimes what seems trivial may be hard to assess or ends up introducing regressions. I'm still shedding a tear.