Dropping MacPorts for Homebrew
For years now, I have been a user and proponent of MacPorts instead of the more popular choice, Homebrew. At the latest when I discovered FreeBSD to be superior to the various Linux distributions (for my needs), I admired the implementation and care of the “ports” projects. MacPorts is very much in line with this care, essentially bringing the BSD “ports” tree over to macOS. It was started by volunteers and Apple engineers, was long-time hosted by Apple and has recently moved over to GitHub — a highly anticipated but also challenged move by those using and contributing to the project. The people running MacPorts generally appear to be very knowledgeable about the platform, porting software and working out patches to make everything work. In fact, the new kid on the block, Homebrew, often lifts patches from MacPorts. It’s the solid, conservative choice. They use TCL and C for running things, changes get rsync’d to your machine and for the longest time the VCS of choice was SVN.
Homebrew, in constrast, is the cool, hip place to be. It’s based on Ruby, was
built around Git repositories from day one (and GitHub in particular) and does
some rather controversial stuff like taking over your /usr/local folder by
default. Ruby and GitHub appear to be the hipster developer choice for some
reason, although I’m pretty sure that Homebrew would be a Node.js project were
it conceived within the last couple of years. This alone was enough to drive me
away from Homebrew, which I used as my first package manager ever on Mac OS X,
back in the day. It just seemed so convenient — and more to the point, even a
novice gets to install some software via the shell. Which is another point that
quickly drew me away: I’m not a hipster Ruby/JS guy, I’m a serious software
developer after all! I will have none of this! Freeeeeeeedoooooooom! (At this
point please imagine me breaking out into a holy rage, ranting on and on about
how trends are destroying everything worth having and how we can’t have nice
things anyway because of idiots and how the whole of humanity is surely
doomed.)
Anyway. Where was I? MacPorts, right… My troubles began with a rather simple problem: I wanted to install Pandoc. Pandoc, you see, requires Haskell. However, the Haskell port was too old for Pandoc to build at the time. In fact, it was broken for a couple of months. Possibly years. No one could reliably tell, as MacPorts users apparently don’t have a need for running Pandoc. Additionally, some older ports also relied on an older Haskell version, all of which would break if Haskell got updated. I found out about this only after I signed up for their bug tracker, a horribly bloated, customized, slow and out-of-date Trac. The workflow to open an issue was laborous and error-prone to say the least. I’m sure the seasoned contributors are perfectly fine with this. After all, there’s a reason for why things are the way they are. For a newcomer like me, however, the process was downright hostile. Plus, I found issues and diffs that were over 5 years old, were never merged and basically left open to deal with… whenever. That’s right, no pull requests or the like existed here, you have had to manually diff any changes and manually upload and attach the resulting diff file to an issue. Also, you needed to find out the maintainer of the port you were reporting on by running a terminal command, copy the email address over, format the title in a specific way (which exactly mirrored the version number you had to enter in a separate field anyway) and finally format your issue in a non-obvious (Markdown anyone?) way with no quick help or cheatsheet in sight. After having done all this, the first response that came in was about how I had done something wrong. Then, nothing. A couple of days later, some references to already-existing issues were added. Issues, mind you, that were months and years old. Wow.
Maybe I’m spoiled by working with GitHub for so long. Issues are easy to open, you can have a discussion with the author/maintainer and other people experiencing similar issues. You can take part because you already have an account and already know the workflow of submitting a bug or a patch. But there’s more.
After I joined the MacPorts mailing list, I inquired about any help wanted to support the project. The response was along the lines of “we always need to attract more people to help out, so yes please”. I found out about the plan to move to GitHub to attract more contributors. I offered to give restructuring the documentation a try, from a perspective of a newcomer, to clear things up and make it easier to understand. I’m not usually in the mood to read a document that essentially amounts to an academic whitepaper to install and use a package manager. That shouldn’t be neccessary. My ideas were welcomed with open arms by one person while the main web guy chipped in that he would redo the whole thing anyway, very soon. I offered to help him with that. He declined. The identical documentation and website are online as of this writing. That was more than two years ago. I have unsubscribed from the mailing list in the meantime.
Fast forward to today: MacPorts is on GitHub. Yay! But: reporting issues and pull requests that aren’t simple version bumps still require you to use the Trac. The first time I contributed an update to ncurses (which had a color bug messing up everything from vim to cmus to vifm) the pull request was closed and a similar version was merged. No explanation. I asked for one and got informed that a similar one had already been on the maintainer’s machine and differed slightly. No attribution, not even a simple “thanks anyway”, basically erecting a big “don’t disturb me, go away” sign. Also, pull requests apparently don’t get merged anyway. So the whole move to GitHub to attract new contributors is for naught as it doesn’t allow for a GitHub workflow. This is probably what compromise looks like when one half of an existing team wants to stay within the old structure and the other wants to modernize. You get a system that doesn’t work particularly well for any of the two. You especially won’t gain any new contributors. I haven’t had any patch merged as of today.
Contrast that with my Homebrew experience, if you will. Forked the repository, created a feature branch, made, committed and pushed the changes, opened a pull request, got it merged within three hours, meaning the patch was live for everyone.
Which brings me to my main criticism of MacPorts. For all intents and purposes, MacPorts appears to be a project run by a tightly-knit group of individuals who don’t embrace change, do not like to challenge the status quo and send mixed messages about their goals. It may have once been a great way to install and manage Unix-like software on the macOS platform but as it stands today, as a community it has ground to a halt. No wonder that the Homebrew project takes what MacPorts appears to be best at — technical expertise in the form of macOS software patches — and leaves everything else in favor of a more open, more welcoming community. Given that every person has finite time and resources at hand, I choose to go where I can effect the most positive impact. That, I’m afraid, certainly isn’t the MacPorts community.