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.
Because they're already the senior. CEO said it shouldn't be that hard, and besides, they only wanted to pay $40K/yr.
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.
My advice to mentees is that if installing a package to achieve x saves (a significant amount of) time/money that outweighs the risks to self/company or has value added by means of product maturity or domain expertise, then by all means do not roll your own crypto, web framework, db connector or machine learning library. But if one is going to introduce dependencies on things as trivial as leftpad or someone's Show HN single-pass weekend hackathon proof-of-concept, they will soon learn why we don't bring toys to work.
Or did you forget the /s...
Yep. It's been a long day after a particularly long week. I will take a break from HN, too much on my mind. Thanks for the reminder.
Nobody else but you alone can ensure that your project is managed and developed properly.
But I get where you're coming from. It's even worse on Steam, where developers will actually collect money during the "early access" phase and then walk away once a (closed-source) tech demo is half-complete.
I’m not saying anyone should be obligated to do free work. This issue is that most people don’t feel comfortable publishing a public fork without the blessing of the creator, or at least knowing the creator no longer intends to work on the project in the near future. So you end up with these situations where there are thousands of people running production systems with unmerged security patches because the creator can’t be bothered to spend 30 seconds to write a one sentence reply to an email.
Short of being in a coma, I consider that toxic behavior.
And just to be clear I’m taking about situations where there are lots of open PRs but no signs of life for months or years on end, not situations where the creator just went on vacation for a few weeks.
no one promised you anything. you merged some code into your project. now deal with the consequences. be responsible for your work.
I dont want to know, how much of core infrastructure is resting on the shoulder of overworked and burned out BDFL. This isnt a ego complex in most cases, but the knowledge that without someone with their commitment working at the project it will crumble.
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.