+SBCL can be built from scratch using a plain vanilla ANSI Common Lisp
+system and a C compiler, and all of its properties are specified by
+the version of the source code that it was created from. This clean
+bootstrappability was the immediate motivation for forking off of the
+CMU CL development tree. A variety of implementation differences are
+motivated by this design goal.
+
+Maintenance work in SBCL since the fork has diverged somewhat from the
+maintenance work in CMU CL. Many but not all bug fixes and
+improvements have been shared between the two projects, and sometimes
+the two projects disagree about what would be an improvement.
+
+Most extensions supported by CMU CL have been unbundled from SBCL,
+including Motif support, the Hemlock editor, search paths, the WIRE
+protocol, various user-level macros and functions (\fIe.g.\fR
+\f(CRLETF\fR, \f(CRITERATE\fR, \f(CRMEMQ\fR, \f(CRREQUIRED\-ARGUMENT\fR),
+and many others.
+
+(Why doesn't SBCL support more extensions natively? Why drop all those
+nice extensions from CMU CL when the code already exists? This is a
+frequently asked question on the mailing list. There are two principal
+reasons. First, it's a design philosophy issue: arguably SBCL has done
+its job by supplying a stable FFI, and the right design decision is to
+move functionality derived from that, like socket support, into
+separate libraries. Some of these are distributed with SBCL as
+"contrib" modules, others are distributed as separate software
+packages by separate maintainers. Second, it's a practical decision -
+focusing on a smaller number of things will, we hope, let us do a
+better job on them.)