I don't think that's true. I've long worked with software both proprietary and not, and I find myself digging deep all the time. I shouldn't have to reverse engineer my dependencies to find out why they're broken. When I do figure it out, I should be able to send a patch so everyone benefits. Without these basic things in place, I simply cannot get work done.
The other advantages are not really important. If an open source offering is lacking something, I can just add it myself. If the proprietary version is lacking something, I cannot.
And what if what you're doing is just a quick, one month project? Is it likely you must absolutely dig into the sources then? I would say no. The fact is, your original comment completely fails to address or take into account the context of the individual project. You think you're being reasonable, and of course there are great advantages to open source. I too would prefer this library to be. But the dogmatism and fanaticism is not just offensive to the author who claims elsewhere in the thread that he spent 4 years on this, it's also irrational and leads to suboptimal results.
>And what if what you're doing is just a quick, one month project? Is it likely you must absolutely dig into the sources then? I would say no.
You would be surprised. I can't even count on one hand the number of times I've send a patch upstream within the first 2 hours of using a new dependency.
I don't really care how long he spent on it. It was a waste of 4 years if it's just going to be proprietary.
The other advantages are not really important. If an open source offering is lacking something, I can just add it myself. If the proprietary version is lacking something, I cannot.