> However, it might as well happen that this is not enough to keep security issues from happening. Things are already moving in a direction where it's absolutely expected that a developer understands and takes responsibility for every line of code that is included in their prodiuct, whether they wrote it themself or not. But if that happens, it will fundamentally change the way we deal with libraries and how software ecosystems work.
That's one of the differences between coders and engineers.
Coders just import libraries to avoid re-inventing the wheel. Engineers consider each import as a dependency they'll have to maintain, buy support for or replace. Log4j just highlighted this difference, with some knowing exactly what to patch and others franctically trying to determine if one of the thousands of dependencies they imported into their app actually used it.
> Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead.
That's one of the differences between coders and engineers.
Coders just import libraries to avoid re-inventing the wheel. Engineers consider each import as a dependency they'll have to maintain, buy support for or replace. Log4j just highlighted this difference, with some knowing exactly what to patch and others franctically trying to determine if one of the thousands of dependencies they imported into their app actually used it.
> Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead.
There's a simple alternative: hire the devs.