I don’t know why, but there are a few projects I’ve tried contributing to that are just extremely tiresome to get running and when a PR comes in to improve it, they pick it to death or outright reject it. “Works on my machine”, “I don’t like $technology”, “We already use gitpod, this is unnecessary”, etc. have made me unwilling to invest time in projects that look difficult to setup.
“Just run ./configure && make && make install”. Has not worked for me. Not even once.
Thanks to AUR, I haven’t manually run a autoconf build in years, but I remember them being very fiddly. Lots of “google for header file, install and retry”.
I think maintainer burn-out somewhat contributes to the hostile approach some projects have, anything that is accepted into a project needs to be maintained and comes with a risk of being broken in the future. If the original committer isnt around, then the maintainers either have to take on that burden, or remove it.
Its a tough cycle to break, I don’t know what the answer is.
I don’t know why, but there are a few projects I’ve tried contributing to that are just extremely tiresome to get running and when a PR comes in to improve it, they pick it to death or outright reject it. “Works on my machine”, “I don’t like $technology”, “We already use gitpod, this is unnecessary”, etc. have made me unwilling to invest time in projects that look difficult to setup.
“Just run
./configure && make && make install”. Has not worked for me. Not even once.Anti Commercial-AI license
Thanks to AUR, I haven’t manually run a autoconf build in years, but I remember them being very fiddly. Lots of “google for header file, install and retry”.
I think maintainer burn-out somewhat contributes to the hostile approach some projects have, anything that is accepted into a project needs to be maintained and comes with a risk of being broken in the future. If the original committer isnt around, then the maintainers either have to take on that burden, or remove it.
Its a tough cycle to break, I don’t know what the answer is.