4 ms·

Success of Homebrew was based on marketing, not on the tool being well designed on technical level (because it was not designed well) or its authors' technical

by dozzie 8y ago

Success of Homebrew was based on marketing, not on the tool being well designed on technical level (because it was not designed well) or its authors' technical competence (because they haven't displayed it much). Google was hiring for a technical position based on technical prowess, not on marketing one (maybe the skills tested were unrelated to the job, but they were still technical), but people pulling out the Google vs. Homebrew case mistake one for the other, which certainly needs correction. > [...] likely [...] we are coming from perspectives so far apart that there's little hope we could agree. You see, I come from Linux administration field. We have package managers deployed in the field for two decades now. These package managers usually don't silently break your library dependencies on update (though Fedora and desktop Ubuntu break them with a lot of noise) and have integrity ensured cryptographically. I take these features almost for granted, as I work with them every day for a long time. Any package manager that provides anything less than that is, in my view, badly designed, especially because there are many examples of how it should be done, it just takes some effort to learn them. On the other hand, you, coming from macOS angle, didn't have a prior experience of working with many package managers -- or at least that's my guess. If I am right, it's quite clear why a poorly designed but popular package manager (i.e. one that has many packages available already) was a huge improvement for you. It was the same for Debian's APT twenty years ago, but APT had pretty much no prior art and the internet was not a viruses/worms/spyware-driven machine it is nowadays.

