People are mad that someone created a Go library mocking the (obviously terrible) log4j behavior. How dare you make fun of the hardworking log4j developers, or the programming community that accepted their outrageously overcomplicated library without question? They're trying their best!

Honestly, I'm a bit miffed. It's a damned if you do, damned if you don't scenario for OSS.

Don't add feature X that other log library might add or has added, your lib is bad. Add a feature X that other log library has, now you support it for the lifetime of universe. Oh and RCE might happen.

It all starts with little changes.

Allow us to show colors in console...

Allow us more formatting options...

We need to display remotely added class...

We need JNDI access...

> Oh and RCE might happen.

You added a feature that can load plugins and query any kind of data based on user provided strings, this is completely unexpected and never happened before. What to call it? How about SQL injection attack, sounds about fancy enough.

If you implement feature requests without thinking about the design and security implications it has you are doomed to repeat history.

Log4j maintainers didn't like the feature, they added it for backwards compatibility.

> Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns.

It was added by these maintainers in 2.x and did not exist in 1.x. The maintainers are also different from 1.x developers and took the brand. They may regret their past decisions, but it was is irresponsible to claim that it was not their fault and added for backward compatibility.

There isn't a benefit to OSS projects all competing for the same audience and bloated feature set. Picking a subset, being opinionated about it and the implementation isn't wrong. For developers, there is such a thing as picking the right tool for the job, even if it isn't your favourite one you usually use.

As much as people moan about npm community, it does give you many choices and you can avoid complicated massive libs

...By adding thousands of libs, turning node_modules into a multi GB folder. Oh, and each of which can be compromised by an unscrupulous actor.

Good luck auditing that.

Like if any other thing with automatic package management is any better.

.m2/repository is 5 gb on my machine.

Rust crates?

Go packages that are neatly tucked away too?

Node just makes it visible and in your face by putting the node_modules in you project directory.

Besides, what’s the alternative? Write stuff yourself? Put stuff in language stdlib? Even minimal service requires _a lot_ of things to do minimal stuff.

I think at some point (like introducing the ability to fetch resources off a network in your logging library) you need to step back and say "let's put this in its own, optional extra module".

There are ways to manage this sort of stuff.

I'm sure the log4j developers have just as much potential as the code they're sort of maintaining.

If you let them into your codebase you get federated remote code updates for free.