Kind of, in this case its a vulnerability in a portion of code that you need to compile with special flags to even include in the library (ie its not in the default build, you need to rebuild it and opt-in) so its super low impact and just ends up giving the maintainers excessive paperwork.
Again, ignoring/postponing is an option.
At work, we’d just move that to the backlog of shit we may never touch: having it there is good for tracking the issue & gathering notes on our thoughts regarding it, which saves time approaching it like new each time it comes up.
It’s no different for open source maintainers.
Marking an item as won’t fix, deferred, or help wanted or closing redundant items isn’t much paperwork.
Again, the objective reality is the defect exists, and that reality doesn’t change with our awareness of that fact: it’s better to know & track for planning even if the plan is to do nothing.
An issue I’ve seen brought up in the open source community is that they have audits that look at the number of untriaged issues and time to resolve serious issues that their funding depends on.
I’m in software, but not open source, so it seems like they don’t have someone aligned with their team who they can sit down and say “either we need more resources, cut scope for new features, or accept quality / security issues coming up” to, its kind of this weird game of politics they end up needing to play to get any kind of funding for full time maintainers.
That’s the main reason they can’t just ignore issues that come up in their backlog, especially security ones.
That’s an unnecessary issue regarding someone’s income, which some projects don’t even have.
its kind of this weird game of politics they end up needing to play
They don’t need to.
It’s a supply & demand issue: if a maintainer finds the terms unacceptable and goes “fuck you, pay us right, lower your expectations, or piss off” then what is the funder going to do?
Let the software rot?
They either want the software or they don’t, and it’s not going to be cheaper to develop that software in a non-open setting.
They’ll have to reconcile terms or find another maintainer who’ll work for less in a market where their skills are highly valued.
Objective facts of reality are unrelated to the reasonability of business arrangements people work out to address those facts.
This is a negotiation skills issue to address with the business partner, not with immutable, objective reality.
It’s a free world: anyone is free to express truths about security defects at any time, and no one owes anyone anything on the timing of those disclosures.
Kind of, in this case its a vulnerability in a portion of code that you need to compile with special flags to even include in the library (ie its not in the default build, you need to rebuild it and opt-in) so its super low impact and just ends up giving the maintainers excessive paperwork.
Again, ignoring/postponing is an option. At work, we’d just move that to the backlog of shit we may never touch: having it there is good for tracking the issue & gathering notes on our thoughts regarding it, which saves time approaching it like new each time it comes up. It’s no different for open source maintainers. Marking an item as won’t fix, deferred, or help wanted or closing redundant items isn’t much paperwork.
Again, the objective reality is the defect exists, and that reality doesn’t change with our awareness of that fact: it’s better to know & track for planning even if the plan is to do nothing.
An issue I’ve seen brought up in the open source community is that they have audits that look at the number of untriaged issues and time to resolve serious issues that their funding depends on.
I’m in software, but not open source, so it seems like they don’t have someone aligned with their team who they can sit down and say “either we need more resources, cut scope for new features, or accept quality / security issues coming up” to, its kind of this weird game of politics they end up needing to play to get any kind of funding for full time maintainers.
That’s the main reason they can’t just ignore issues that come up in their backlog, especially security ones.
That’s an unnecessary issue regarding someone’s income, which some projects don’t even have.
They don’t need to. It’s a supply & demand issue: if a maintainer finds the terms unacceptable and goes “fuck you, pay us right, lower your expectations, or piss off” then what is the funder going to do? Let the software rot? They either want the software or they don’t, and it’s not going to be cheaper to develop that software in a non-open setting. They’ll have to reconcile terms or find another maintainer who’ll work for less in a market where their skills are highly valued.
Objective facts of reality are unrelated to the reasonability of business arrangements people work out to address those facts. This is a negotiation skills issue to address with the business partner, not with immutable, objective reality.
It’s a free world: anyone is free to express truths about security defects at any time, and no one owes anyone anything on the timing of those disclosures.