5 ms·

I do agree with what I take as the general message: most people don't really understand how open source works and have unreasonable expectations. Maintainers do

by palata 3y ago

I do agree with what I take as the general message: most people don't really understand how open source works and have unreasonable expectations. Maintainers don't owe users anything unless the user actually pays for it and the maintainer accepts the money for the task. Developers should understand what it actually means to depend on a project. If one needs a fix or a change down the line, it could be that nobody will be there to do it for free, or at all. Therefore one should be ready to either pay or take over the maintenance. And this should be carefully put in balance every time: "Should I add this dependency, or should I write it myself?". Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies (and then be pissed at the maintainers who don't want to maintain for free or at all).

bayindirh 3y ago
> Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies... Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. One of the worse offenders I have seen was adding whole Pandas and the kitchen sink for a simple table lookup. I have seen other programs which adds almost hundred libraries for something which can be implemented in a relatively simple way. Then people whine about dependency hell.
- throwaway11460 3y ago
  > Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well that's where modern bundler steps in - who cares if you throw the unnecessary cruft away during build process? Except in Python where a dependency might uninstall your desktop GUI and switch the init system, perhaps.
  - bayindirh 3y ago
    The problem with this approach is not shipping unused functions at the end. Pruning them is an old practice. The problem is inclusion of that much libraries creates a dependency hell, because a higher level library pulls in approximately 5 more libraries which are generally shared amongst other libraries you potentially pull. Library A updates its' dependency to library C to a new, more recent minimum, but library B depends on C's behavior which is recently changed. Hence A requires C > v3, but B requires C==v2. Then the fun begins. Bonus points for having a serious CVE/RCE as a reason for updating C to v3 in the first place.
    - throwaway11460 3y ago
      That's why we use Semver, at least in the Node land. A security fix should be a patch, at most minor version bump - API/behavior shouldn't change.
      - bayindirh 3y ago
        This doesn't change the fact that some security fixes forces behavioral changes, and semver doesn't protect you against that. You fix the bug, and the behavior changes, because your design was wrong in the first place. Now there is at least one library which depends on that behavior so bad, so they can't change their dependency chain in two days.
  - barkbyte 3y ago
    Dependencies can also do that in node with post install hooks (or in rust with build.rs even if you don’t call into them, I think)
  - edflsafoiewq 3y ago
    The dev who you made download and build all those deps just to throw them away for one. Not super fond of the attitude that efficiency for the end user is a necessary evil... but a dev can be expected to endure any indignity.
    - throwaway11460 3y ago
      What about the dev who is making the library for their own purposes, they don't matter? Be thankful for the opportunity to use their work for free; you can do your own thing if you don't like theirs.
      - edflsafoiewq 3y ago
        By that argument you can never criticize anything, so what's the point of even talking about how you should or should not code?
        throwaway11460 3y ago
        Yes, you can't criticize that somebody made a big library - you have no idea why, how and under what circumstances it was made. Even if the only reason is that the author doesn't find it fun to maintain a bunch of libraries, that's still a valid reason. It's actually exactly that most of the time - it's a hobby, not a job to them. They probably maintain few dozen microservices at work, why bring it home too? In other cases you have resource constraints, cost/benefit optimization, etc. You can say you'd prefer a bunch of smaller more focused libraries, but criticizing that big one is wrong, especially if you got it for free including the source and a license to distribute and modify it. And this has nothing to do with how you should or should not code, there's no definite way how everyone should code; some prefer batteries-included frameworks and some prefer small focused pieces - it's an opinion more than a fact that small library is better. But even if not, people are free to share their bad work and you are free to pass on it, provide suggestions or patches - but criticizing it is entitled. BTW it's funny to argue that you should be able to criticize a big library for being too big right under a discussion about dependency version requirement hell. One big library that includes everything would alleviate that pain - perhaps that's what the authors were looking to fix. As I said, this is an opinion, not fact.
- sureIy 3y ago
  > Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well then which one is it? There’s no middle ground, unless at some point you decide it’s now worth using a big library and start replacing your own code. If you decide to write everything from scratch, good luck to your users, they’re not getting a better product.
  - bayindirh 3y ago
    I use big and well matured libraries for the critical parts of my code. These can be logging, option/file parsing, or linear algebra. When I add these libraries, I use most parts of them at the end of the day. However for other one-off things like internal state handling or stuff which I can prop up using the standard library, I refuse to use external libraries. I kindly disagree on the part of they're not getting a better product. On the contrary. They require to manage less dependencies, most critical parts are well cooked/tested, and other parts are built using the standard library which is built to build these things. When rolling things forward, I need to juggle less dependencies, too. So things can move forward easier. It's not like I'm banging the keyboard and shouting done when it prints something meaningful to screen.
  - Chris2048 3y ago
    > There’s no middle ground unless using a language that supports tree-shaking. Also, you could also use the same interface (fn-signature etc), or even add a flag for if the lib is installed (in python, try-except over import, with "dummy" module as fallback).
ozim 3y ago
*Maintainers don't owe users anything unless the user actually pays for it and the maintainer accepts the money for the task.* I have a nitpick on that take. If maintainer was actively building community and advocating use of his project (for whatever reasons but usually to gain audience - money is not the only value exchange that there is) they still do owe users bug fixes or reviewing bug fixes made by community. Especially if there were other community contributions, cash on hand is too specific. If someone doesn't want to owe users anything, don't make project open source or make it clear "don't use this or fork for yourself, please" in read-me or something. But also one should not pull dependencies willy-nilly especially if one is building business on top of that.
- sureIy 3y ago
  This is such a bad take, I’m glad you already got like 8 replies. My code is open source, at a minimum it’s there for your own perusal to be copy-pasted. I don’t owe you anything.
- bayindirh 3y ago
  Free Software ecosystem is not black and white (i.e. Build a community or don't share). I put my software in the open with a license which I think is fair, because I hope someone might find it useful, with a completely neutral stance. On the other hand, I set my expectations with the license I assign to my codebase. If nobody cares about what I do, I'm also fine with it. At the end of the day, I wrote that thing for myself in the first place. If somebody decides to contribute something back, my primary responsibility is to act as decently as other party allows me. They can report a bug, send in a fix, or ask something. If the proposed change is favorable to both of us (i.e. it also fits into the design/role I have in my mind for that codebase, or doesn't disturb it), why not work together and make something better? If the change makes the software unfit for me, but fit for the other party, they're free to fork and maintain their fork as they fit, as long as they honor the license. This is why is this thing is in the open. But, if the requester wants me to implement their changes to make the software fit for themselves, while making it unfit for me, and want to pass the burden of maintenance on me, then sorry, we can't cooperate. Plus, who decides which codebase I open to the world, and in what way?
Gigachad 3y ago
I’m not sure cargo is really the fault rather than developers who import a library just to use a trivial utility function in one place. Modern package managers solve 1000x problems and make one pitfall slightly easier. But it’s still a very easily avoided problem.
- deleted 3y ago
  [deleted]

by palata 3y ago

bayindirh 3y ago

> Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies... Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. One of the worse offenders I have seen was adding whole Pandas and the kitchen sink for a simple table lookup. I have seen other programs which adds almost hundred libraries for something which can be implemented in a relatively simple way. Then people whine about dependency hell.

throwaway11460 3y ago
> Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well that's where modern bundler steps in - who cares if you throw the unnecessary cruft away during build process? Except in Python where a dependency might uninstall your desktop GUI and switch the init system, perhaps.
- bayindirh 3y ago
  The problem with this approach is not shipping unused functions at the end. Pruning them is an old practice. The problem is inclusion of that much libraries creates a dependency hell, because a higher level library pulls in approximately 5 more libraries which are generally shared amongst other libraries you potentially pull. Library A updates its' dependency to library C to a new, more recent minimum, but library B depends on C's behavior which is recently changed. Hence A requires C > v3, but B requires C==v2. Then the fun begins. Bonus points for having a serious CVE/RCE as a reason for updating C to v3 in the first place.
  - throwaway11460 3y ago
    That's why we use Semver, at least in the Node land. A security fix should be a patch, at most minor version bump - API/behavior shouldn't change.
    - bayindirh 3y ago
      This doesn't change the fact that some security fixes forces behavioral changes, and semver doesn't protect you against that. You fix the bug, and the behavior changes, because your design was wrong in the first place. Now there is at least one library which depends on that behavior so bad, so they can't change their dependency chain in two days.
- barkbyte 3y ago
  Dependencies can also do that in node with post install hooks (or in rust with build.rs even if you don’t call into them, I think)
- edflsafoiewq 3y ago
  The dev who you made download and build all those deps just to throw them away for one. Not super fond of the attitude that efficiency for the end user is a necessary evil... but a dev can be expected to endure any indignity.
  - throwaway11460 3y ago
    What about the dev who is making the library for their own purposes, they don't matter? Be thankful for the opportunity to use their work for free; you can do your own thing if you don't like theirs.
    - edflsafoiewq 3y ago
      By that argument you can never criticize anything, so what's the point of even talking about how you should or should not code?
      - throwaway11460 3y ago
        Yes, you can't criticize that somebody made a big library - you have no idea why, how and under what circumstances it was made. Even if the only reason is that the author doesn't find it fun to maintain a bunch of libraries, that's still a valid reason. It's actually exactly that most of the time - it's a hobby, not a job to them. They probably maintain few dozen microservices at work, why bring it home too? In other cases you have resource constraints, cost/benefit optimization, etc. You can say you'd prefer a bunch of smaller more focused libraries, but criticizing that big one is wrong, especially if you got it for free including the source and a license to distribute and modify it. And this has nothing to do with how you should or should not code, there's no definite way how everyone should code; some prefer batteries-included frameworks and some prefer small focused pieces - it's an opinion more than a fact that small library is better. But even if not, people are free to share their bad work and you are free to pass on it, provide suggestions or patches - but criticizing it is entitled. BTW it's funny to argue that you should be able to criticize a big library for being too big right under a discussion about dependency version requirement hell. One big library that includes everything would alleviate that pain - perhaps that's what the authors were looking to fix. As I said, this is an opinion, not fact.
sureIy 3y ago
> Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well then which one is it? There’s no middle ground, unless at some point you decide it’s now worth using a big library and start replacing your own code. If you decide to write everything from scratch, good luck to your users, they’re not getting a better product.
- bayindirh 3y ago
  I use big and well matured libraries for the critical parts of my code. These can be logging, option/file parsing, or linear algebra. When I add these libraries, I use most parts of them at the end of the day. However for other one-off things like internal state handling or stuff which I can prop up using the standard library, I refuse to use external libraries. I kindly disagree on the part of they're not getting a better product. On the contrary. They require to manage less dependencies, most critical parts are well cooked/tested, and other parts are built using the standard library which is built to build these things. When rolling things forward, I need to juggle less dependencies, too. So things can move forward easier. It's not like I'm banging the keyboard and shouting done when it prints something meaningful to screen.
- Chris2048 3y ago
  > There’s no middle ground unless using a language that supports tree-shaking. Also, you could also use the same interface (fn-signature etc), or even add a flag for if the lib is installed (in python, try-except over import, with "dummy" module as fallback).

ozim 3y ago

*Maintainers don't owe users anything unless the user actually pays for it and the maintainer accepts the money for the task.* I have a nitpick on that take. If maintainer was actively building community and advocating use of his project (for whatever reasons but usually to gain audience - money is not the only value exchange that there is) they still do owe users bug fixes or reviewing bug fixes made by community. Especially if there were other community contributions, cash on hand is too specific. If someone doesn't want to owe users anything, don't make project open source or make it clear "don't use this or fork for yourself, please" in read-me or something. But also one should not pull dependencies willy-nilly especially if one is building business on top of that.

sureIy 3y ago
This is such a bad take, I’m glad you already got like 8 replies. My code is open source, at a minimum it’s there for your own perusal to be copy-pasted. I don’t owe you anything.
bayindirh 3y ago
Free Software ecosystem is not black and white (i.e. Build a community or don't share). I put my software in the open with a license which I think is fair, because I hope someone might find it useful, with a completely neutral stance. On the other hand, I set my expectations with the license I assign to my codebase. If nobody cares about what I do, I'm also fine with it. At the end of the day, I wrote that thing for myself in the first place. If somebody decides to contribute something back, my primary responsibility is to act as decently as other party allows me. They can report a bug, send in a fix, or ask something. If the proposed change is favorable to both of us (i.e. it also fits into the design/role I have in my mind for that codebase, or doesn't disturb it), why not work together and make something better? If the change makes the software unfit for me, but fit for the other party, they're free to fork and maintain their fork as they fit, as long as they honor the license. This is why is this thing is in the open. But, if the requester wants me to implement their changes to make the software fit for themselves, while making it unfit for me, and want to pass the burden of maintenance on me, then sorry, we can't cooperate. Plus, who decides which codebase I open to the world, and in what way?

Gigachad 3y ago

I’m not sure cargo is really the fault rather than developers who import a library just to use a trivial utility function in one place. Modern package managers solve 1000x problems and make one pitfall slightly easier. But it’s still a very easily avoided problem.

deleted 3y ago
[deleted]