| ▲ | Dilettante_ 5 hours ago |
| >it is not okay to consider that this labor fell from the sky and is a gift, and that the people/person behind are just doing it for their own enjoyments Yes it absolutely is. That is the exact social contract people 100% willingly enter by releasing something as Free and Open Source. They do give it as a gift, in exchange for maybe the tiny bit of niche recognition that comes with it, and often times out of simple generosity. Is that really so incredible? |
|
| ▲ | securesaml 5 hours ago | parent | next [-] |
| The problem is more so maintenance. The expectation of FOSS is that the users and maintainer work together to resolve bug fixes/features/security issues. However many companies will dump these issues to the maintainer and take it for granted when they are resolved. It's not a sustainable model, and will lead to burnout/unmaintained libraries. If the companies don't have the engineering resources/specialization to complete bug fixes/features, they should sponsor the maintainers. |
| |
| ▲ | strongpigeon 5 hours ago | parent [-] | | It’s OK to say “No” or “Pay me and I’ll do it right now” to companies doing this. | | |
| ▲ | carllerche 4 hours ago | parent | next [-] | | I 100% agree with this. It also is 100% OK to fork aggressively and patch yourself. | |
| ▲ | Dilettante_ 5 hours ago | parent | prev | next [-] | | (And on the flipside, nothing is owed for a bugfix the maintainer made out of their own free will. Again, a gift.) | | |
| ▲ | securesaml 4 hours ago | parent [-] | | The problem is lots of open source is unmaintained/insecure, and there aren't any security engineers on those open source libraries. For the library to be secure, there needs to be funding, not by magic and expecting maintainers will do stuff on there free will. | | |
| ▲ | overfeed an hour ago | parent [-] | | The person needing a feature can do implement it themselves or pay for it. They may even share it, in the spirit of open source, but they probably don't have to (depending on license conditions). |
|
| |
| ▲ | securesaml 4 hours ago | parent | prev [-] | | 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? | | |
| ▲ | carllerche 4 hours ago | parent | next [-] | | Help 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 3 hours ago | parent | prev | next [-] | | I’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 3 hours ago | parent | prev | next [-] | | > 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. | |
| ▲ | ImPostingOnHN 3 hours ago | parent | prev [-] | | If 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 3 hours ago | parent [-] | | I 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 2 hours ago | parent [-] | | Unless 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 2 hours ago | parent [-] | | I'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. |
|
|
|
|
|
|
|
| ▲ | Aurornis 5 hours ago | parent | prev | next [-] |
| Agreed. Supporting open source maintainers is a great idea in general, but shaming people for using something according to the exact license terms it was released with is getting old. |
|
| ▲ | nonethewiser 5 hours ago | parent | prev | next [-] |
| It's crazy to expect someone to pay for something that you're giving them for free. |
| |
| ▲ | patmorgan23 4 hours ago | parent [-] | | Correct, but if there's a bug/enhancement/support they want, it's perfectly reasonable to ask for compensation for it. |
|
|
| ▲ | tehjoker 2 hours ago | parent | prev [-] |
| A natural solution for this kind of problem would be either a private or public grants program. Critical infrastructure built by random uncompensated people... ideally there would be some process for evaluating what is critical and compensating that person for continued maintenance. |