3 ms·

Regardless of whether it's a project run by a big company or a guy in a shed, a security-critical project not fixing critical vulns for 10 months is an importan

Regardless of whether it's a project run by a big company or a guy in a shed, a security-critical project not fixing critical vulns for 10 months is an important bit of information when judging whether you should use it. It doesn't really matter whether it's someone's fault, or wrong, or whatever - what matters for the user is that using the project is likely unsafe. Sharing that information is a public service.

hinkley 2y ago
The number of software engineers who either don’t understand social contracts or only understand them when it benefits them to do so is frankly appalling. You said you’re going to do something and now people depend on you having done it. Volunteer organizations fall apart if they can’t trust each other.
- from-nibly 2y ago
  People depending on you is not somethng in your control, therefore you can't be responsible for that. It's up to the people depending on you to make a judgement on whether or not that's a good idea. Social contracts are not contracts, they do not end up in court, and if you depend on them you have no recourse. The most anyone can say about social contracts is that you are allowed to be disappointed privately. And even then...
  - hinkley 2y ago
    No, they end up in the court of public opinion. <gestures around> And they make you lonely if you keep losing.
- water-data-dude 2y ago
  This blog post is from another domain, writing, but it’s stuck with me over the years and colored how I see things like open source projects: https://journal.neilgaiman.com/2009/05/entitlement-issues.html https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
nijave 2y ago
>a guy in a shed That should be enough without needing to shame them over timeline. You can also judge based off issue open/close rate and contribution frequency (GitHub has pretty charts for these if the project is hosted there)

hinkley 2y ago

The number of software engineers who either don’t understand social contracts or only understand them when it benefits them to do so is frankly appalling. You said you’re going to do something and now people depend on you having done it. Volunteer organizations fall apart if they can’t trust each other.

from-nibly 2y ago
People depending on you is not somethng in your control, therefore you can't be responsible for that. It's up to the people depending on you to make a judgement on whether or not that's a good idea. Social contracts are not contracts, they do not end up in court, and if you depend on them you have no recourse. The most anyone can say about social contracts is that you are allowed to be disappointed privately. And even then...
- hinkley 2y ago
  No, they end up in the court of public opinion. <gestures around> And they make you lonely if you keep losing.
water-data-dude 2y ago
This blog post is from another domain, writing, but it’s stuck with me over the years and colored how I see things like open source projects: https://journal.neilgaiman.com/2009/05/entitlement-issues.html https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...

nijave 2y ago

>a guy in a shed That should be enough without needing to shame them over timeline. You can also judge based off issue open/close rate and contribution frequency (GitHub has pretty charts for these if the project is hosted there)