←back to thread

2024 points randlet | 1 comments | | HN request time: 0.428s | source
Show context
bla2 ◴[] No.17515883[source]
> 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): >>17515955 #>>17515972 #>>17516193 #>>17516427 #>>17516776 #>>17516884 #>>17517282 #>>17517716 #>>17517821 #
sjm-lbm ◴[] No.17515955[source]
It's PHP and not Python, but every time I read something like this from a major open source figure, I always think of this old PHP mailing list thread:

https://bugs.php.net/bug.php?id=50696

replies(8): >>17516108 #>>17516130 #>>17516216 #>>17516240 #>>17516461 #>>17516708 #>>17516836 #>>17517666 #
Y_Y ◴[] No.17516108[source]
That's a good read. I feel like the "customer is always right" mentality does quite a bit of harm to OSS support.

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.

replies(6): >>17516199 #>>17516206 #>>17516230 #>>17516371 #>>17516964 #>>17517308 #
Alex3917 ◴[] No.17516964[source]
> "customer is always right" mentality does quite a bit of harm to OSS support.

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.

replies(2): >>17517068 #>>17517252 #
jstarfish ◴[] No.17517068[source]
Not using toy libraries for production systems is a lesson every young developer learns early on in their career.
replies(3): >>17517183 #>>17517245 #>>17517678 #
jacquesm ◴[] No.17517183[source]
Fortunately every young developer is also schooled extensively in telling toy libraries apart from serious ones.
replies(3): >>17517708 #>>17517858 #>>17519660 #
1. jstarfish ◴[] No.17519660[source]
By definition, they aren't though-- for the truly green, that extensive schooling comes from `npm/pip/gem install`ing random packages with implementations they don't understand or can't account for, then having to deal with the fallout in whatever form it chooses to manifest itself. Could be a maintainability nightmare, or it could be losing your job.

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.