3 ms·
> Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you me
by gridlockd 6y ago
> Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned)
It's not always the best way, it's a shortcut. While you're spending time figuring out which JSON library is the best by some metric that might ultimately be irrelevant to the task at hand, I'm going with the popular option that is almost certainly "good enough" for me - otherwise it wouldn't be popular. That gives me an advantage over you, 98% of the time.
> Adopts a purely consumeristic view of open source
I don't see how this relates to popularity. Most users of open source will always be consumers, whether something is popular or not. However, if something is popular, the likelihood of someone to contribute back also grows.
Furthermore, if something is popular and there's an issue, somebody else will most likely run into it before me, write about it, get feedback on it, and so on. That's a valuable contribution, even though it isn't code.
- denoma 6y agoThe tendency to go for most popular library/framework/etc, with all the assorted justifications (which are valid to a degree and thus misleading) is an indication of just how rampant cargo culture is in software. Everybody always looking for the default thing to throw at the wall, hoping it solves their problem. And it’s fine, for prototyping and fast growth “products” (really mvps and demos) but with anything serious you must do the required legwork to figure out what is actually needed, and it’s often best to limit dependencies on external libraries and frameworks as much as possible.
- gridlockd 6y agoI disagree that this is cargo culture. I'm not arguing for people to follow the latest hype, or do what everyone else does, in the hopes of winning. I'm saying that if you have the choice between a handful of projects that solve more or less the same problem that you actually have, just going with the most popular one is probably going to be the best choice, because having all these other people in the same boat is valuable. I agree with limiting dependencies and points of failure, but that's orthogonal.