macports [1] is a great thing. I like it almost as much as I like freebsd's ports system (which is my favorite package system).
My experience is that these third-party package managers are great, until you want to make them work with software that doesn't come through the package system. A good test case, I think, would be this: how easy is it to install Python via [MacPorts|Fink|Homebrew|etc.] and then compile and run the latest SciPy (say, a bleeding-edge version from source control, not one from the package manager) against that Python?
Can you speak to a case like this, or one of similar complexity?
$ brew install python pip gfortran # Fortran's for scipy...
$ pip install numpy
$ pip install svn+http://svn.scipy.org/svn/scipy/trunk/#egg=scipy
If you don't want to use the SVN version of SciPy, you can just use:
$ pip install scipy
Homebrew and pip are the first things I've ever used that made me not miss apt on debian.
I've used MacPorts to install one dependency for something I was compiling by hand, and so I sort of did the opposite: I told MacPorts to install that particular package into the directory where I had hand-built the rest of them.
I'm not an "open source developer." But I do write code from time to time that I am happy to share with others. I run Debian on a desktop most of the time; essentially the only program I interact with outside of Emacs is a web browser. I do have a Macbook, though, that I use as a second computer when I'm away from home.
I am constantly frustrated by OS X.
The biggest reason is one of the `features' mentioned in the article: the `./configure && make && make install' routine seems to constantly break on OS X. This is a problem for me because much of the software I use (or try to play around with) doesn't specifically target OS X, so there generally aren't pre-compiled binaries available, and often the build instructions do not provide helpful hints for OS X users. I used to work in a lab that ran entirely on OS X. Compiling scientific libraries (e.g. SciPy) was frequently a recursive nightmare of trying to compile or otherwise install various dependencies (in SciPy's case, I remember the lack of gfortran being an issue).
Often, the problem has to do with missing libraries or figuring out how to set CFLAGS to cope with Apple's non-standard paths, both of which are headache enough. But sometimes the errors are just incomprehensible -- at least to someone without serious C knowledge -- and then I'm stuck.
Sometimes, Apple has done the hard work for you of properly configuring and installing popular Free programs (e.g. Emacs, Python) but the versions are Apple modified, can be difficult to get to work with outside libraries, and are often very old.
(I'm venting a bit here because I have been suffering from these sorts of problems fairly acutely in the last couple of days, but it really does seem to be an issue every time I want to use something on OS X: from Emacs to Python to Git to whatever else, something always seems to go wrong, even if it's not a dealbreaker.)
The bottom line is that OS X is a long way away, for me, from being an environment in which I can comfortably use all the software I want to without too much time lost down the rabbit hole of configuration. And I don't even spend most of my time programming! So I'd have to disagree with the sentiment of the article.