mlthoughts2018 8y ago
> "On the other hand, you, coming from macOS angle, didn't have a prior experience of working with many package managers" Just to clarify this: I personally have always used Debian and Ubuntu, and spent a lot of time with APT (including helping to build a PPA for wrapping a custom wrapper for NetworkManager for my company because their third-party VPN solution prevented all of us who use solely Linux from being able to work remotely for a while. Despite my personal views that Linux provides me with better tooling, many of my colleagues don't share that view, and they like to use Mac. At times, homebrew has given us a super easy way to solve some problems that arise from that situation. This doesn't mean it's perfect. Just that it solves specific problems that a lot of users have in a way where they are not adversely affected by its downsides. Every tool out there will have downsides, and a subset of the population who hates the tool because of those downsides. It just strikes me as incredibly myopic to privilege your own experience in system administration as oh so much more enlightened than a person manage the overall problem of a package management tool that users are actually using with success. It's just tone deaf to me to say, "but for these engineering reason that I care about, I discredit the entire achievement of the project because the author didn't design it the way I want." And even if it's not merely "the way you want" but includes broader and more established criteria from history of package management solutions, it's still nonsense to use that to dismiss it. It's a lot like the shortsighted dismissals of early MongoDB, which went after very specific customer use cases at the expense of omitting big design considerations that the history of database engineering had come to accept as standard. MongoDB used this to build a customer base who was happy with what they engineered. And then began investing in going back to fix the things that were glaringly suboptimal from historical database perspective. Lots of people wallowed in their constant criticism of MongoDB, turning their noses up at it. Yet now it's a public company, releasing lots of features that bring it into alignment with those earlier best practices that it was forced to omit for the sake of addressing shorter term workflow needs of its customers. To me, this is effective engineering. Sticking my nose up at MongoDB because of its earlier choices to omit accepted database designs would be a silly way to look at it. I'm not saying that example maps perfectly to homebrew, but it is similar in spirit. It's one thing to say, "I don't like that homebrew prioritized XYZ for its users short term experience instead of addressing big, underlying, sysadmin design considerations ABC." It's totally different to say that this choice entirely discredits the project.
- dozzie 8y ago
  > It just strikes me as incredibly myopic to privilege your own experience in system administration as oh so much more enlightened than a person manage the overall problem of a package management tool that users are actually using with success. Users use with success plenty of ill-suited tools for various purposes. It doesn't make the tools any better, merely more widely used. There are many examples of better products dying, while worse products take over the market. My experience with system administration gives me better standing ground for assessing technical aspects of package managers. These technical aspects have little to do with success of any particular package manager, though, which I find unfortunate. > To me, this [MongoDB; Homebrew too?] is effective engineering. Effective marketing. Engineering, not quite, especially with MongoDB's track of losing real data because of operations tuned for benchmarks. > I'm not saying that example maps perfectly to homebrew, but it is similar in spirit. It is a similar case indeed. Especially in how marketing was much more important for adoption than technical grounds.
saagarjha 8y ago
> On the other hand, you, coming from macOS angle, didn't have a prior experience of working with many package managers -- or at least that's my guess. There were package managers before Homebrew, such as MacPorts and Fink–which went as far to use APT.
setpatchaddress 8y ago
>Success of Homebrew was based on marketing No, as a user of every previous package manager for macOS, I can tell you that Homebrew was successful because it actually worked, and worked really well, and it kept working even for prerelease versions of macOS. This doesn’t mean that it’s well designed or secure. But it’s not a marketing cream puff.
- iainmerrick 8y ago
  Seconded. I like and use homebrew because it works better and causes much less hassle than other Mac package managers. (Before homebrew I used fink.)

by dozzie 8y ago

mlthoughts2018 8y ago

> "On the other hand, you, coming from macOS angle, didn't have a prior experience of working with many package managers" Just to clarify this: I personally have always used Debian and Ubuntu, and spent a lot of time with APT (including helping to build a PPA for wrapping a custom wrapper for NetworkManager for my company because their third-party VPN solution prevented all of us who use solely Linux from being able to work remotely for a while. Despite my personal views that Linux provides me with better tooling, many of my colleagues don't share that view, and they like to use Mac. At times, homebrew has given us a super easy way to solve some problems that arise from that situation. This doesn't mean it's perfect. Just that it solves specific problems that a lot of users have in a way where they are not adversely affected by its downsides. Every tool out there will have downsides, and a subset of the population who hates the tool because of those downsides. It just strikes me as incredibly myopic to privilege your own experience in system administration as oh so much more enlightened than a person manage the overall problem of a package management tool that users are actually using with success. It's just tone deaf to me to say, "but for these engineering reason that I care about, I discredit the entire achievement of the project because the author didn't design it the way I want." And even if it's not merely "the way you want" but includes broader and more established criteria from history of package management solutions, it's still nonsense to use that to dismiss it. It's a lot like the shortsighted dismissals of early MongoDB, which went after very specific customer use cases at the expense of omitting big design considerations that the history of database engineering had come to accept as standard. MongoDB used this to build a customer base who was happy with what they engineered. And then began investing in going back to fix the things that were glaringly suboptimal from historical database perspective. Lots of people wallowed in their constant criticism of MongoDB, turning their noses up at it. Yet now it's a public company, releasing lots of features that bring it into alignment with those earlier best practices that it was forced to omit for the sake of addressing shorter term workflow needs of its customers. To me, this is effective engineering. Sticking my nose up at MongoDB because of its earlier choices to omit accepted database designs would be a silly way to look at it. I'm not saying that example maps perfectly to homebrew, but it is similar in spirit. It's one thing to say, "I don't like that homebrew prioritized XYZ for its users short term experience instead of addressing big, underlying, sysadmin design considerations ABC." It's totally different to say that this choice entirely discredits the project.

dozzie 8y ago
> It just strikes me as incredibly myopic to privilege your own experience in system administration as oh so much more enlightened than a person manage the overall problem of a package management tool that users are actually using with success. Users use with success plenty of ill-suited tools for various purposes. It doesn't make the tools any better, merely more widely used. There are many examples of better products dying, while worse products take over the market. My experience with system administration gives me better standing ground for assessing technical aspects of package managers. These technical aspects have little to do with success of any particular package manager, though, which I find unfortunate. > To me, this [MongoDB; Homebrew too?] is effective engineering. Effective marketing. Engineering, not quite, especially with MongoDB's track of losing real data because of operations tuned for benchmarks. > I'm not saying that example maps perfectly to homebrew, but it is similar in spirit. It is a similar case indeed. Especially in how marketing was much more important for adoption than technical grounds.

saagarjha 8y ago

> On the other hand, you, coming from macOS angle, didn't have a prior experience of working with many package managers -- or at least that's my guess. There were package managers before Homebrew, such as MacPorts and Fink–which went as far to use APT.

setpatchaddress 8y ago

>Success of Homebrew was based on marketing No, as a user of every previous package manager for macOS, I can tell you that Homebrew was successful because it actually worked, and worked really well, and it kept working even for prerelease versions of macOS. This doesn’t mean that it’s well designed or secure. But it’s not a marketing cream puff.

iainmerrick 8y ago
Seconded. I like and use homebrew because it works better and causes much less hassle than other Mac package managers. (Before homebrew I used fink.)