> I don't ever want to have to fight so hard for a
PEP and find that so many people despise my decisions.
Leading a large open source project must be terrible in this age of constant outrage :-(
replies(9):
Leading a large open source project must be terrible in this age of constant outrage :-(
Also reminds me of that dev (who I can't seem to search up) who had their email printed as part of a open-source software license in a car manual and would get ridiculous email from people who had car trouble.
It goes both ways. All too often people promote their new library on HN and Reddit, wait until a bunch of people are using it as a dependency, and then abandon it without even telling anyone whether or not it’s abandoned.
Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project?
If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example?
A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO.
Some critical assumptions:
- a more senior dev is available
- has time
- understand the system well enough to judge the impact
- is actually a better developer than the junior (in spite of being older / in the game longer)
> Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project?
It isn't, that was the point.
> If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example?
Some critical assumptions:
- organizations keep a close eye on developers incorporating code under various licenses
- the people keeping an eye on that are qualified to make the calls
- the resources to keep an eye on this are available
> A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO.
Sure. But that doesn't mean these things don't happen just about everywhere, many times per day.
It is rare to find a company where all of the assumptions labelled above are true all the time. And that's where the problem lies.
It's a clear case of there being no difference between theory and practice in theory but in practice there is, and rather a lot of it. Everybody knows in theory how software should be developed, but in practice hardly anybody actually does it that way. They're either out of time, options or qualifications (or all three) and they will do the job anyway.
That doesn't excuse it, but it does help you to understand it.