Hacker News new | past | comments | ask | show | jobs | submit login

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.




>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)


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.


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...


No, they end up in the court of public opinion. <gestures around>

And they make you lonely if you keep losing.


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.ht...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: