4 ms·

I don't think it's that big of a deal honestly. If some guy in Nebraska maintains some library that is very useful and your company relies on it and does not p

I don't think it's that big of a deal honestly. If some guy in Nebraska maintains some library that is very useful and your company relies on it and does not pay him, you're asking to wind up relying on an unmaintained project eventually. If I maintained something extremely valuable and found out a core google product relied on it, I'd stop maintaining it.

marktani 5y ago
may I ask why you would stop maintaining it in this case? aren't you then limiting yourself in your self-expression?
- ohgodplsno 5y ago
  Getting Google to waste time and money would be the best self-expression someone can ever have.
- WJW 5y ago
  Presumably their wish to cause google some inconvenience is greater than their wish for self-expression, and/or they have other means of expressing themselves so they don't care about any particular project.
hn_throwaway_99 5y ago
I think the issue, which is so well depicted in that XKCD cartoon, is that transitive dependencies can make it nearly impossible to not depend on some low-level, unmaintained library. It's not like tens of thousands of projects decide to pull in left-pad. But tens of thousands of projects do decide to use React, which (I'm guessing through its own gaggle of many dependency layers) happened to pull in left-pad. Taking the option of "I'll just build everything myself" then is not really a viable process in today's world, where all of your competitors will be using tons of prebuilt stuff (unless, perhaps, you have the productivity of someone like Fabrice Bellard, but the reason he's so well known is because his abilities are so rare). I think the real fix is that dependency management tools like NPM and Maven need to make it much easier to "override" dependency package names so that, if a critical issue is discovered, you are not at the mercy of the current maintainers of that package to quickly get a fix into production.
- nyanpasu64 5y ago
  > Taking the option of "I'll just build everything myself" then is not really a viable process in today's world I want it to be practical to build software which only depends on a small number of trusted individuals or organizations beyond the OS and compiler. C++ manages it better than newer languages with built in package managers, and dependencies rarely depend on transitive dependencies, though it comes at the cost of adding dependencies (especially transitive dependencies) being extremely difficult (I hear Meson subprojects help, and CMake has their own worse version I didn't try).
- j-bos 5y ago
  "I think the real fix is that dependency management tools like NPM and Maven need to make it much easier to "override" dependency package names so that, if a critical issue is discovered, you are not at the mercy of the current maintainers of that package to quickly get a fix into production." I'm probably mistaken, but I thought in maven managedDependencies was exactly this. Please correct me if I'm wrong.
  - ohgodplsno 5y ago
    Maven/Gradle does exactly that. Provided the dependency you're replacing is compatible with the new one (same packages, same methods, etc), it's fully transparent. It's just that once again, the web world is running with awful tools that keep making the same mistakes that have been done years before them.
    - CRConrad 5y ago
      Upvoted for that last sentence.
- fileeditview 5y ago
  > Taking the option of "I'll just build everything myself" then is not really a viable process in today's world, where all of your competitors will be using tons of prebuilt stuff [...] It obviously depends on the scope of things but I tend to see a future where this building everything yourself might be an advantage again. Because most of "this prebuilt stuff" adds layers of complexity because of generalizations you don't need and other abstractions. In my experience this gets worse and worse every year. We software developers are already drowning in a flood of languages, frameworks and so on. How often do I see a framework Y built on top of library/framework X to abstract away something from X. Not only you have now both dependencies but at some point Y lacks a feature you need (which is provided by X). Now you have to pull up X and mix with Y and everything just got worse than just using X from the get go.. I more and more think we need some back to the root movement and also keep in mind to always choose the simplest solution.
TheRealPomax 5y ago
You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it broke millions of applications the world over when it got pulled. Some projects have the benefit of notoriety (log4j falls in that category) but plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list. I can guarantee you that except for security audits, no one knows their full dependency tree, and that they have a deeper dependency with itself a dependency on a utility that depends on a thing that no one's even heard of, and no one's looked at for years, and you would never have looked for. While also being one of the critical pieces that your software runs on top of, capable of bringing down your entire product even if _what it does_ is literally trivial. Best case, it fails. Your product/server is now broken (hopefully, for only a short while). But worst case, it has a 0-day exploit. And now your entire company is at risk to the tune of "depending on how bad, you may have just gone out of business because you can't afford what is necessary to both legally and professionally deal with the fallout". (Did your product/service have a database that comes with rather massive fines for leaking that data? Good luck, that might bankrupt you. Does your company have contracts that are void on significant service interruption? Good luck, you may have just lost all your big clients. Etc.)
- ohgodplsno 5y ago
  > plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list. Maybe in the web world. .Net/Java/C/C++/etc projects have a well understood dependency chain, most of the time. Mostly because there is an actual stdlib and having dependencies upon dependencies upon dependencies is very rare. Projects I've worked on with over 150 dependencies (which is an awful lot for an Android project as it was) had a dependency tree that wasn't that deep (5 at most), and all of that was on standard, well known modules (androidx, etc.) The shitshow that is JS dependency management is a self-inflincted wound. Knowing your dependency tree _is part of your job_ as a software engineer.
- whateveracct 5y ago
  > You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it broke millions of applications the world over when it got pulled. We're professionals - we in fact simply can do that with some elbow grease. Doesn't take a genius to understand how software is built.
armchairhacker 5y ago
This is what I was thinking: it seems like any security and reliability vulnerabilities from OSS are at least as bad, if not worse, in paid software or closed-source. You can pay someone a lot to make a product and they can do a shitty job. You can have a company install a backdoor in a closed-source software for whatever reason. You can have a well-trusted organization with competent developers mess up a single line of code, creating a huge bug or exploit. OSS actually gives you a benefit that you can see the code and technically discover any bugs or exploits (even though of course nobody will). There are plenty of open-source libraries where contributions are seriously reviewed for any accidental or intentional errors. Serious hard-to-patch exploits are discovered in closed-source software every day. They might be harder to discover and easier to reveal without revealing how to trigger, because you can't directly see the source code. But this isn't a fundamental problem of OSS, it's something OSS users and maintainers need to look out for.
- indymike 5y ago
  > This is what I was thinking: it seems like any security and reliability vulnerabilities from OSS are at least as bad, if not worse, in paid software or closed-source. This is wrong: it's better in open source land. Closed source means you, the user have to wait for the vendor to ship a fix. With closed source, the answer sometimes is the version you are on is no longer maintained, and you must buy a new licenses to fix the vulnerability in your closed-source product. Other times, the answer is, sorry, we discontinued that product and will not be patching it. With open source, you have options when a maintainer says the version is too old: fix yourself, use a patched fork, or migrate. Any way you go, the situation is substantially better than closed source. > OSS actually gives you a benefit that you can see the code and technically discover any bugs or exploits (even though of course nobody will). People can and do find and report bugs and exploits in OSS all the time. It's what makes open source work so well.

marktani 5y ago

may I ask why you would stop maintaining it in this case? aren't you then limiting yourself in your self-expression?

ohgodplsno 5y ago
Getting Google to waste time and money would be the best self-expression someone can ever have.
WJW 5y ago
Presumably their wish to cause google some inconvenience is greater than their wish for self-expression, and/or they have other means of expressing themselves so they don't care about any particular project.

hn_throwaway_99 5y ago

I think the issue, which is so well depicted in that XKCD cartoon, is that transitive dependencies can make it nearly impossible to not depend on some low-level, unmaintained library. It's not like tens of thousands of projects decide to pull in left-pad. But tens of thousands of projects do decide to use React, which (I'm guessing through its own gaggle of many dependency layers) happened to pull in left-pad. Taking the option of "I'll just build everything myself" then is not really a viable process in today's world, where all of your competitors will be using tons of prebuilt stuff (unless, perhaps, you have the productivity of someone like Fabrice Bellard, but the reason he's so well known is because his abilities are so rare). I think the real fix is that dependency management tools like NPM and Maven need to make it much easier to "override" dependency package names so that, if a critical issue is discovered, you are not at the mercy of the current maintainers of that package to quickly get a fix into production.

nyanpasu64 5y ago
> Taking the option of "I'll just build everything myself" then is not really a viable process in today's world I want it to be practical to build software which only depends on a small number of trusted individuals or organizations beyond the OS and compiler. C++ manages it better than newer languages with built in package managers, and dependencies rarely depend on transitive dependencies, though it comes at the cost of adding dependencies (especially transitive dependencies) being extremely difficult (I hear Meson subprojects help, and CMake has their own worse version I didn't try).
j-bos 5y ago
"I think the real fix is that dependency management tools like NPM and Maven need to make it much easier to "override" dependency package names so that, if a critical issue is discovered, you are not at the mercy of the current maintainers of that package to quickly get a fix into production." I'm probably mistaken, but I thought in maven managedDependencies was exactly this. Please correct me if I'm wrong.
- ohgodplsno 5y ago
  Maven/Gradle does exactly that. Provided the dependency you're replacing is compatible with the new one (same packages, same methods, etc), it's fully transparent. It's just that once again, the web world is running with awful tools that keep making the same mistakes that have been done years before them.
  - CRConrad 5y ago
    Upvoted for that last sentence.
