Comment by KPGv2 | Hacker News Reader

Comment by KPGv2 | Hacker News Reader

Parent Full thread

> the value of software appears when it's run, not when it's written

Have you ever tried to contribute to open source projects?

The question was why wouldn't someone writing software not take the route likely to end in rejection/failure. I don't know about you, but if I write software, I am not going to write it for a project whose managers will make it difficult for my PR to be accepted, and that 99% likely it never will be.

I will always contribute to the project likely to appreciate my work and incorporate it.

I'll share an anecdote: I got involved with a project, filed a couple PRs that were accepted (slowly), and then I talked about refactoring something so it could be tested better and wasn't so fragile and tightly coupled to IO. "Sounds great" was the response.

So I did the refactor. Filed a PR and asked for code review. The response was (after a long time waiting) "thanks but no, we don't want this." PR closed. No feedback, nothing.

I don't even use the software anymore. I certainly haven't tried to fix any bugs. I don't like being jerked around by management, especially when I'm doing it for free.

(For the record, I privately forked the code and run my own version that is better because by refactoring and then writing tests, I discovered a number of bugs I couldn't be arsed to file with the original project.)

> 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.

> The older OSS projects become, the more they fossilize too - and that makes it more annoying to contribute.

Newer ones can be just as braindead, if they came out of some commercial entity. CLAs and such.

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!").

Reply on news.ycombinator.com