*nix developers pride themselves on making things that work and work well. Look, let's say I want to make a desktop environment. I have to support operating systems A, B, and C. 95% of people use A. All three systems manage wifi, sound, disk, camera, microphone, HID in different ways. It's kind of a pain to write the thing to handle wifi, sound, automount, optical drives, camera, microphone, HID on B and C, for little reward, isn't it? The way forward is to write FreeBSD-specific graphical programs to handle wifi, sound, disk, camera, microphone, HID that work with the popular window managers. Dropbox and f.lux can pop little icons in the top bar on OS X without being developed by Apple, and figuring out how to put an icon in GNOME Panel is way, waaaaaaay easier than figuring out how to configure seamless failover swapping between wireless and wired internet on FreeBSD. As proof: how many FreeBSD laptop users out there have configured failover swapping between wireless and wired internet? It's only, I don't know, a hundred shell commands and twenty config files dealing with eighty gazillion drivers and half a googolplex of possible wireless NICs. So instead of having a GNOME application that deals with the intricacies of wlan0 et al, it makes more sense to have a FreeBSD-specific GUI application that deals with putting a little thingy in the GNOME Panel, the KDE Panel, the flux box panel, the e17 panel, what-have-you, because all of those things are comparatively not so bad (the developers of many other applications do it this way!). And plus, if putting a thingy in the panel doesn't work, I can still listen to music. Not so if GNOME's volume manager blows up on my novelty sound card; I'm reduced to a shell, and I have to journey into the netherworld of /etc to see what went wrong. The best user experience can be achieved in the former case, and that's what matters.