fileeditview 5y ago
> Taking the option of "I'll just build everything myself" then is not really a viable process in today's world, where all of your competitors will be using tons of prebuilt stuff [...] It obviously depends on the scope of things but I tend to see a future where this building everything yourself might be an advantage again. Because most of "this prebuilt stuff" adds layers of complexity because of generalizations you don't need and other abstractions. In my experience this gets worse and worse every year. We software developers are already drowning in a flood of languages, frameworks and so on. How often do I see a framework Y built on top of library/framework X to abstract away something from X. Not only you have now both dependencies but at some point Y lacks a feature you need (which is provided by X). Now you have to pull up X and mix with Y and everything just got worse than just using X from the get go.. I more and more think we need some back to the root movement and also keep in mind to always choose the simplest solution.

TheRealPomax 5y ago

You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it broke millions of applications the world over when it got pulled. Some projects have the benefit of notoriety (log4j falls in that category) but plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list. I can guarantee you that except for security audits, no one knows their full dependency tree, and that they have a deeper dependency with itself a dependency on a utility that depends on a thing that no one's even heard of, and no one's looked at for years, and you would never have looked for. While also being one of the critical pieces that your software runs on top of, capable of bringing down your entire product even if _what it does_ is literally trivial. Best case, it fails. Your product/server is now broken (hopefully, for only a short while). But worst case, it has a 0-day exploit. And now your entire company is at risk to the tune of "depending on how bad, you may have just gone out of business because you can't afford what is necessary to both legally and professionally deal with the fallout". (Did your product/service have a database that comes with rather massive fines for leaking that data? Good luck, that might bankrupt you. Does your company have contracts that are void on significant service interruption? Good luck, you may have just lost all your big clients. Etc.)

ohgodplsno 5y ago
> plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list. Maybe in the web world. .Net/Java/C/C++/etc projects have a well understood dependency chain, most of the time. Mostly because there is an actual stdlib and having dependencies upon dependencies upon dependencies is very rare. Projects I've worked on with over 150 dependencies (which is an awful lot for an Android project as it was) had a dependency tree that wasn't that deep (5 at most), and all of that was on standard, well known modules (androidx, etc.) The shitshow that is JS dependency management is a self-inflincted wound. Knowing your dependency tree _is part of your job_ as a software engineer.
whateveracct 5y ago
> You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it broke millions of applications the world over when it got pulled. We're professionals - we in fact simply can do that with some elbow grease. Doesn't take a genius to understand how software is built.

armchairhacker 5y ago

This is what I was thinking: it seems like any security and reliability vulnerabilities from OSS are at least as bad, if not worse, in paid software or closed-source. You can pay someone a lot to make a product and they can do a shitty job. You can have a company install a backdoor in a closed-source software for whatever reason. You can have a well-trusted organization with competent developers mess up a single line of code, creating a huge bug or exploit. OSS actually gives you a benefit that you can see the code and technically discover any bugs or exploits (even though of course nobody will). There are plenty of open-source libraries where contributions are seriously reviewed for any accidental or intentional errors. Serious hard-to-patch exploits are discovered in closed-source software every day. They might be harder to discover and easier to reveal without revealing how to trigger, because you can't directly see the source code. But this isn't a fundamental problem of OSS, it's something OSS users and maintainers need to look out for.

indymike 5y ago
> This is what I was thinking: it seems like any security and reliability vulnerabilities from OSS are at least as bad, if not worse, in paid software or closed-source. This is wrong: it's better in open source land. Closed source means you, the user have to wait for the vendor to ship a fix. With closed source, the answer sometimes is the version you are on is no longer maintained, and you must buy a new licenses to fix the vulnerability in your closed-source product. Other times, the answer is, sorry, we discontinued that product and will not be patching it. With open source, you have options when a maintainer says the version is too old: fix yourself, use a patched fork, or migrate. Any way you go, the situation is substantially better than closed source. > OSS actually gives you a benefit that you can see the code and technically discover any bugs or exploits (even though of course nobody will). People can and do find and report bugs and exploits in OSS all the time. It's what makes open source work so well.