I would love to contribute but I don’t have the experience for a fork. This is kind of the essence of the whole problem though. Plenty of unutilized contributors who could be driving this project forward but are having a hard time getting involved.
This sort of thing happens in every opensource project; the maintainer(s) have a vision for the product and whatever amount of time they can use to review contributions and PRs. Some PRs are utter messes, some are good but complex, others are good but either are not going to be supportable with the current manpower or will be superceded by codebase changes in the future. And then these contributors get upset their PRs aren’t being taken seriously. They as well are welcome to fork it and they could even use patches from the original branch as they develop their forks, and presumably implement them in production. But more often than not, they just move on because they don’t have much invested.
It’s every maintainers balance that has to be determined, and not everyone is going to be happy. They might want a slow development pace because fast paces require a lot of work to maintain. Simplistically saying “we need faster development to take advantage of surges in interest” is pointless if there’s nobody that’s willing to stand behind the extra QC and support those patches introduce. Drive-by patching is a huge issue because the contributors rarely stick around to fix bugs.
spaduf@slrpnk.net 1 year ago
I would love to contribute but I don’t have the experience for a fork. This is kind of the essence of the whole problem though. Plenty of unutilized contributors who could be driving this project forward but are having a hard time getting involved.
ikidd@lemmy.world 1 year ago
This sort of thing happens in every opensource project; the maintainer(s) have a vision for the product and whatever amount of time they can use to review contributions and PRs. Some PRs are utter messes, some are good but complex, others are good but either are not going to be supportable with the current manpower or will be superceded by codebase changes in the future. And then these contributors get upset their PRs aren’t being taken seriously. They as well are welcome to fork it and they could even use patches from the original branch as they develop their forks, and presumably implement them in production. But more often than not, they just move on because they don’t have much invested.
It’s every maintainers balance that has to be determined, and not everyone is going to be happy. They might want a slow development pace because fast paces require a lot of work to maintain. Simplistically saying “we need faster development to take advantage of surges in interest” is pointless if there’s nobody that’s willing to stand behind the extra QC and support those patches introduce. Drive-by patching is a huge issue because the contributors rarely stick around to fix bugs.