> Have you ever tried to contribute to open source projects?
yes, and it was often painful enough to make me consider very well wether I want to bother contributing. I can only imagine how terrible the experience must be at a core utility such as ls.
> The question was why wouldn't someone writing software not take the route likely to end in rejection/failure
Obviously they wouldn't - in my comment I assumed that the lsr author aimed for providing a better ls for people and tried to offer a perspective with a different definition of what success is.
> I don't like being jerked around by management, especially when I'm doing it for free
I get that. The older OSS projects become, the more they fossilize too - and that makes it more annoying to contribute. But you can try to see it from the maintainers perspective too: They have actual people relying on the program being stable and are often also not paid. Noone is forcing you to contribute to their project, but if you don't want to deal with existing maintainers, you won't have their users enjoying your patchset. Know what you want to achieve and act accordingly, is all I'm trying to say.
That CLA is a curious take, as the old, avowedly non-commercial, GNU foundational tools such as the ones we're talking about like "ls" in coreutils, have always required a kind of strong CLA to be signed from the very beginning, even when they wee new, nimble and fun to contribute to.
Their kind of CLA was designed to uphold community and openness values more strongly than GPL alone, by helping GNU to pursue GPL violators through the law, to fource vendors to release source code when GPL code was shipped in products..
So I've never understood the blanket "don't like regardless of what it says" attitude to CLAs and such.
Surely it should depend on what the CLA says?
Some people object to CLAs that grant upstream less rights than BSD/MIT/Apache licenses grant upstream by defaut. ("No way, the CLA lets them make. a private, commercial fork of my code!"). Yet the same people contribute enthusiastically to BSD/MIT/Apache projects with exactly the same upstream property ("I don't mind that the license let's them make a private, commercial fork of my code!").
yes, and it was often painful enough to make me consider very well wether I want to bother contributing. I can only imagine how terrible the experience must be at a core utility such as ls.
> The question was why wouldn't someone writing software not take the route likely to end in rejection/failure
Obviously they wouldn't - in my comment I assumed that the lsr author aimed for providing a better ls for people and tried to offer a perspective with a different definition of what success is.
> I don't like being jerked around by management, especially when I'm doing it for free
I get that. The older OSS projects become, the more they fossilize too - and that makes it more annoying to contribute. But you can try to see it from the maintainers perspective too: They have actual people relying on the program being stable and are often also not paid. Noone is forcing you to contribute to their project, but if you don't want to deal with existing maintainers, you won't have their users enjoying your patchset. Know what you want to achieve and act accordingly, is all I'm trying to say.