The Base System
The concept of the "base system" is something that, I think, causes the most trouble for people used to the Linux methodology. Which is perfectly understandable, because the whole idea just doesn't even exist in the Linux world.
Linux, from the start, was just a kernel. Without getting into the eternal debate of what an "operating system" precisely consists of, it's easy to state that a kernel by itself isn't very useful. You need all the userland utilities to make it work. Linux has always been a conglomerate; a kernel from here, a ls from there, a ps from this other place, vim, perl, gzip, tar, and a bundle of others.
Linux has never had any sort of separation between what is the "base system" and what is "addon utilities". The entire system is "addon utilities". MySQL is no different from ls from KDE from whois from dc from GnuCash from ... Every bit of the system is just one or another add-on package.
By contrast, BSD has always had a centralized development model. There's always been an entity that's "in charge" of the system. BSD doesn't use GNU ls or GNU libc, it uses BSD's ls and BSD's libc, which are direct descendents of the ls and libc that were in the CSRG-distributed BSD releases. They've never been developed or packaged independently. You can't go "download BSD libc" somewhere, because in the BSD world, libc by itself is meaningless. ls by itself is meaningless. The kernel by itself is meaningless. The system as a whole is one piece, not a bunch of little pieces.
Now, X isn't a part of the FreeBSD base system. It's an addon package. Since X isn't part of the base system, X apps like xterm and KDE and Gnome and Mozilla and gaim and xmms and such obviously can't be part of the base system either. They're add-on packages, which are treated and thought of differently. The primary difference is where they're developed.
NetBSD and OpenBSD do have an X implementation in the base, because of the way they integrate it with their console driver. They both use heavily modified, very custom versions, so it's not feasible to keep it as a separate package.
The entire base system is developed together. To be sure, there're parts of the base system like sendmail and BIND and tcpdump and ssh and such, which are in fact individual packages which are developed elsewhere. There are even some GNU packages like groff and gcc and gzip and such, which will be immediately recognizable to any Linux user. But these are treated specially, in that versions are imported into the tree, then molded to fit the rest of the system. In fact, many of them used to be BSD-only; BIND and sendmail were originally developed at Berkeley as part of BSD, and only later became available separately. My FreeBSD system claims to be running gcc version 3.2.2 at this moment. Technically, it's not really gcc 3.2.2; it's a FreeBSD compiler based on gcc 3.2.2. The version of tcpdump I've got here isn't technically 3.7.2, it's a FreeBSD tcpdump based on tcpdump 3.7.2.
In most cases, of course, the FreeBSD version is practically indistinguishable from the vendor version. There're usually some changes to the compiling setup (Makefiles and such) to let it build cleanly with the rest of the system, and occasionally some necessary patches to make it compile and run right. Some changes are more extensive, and some are massive. But, they're all maintained together, and forced to play nicely together. There's a basic assurance that the pieces in a BSD base system all fit together, by design.
The primary reason an externally-maintained package becomes imported into and tracked in the base system is that it is, in some way, basic enough to the functioning of the system that it's easiest to have it there by default. FreeBSD currently uses the OpenSSH ssh server and client, which are integrated into the base system because, in this day and age, a secure remote access method is sufficiently basic to any system that it's a practical necessity. gcc and the binutils are part of the base system because... well, they're required to build the base system. X and Gnome and PostgreSQL and Apache and such are not part of the base system, and likely never will be, because they're not required to get the system up and deployed, won't be used on many systems, don't need that sort of close integration... many reasons.
It's important to emphasize this "base system" idea, since it is, I think, one of the most visible indication of the difference in development methodologies between BSD and Linux. A Linux distributor may put together the pieces and test that they fit before releasing. They may even have some customization on some of the packages. But it's rather different from the intense sort of integration done by BSD. Particularly in that so many of the components of the base system don't come from "somewhere else" in the first place; they've lived their whole lives as a part of the system.
Some Linux distributions (Debian and Gentoo, from what I understand, are particularly prominent members of this group) are much more similar to this base/ports split than others. They keep something of a line between what's necessary to get the system running, and all the other packages you might want to install on a system. What distinguishes this from the BSD base system is that most of those packages are still maintained elsewhere, and just "collected" into the Linux dist. There's no "Gentoo tftp", for instance; it's some package from somewhere else. While many packages in BSD are from somewhere else, much of the "base system" never came from some other maintainer; it's always been BSD.
The base system is sometimes labeled as "minimalist" or "lean and mean" or such things, with the implication that it's maintained the way it is out a desire to have it as small or tight as possible. But that's really not the case; sure, we want it to be all those things, but it's done the way it is because it's really intended to be just what it's called; the base of a system. I've never in my life deployed a BSD system running just what's in base, and I probably never will. I don't know anybody who has. The base just needs to provide the tools to get the system running, and allow you to update it and install other packages. Then you install what you need, for the specific role this system is intended for.
I've been told that the above is more true for FreeBSD than for Net or Open, both of which in many ways have much broader criteria for determining what to include in the base system. As always, you should consult the manuals for the individual systems to determine exactly what goes where.
What's next?
Now that we've covered the base system, it's time to talk about the ports tree.