6 ms·
Correct, maintainers can say that and get shamed. And it leads to unmaintained libraries, since companies don't want to pay. At some point, is open sourcing y
by securesaml 8mo ago
Correct, maintainers can say that and get shamed.
And it leads to unmaintained libraries, since companies don't want to pay.
At some point, is open sourcing your work a liability?
- pythonaut_16 8mo agoAre there honestly examples of maintainers being shamed for that?
- carllerche 8mo agoHelp normalize saying no? As an OSS maintainer, the sense of entitlement many have is quite frustrating. After years in OSS, I have built up a thick skin and am fine saying no, but many aren't.
- edwinjm 8mo agoI’m sure many companies like to pay. It’s probably the cheapest way to solve a business problem. It should be the norm. If a company wants to have a bug fixed or a feature added, they should pay. And GitHub should make it easy to do so.
- bigstrat2003 8mo ago> Correct, maintainers can say that and get shamed. And then they can shrug and move on with their respective days. If I open source something it's a gift to the commons, not a promise to work on it for free in perpetuity. I don't really care if someone tries to shame me for that, as there's nothing to be ashamed of.
- bloppe 8mo agoI always chuckle at indignant GH comments on OSS projects. There should be a subreddit dedicated to them. Like a specific kind of r/choosingbeggars
- ImPostingOnHN 8mo agoIf you look at the issue list for any significant open source project, it's probably of nonzero size. That's a way of saying "no": just don't do it. Maybe you're overloaded, maybe you just don't feel like it. It's totally normal, and different projects have different levels of resources, some with none anymore.
- securesaml 8mo agoI have seen small utility libraries like tj-actions get compromised because there aren't any security specialists looking at the library. My main concern is supply chain compromise.
- ImPostingOnHN 8mo agoUnless you're talking about a different event, tj-actions wasn't "compromised because there aren't any security specialists looking at the library". Instead, an API key was used, maybe by the author, maybe by someone else, to replace good code with bad code, including modifying historical release tags to point to the bad code. That said, everything in my previous post still applies: a nonzero buglist is totally normal and widely accepted.
- securesaml 8mo agoI'm not too sure about the root cause about tj-actions. IIRC there are some libraries that compromised by actions injections vulnerabilities, where a security specialist could have helped.
- kevinrineer 8mo ago> At some point, is open sourcing your work a liability? I argue that open sourcing your work is no more liable than making a comment on social media. The biggest risk to an open source maintainer is publicly losing their patience and/or being heterodox in their beliefs. Code isn't a requirement for that to happen.