It used to be that open source software was released only as source code and had to be compiled wherever it was needed. Obviously, that's changed. Today, some will even tell you that compiling source is an improper and problematic way to install software. Tomorrow, it may become more standard than they think.
While compiling source is still the basis of many BSDs (though you can get binary packages easily enough), package management came to Linux early on with RPM and branched out everywhere ever since. Package support on Debian and Ubuntu is simply massive. Fedora has a huge number of packages, as do RHEL and CentOS, though the packages available for the latter are generally far older for legacy and stability reasons.
This reliance on older packages has led to a situation where far too many admins find themselves in unfamiliar territory when confronted with the problem of needing a software release newer than what's available in the various package repositories. If your new app needs foo >= 1.45 and all you can find are RPM packages for 1.42, you're out of luck.
This was never an issue in the old days. You'd grab the 1.45 source, toss it in /usr/local/src, check whatever configure and compile flags you might need, then build and install it under /usr/local. Problem resolved, time for happy hour.
Why do some think this is a nonstandard and problematic way to install software? The drawback is that the package will not show up in the installed packages list, and there could be issues down the line with library installation locations. But the goal is to get the software installed and running, and that goal has been achieved. Ideally, this is documented and life moves on.
However, there's also an alternative: build your own package from the newer source. You can even contribute back to the project if you like! Again, though, I've seen puzzled looks from those who have never gone beyond apt-get or yum to install software. Yes, Francis, you can build your own packages. It's even easy most of the time.
In the RPM world, a fast way to do this is to download the source RPM for the package you need and the source for the version you need, and marry them together, adjusting for whatever differences there may be. This might be a new configure flag or similar, but apart from a little trial and error, it's usually not a big deal. Then build your new RPM with your new version, install it, and you're in the clear -- the right version installed via the "proper" methods. Perhaps you then complete the OSS cycle and send that package back to the maintainer. Everyone wins.
This sounds great -- many times it is -- but it's not always that easy. Many times, there isn't an available RPM because software inconsistencies, bugs, or other issues have prevented the developers from creating one. In those cases, you may have to abandon the package game for the time being.
Also, things have become much more slippery these days with systemd in play. Because packages now need to contend with systemd dependencies and unit files, modifying newer source RPMs to build on a non-systemd distribution can be a nightmare. In cases where a newer package version was available for Fedora but not CentOS, you used to be able to grab the source RPM and make only minor adjustments (if any) to install on a CentOS 5 or 6 system. Those days are gone.
I think this may become a bigger issue in the short term. With the adoption of systemd in several distributions, we're likely to see much longer use of the current, non-systemd releases. CentOS and RHEL will support version 6 until 2020, and I'd bet there will be more CentOS 6 boxes still running in 2020 than there are CentOS 5 boxes running right now. The same might be true for Debian Stable and Ubuntu LTS releases.
This has nothing to do with a like or dislike of systemd. It has everything to do with the decision whether to invest the time, energy, and risk into upgrading otherwise fully functional systems to a newer version due to the need for a single package unrelated to systemd.
For instance, you might have a bunch of production systems that need an application upgrade. As part of that upgrade, you need libraries that are of a version only available as a package on CentOS 7. However, that means you need to upgrade all of those systems to CentOS 7 and thus systemd. You run a few tests and determine that systemd will cause problems with other existing infrastructure components.
Now you have a choice: Do you invest all of the time and energy to develop an infrastructure-wide systemd migration plan, and delay the application upgrade for months, or do you build your own package containing the required library versions and leave everything else alone? Dollars to doughnuts, whoever needs the upgraded app will not give a rat's tuckus about systemd, and delaying decisions by several months will not be an option.
The good news is we're all in the same boat, more or less. Once these pain points become big enough, packages will become available on the more adventurous repos like EPEL and RepoForge that will get us through. But don't think it'll be smooth sailing. If you can say anything about systemd, it sure tends to lead to unanticipated choppy waters.