This commentary is exactly the problematic commentary the authors were referring to in the quote that David included near the top of his article. You may not be being so directly brash about their state, but you still imply with added dramatic extension that the project is in some dire state. That's likely a significant overreaction. There's a feature in the project that leads to a security concern, making it fixable likely took a small number of hours, communicating and dealing with the drama is what has and would continue to take the time, as well as pushing back on a plethora of demands for "full review" or "you must travel outside of your home country so I feel comfortable again".
I poked some fun at the issue, because this is in many ways an amusing issue - a feature that would rarely be added in more recent times, but at the time it was introduced we as an industry considered the whole space differently. I'm sure the maintainers are having a tough time, and theres no need to point fingers at them, hell there's no need to point fingers at the implementor of the feature. It's a mistake in retrospect but that doesn't make anyone unworthy of respect.
The actions you identified make a lot of assumptions, some are exclusionary, some are potentially offensive:
- not everyone lives in the same country
- not everyone can travel on a whim
- the developers don't need to be close to you or their customers unless they want to be.
- the project is not in some dire state in need of "saving"
As an Apache project there is a foundation that can help organize funding, and so if there's a funding problem with the project the discussion should start there. Yes, open source at large is underfunded, but this isn't a standalone project on a personal git host. Apache has some (probably not enough) funding, but most importantly it has the industry contacts and relationships to do better here.
There's a problem with "doing better" though, which I rarely see come up in these conversations. There are lots of libraries, such as log4j, that don't necessarily need full time staff or full time funding. They need spurts of funding at key times, to handle the trickle of regular but infrequent patches, to roll releases periodically, and occasionally such as this to dedicate some significant time to handling an exceptionally rare event. What this requires, in my opinion, more than arbitrary dollars, is a slush fund of professional time sponsorship, for employers of key contributors to be ready to make space available during work hours for this work, without adding any more pressure to the situation. Depending on the situation this may or may not require additional funding, but for a healthy ecosystem finding ways to arrange for this, and helping employers be comfortable with it is the step necessary to address the wide scale problem of small to mid size projects burning people's personal time in unplanned ways.