4 ms·
> Johnson closed the project to contributions in January 2021, explaining in a section of the README titled "Open-Source, not Open-Contribution" that dealing wi
by cxr 3y ago
> Johnson closed the project to contributions in January 2021, explaining in a section of the README titled "Open-Source, not Open-Contribution" that dealing with even small code contributions was too time-consuming.
> "As the author of BoltDB, I found that accepting and maintaining third-party patches contributed to my burn out and eventual archival of the project," he wrote. "Even small contributions typically required hours of my time to properly test and validate them[...]"
I'm weirded out when I realize that I've run into someone where this needs to be explained.* The amount of ostensible "engineering" folks who are evidently afflicted with time-cost blindness or can't seem to grapple with the ideas behind basic comparative analyses of reward versus investment is staggeringly high.
* and, of course, this compounds the problem, because the explanation takes time, too...
- Plasmoid 3y agoHashicorp and Terraform are pretty notorious about rejecting/ignoring all community PRs. I once saw Hashicorp say that someone was allowed to come up with a proposal for a proposal for improvement, and that might get read but a real change would not even be considered.
- FartyMcFarter 3y agoComplex projects need to have extensive tests if they are to accept contributions from everyone. I don't mean just unit tests - also extensive integration tests run with sanitizers and static analyzers as well. Without this kind of tests, you accept a significant probability of frequent bugs popping up (especially if you allow contributions from people unfamiliar with the code). It's perfectly fine for authors to decide they don't want to follow this route and simply disallow most contributions (instead of investing into the test infrastructure required to enable them).
- johannes1234321 3y agoIt's not about testing only. All future features have to be vetted against the design decisions made in those contributions. Maybe the primary maintainer, after accepting a contribution, has to mind consistency with a feature, they now have to make Tain they don't care about from the start and is in the way for a feature they'd like. Taking contributions has long-term cost.
- cxr 3y agoI don't understand how this is supposed to be a response to what I wrote.
- FartyMcFarter 3y agoI was agreeing with you and expanding on what you said about reward vs investment.
- josephg 3y agoYep. I have a strict policy of requiring unit tests to be added before I merge any new feature in a pull request. For small features, all the contributor needs to do is add a couple of test functions to the existing testing infrastructure, but I find it still drops the number of PRs by about 5x or something. It’s really remarkable. And I haven’t found a downside to this policy yet.
- MoreQARespect 3y agoI have this too, but with a specification-by-example integration test with a brief explanation that autogenerates readable "step by step" markdown how-to docs. The idea being that new features should be fully tested and clearly documented before being merged - ideally with a minimum of overhead. Because if you defer either, it likely won't get done.
- jmathai 3y agoAt some size, a project grows beyond the scope of what one person can do. Until then it’s possible that taking contributions is more work that the author doing it themselves. In any case, extensive test coverage is a the only way I think you can take contributions for even a medium size project. I have a o(10k) loc project that takes contributions. The contributions are more for community building than anything else. I evaluate pull requests based on code quality and if the tests pass - I don’t ever manually test it. It’s a lot of work to do even just that when the project falls off my priority list.
- nlypra 3y agoProjects that have the currently fashionable dogma that every contribution counts and must be considered degrade and lose the best contributors. Either they are directly run by corporations, in which case they are just designed to "grow the team", or they are taken over by politicians who work for corporations and want to establish themselves as ruthless managers. CPython falls in the latter category, which is why useless things keep being added and bugs creep in.
- matheusmoreira 3y agoI don't think people "need" this to be explained to them. By now we have had decades of "show us the code" and "pull requests welcomed" responses from free and open source software maintainers. Now that people are sending code, it's somehow detrimental to their mental health? I respect their sincerity at least. It's better to know up front when the maintainer isn't actually interested in engaging with you. Nothing's worse than sending a patch in and not even getting a response.