The Ports System
Then, there's the second category; those programs which are add-on packages. In the BSD world, this is usually called the "ports system". That name is chosen for a specific reason.
Traditionally, when you wanted to run a package on your system, the first thing you had to do was compile it. And often before you could compile it, you'd have to fiddle with it. Your system would require different header files. Sometimes, manifest constants would be different. Sometimes, you'd even need to rewrite parts of it from scratch, because of basic assumption that didn't hold on your system.
Or, in other words, you'd have to "port" it to your OS, and/or to your specific system. The basic intent of the ports system is to do all that "porting" stuff for you. That it also automates building and installing, and provides packaging services (for things like 'uninstall') isn't as well reflected in the name.
But as with many things, it grew past its name into the beast it is today. The current FreeBSD ports collection has close to 10,000 packages in it (this number will, of course, be outdated quickly, but that's the nature of development). The most obvious feature of ports is that it builds things from source all the time, rather than just install pre-built binaries. This, it seems, is another one of those blatant differences that trip people up when trying to look at BSD from a Linux perspective. That it builds from source is just a side effect, it's not the primary purpose or difference. Binary packages are also available; in fact, binary packages are built from the ports tree!
Now, it's true that most Linux users install binary packages, and most BSD users install by building from source. Partly, that's a result of the tools; the ports system is designed around the concept of building from source, with the ability to make and install binary packages being something of an afterthought, while Linux packaging like RPM and dpkg and such are designed around the concept of installing a binary package, with building from source as an afterthought. Some of this is historical; binary packaging historically isn't a predominant theme in Unix systems, as I mentioned earlier. For that matter, packaging itself is a more recent thing. Traditionally, you'd deal with uninstalling and such manually.
Gentoo is a Linux distribution gaining in prominence these days. One of its big selling points is its portage system, which is often considered very similar to BSD ports. Perhaps most visibly, in that it compiles from source. That avoids a lot of the problem of binary packages. I've never used it myself, but the impressions I've gotten from information I've seen on it, and people I know who have used it, is that it's taken some good ideas from everyone, and smooshed them together. It'll be very interesting to see how it progresses and matures over the next few years. It's still much more Linux than BSD, but it may well be the closest to the BSD style of the major Linux distributions.
Now, there are advantages to pre-compiled binaries; mostly time (as in much less), and usually it'll take a lot less space to install a pre-compiled package, than it would to compile the package. There are also advantages to building from source, like avoiding all sorts of library versioning ugliness (my personal pet peeve with binary packages). You can install binary packages on Linux or BSD; you can build from source on Linux or BSD. But the users seem to be biased differently, because the systems are biased differently, because the users are biased differently... it all dovetails.
I guess what's important here is to realize that the difference between ports and RPM's isn't just that ports compile and RPM's just install. Ports are designed to cover the full range of bits and pieces of installing stuff; encoding and tracking and installing dependencies, packaging, installing and deinstalling, local changes necessary to build on your system, compile-time configuration tweaks... all those things. An RPM is just a binary package. If you want to auto-install dependencies, you have to have a higher-level tool like urpmi or apt-get to do it. And, since it's binary, you have to deal with library versioning conflicts, or missing compile options, or any of the other limitations you incur by not building it on your own system.
And further, ports, like the rest of the BSD systems, are centralized. The "ports tree" is really just a big directory tree with a bunch of categorized directories, each containing a Makefile with some variable definitions, a checksum file, a packing list, and various other possible things. Each of those directories represents a single program, which is described by the files present. A bunch of black magic happens behind the scenes so that when you run make, it finds and downloads the distribution file from wherever it is, makes any changes or patches necessary, recursively finds and installs all the dependencies, calls GNU configure or imake or whatever preparation programs are necessary with the right options, starts the compile with the right options, etc.
But all those files in that big directory tree are maintained by the FreeBSD project itself. When somebody wrote KDE, for instance, it didn't magically appear in ports trees everywhere. Somebody had to write all the necessary "glue" to build a port for it, then commit the files into the FreeBSD CVS repository so it would be in the ports collection. So again, there's some level of assurance that it works with other things in the ports collection. Any dependencies it has will be there, because it can't declare a dependency on something not in ports.
Things break, of course. Maybe a dependency will have its main site disappear, so nobody can download the source file and start to install it. Maybe a new version of some third program will break a program, which will keep other things that depend on it from working. So of course it doesn't solve all the problems. But the incidence of "I want A, which requires B, which I can't find" is a lot less than it is with such essentially decentralized systems like RPM's turn out to be.
For more detailed information (as always), see the section in the handbook about ports.
Now we've got a working understanding of the dichotomy between the 'base system' and the 'ports tree', which I think really trips a lot of Linux users up. Let's talk a bit about releases and upgrading.