diff --git a/MOTIVATION.md b/MOTIVATION.md
new file mode 100644
index 0000000..07e6093
--- /dev/null
+++ b/MOTIVATION.md
@@ -0,0 +1,30 @@
+Motivation
+----------
+
+> “Why an event loop, why not use threads?”
+
+With the advent of light-weight processes (threads) programmers these
+days have a [golden hammer](http://c2.com/cgi/wiki?GoldenHammer) they
+often swing without consideration.  Event loops and non-blocking I/O is
+often a far easier approach, as well as less error prone.
+
+The purpose of many applications is, with a little logic sprinkled on
+top, to act on network packets entering an interface, timeouts expiring,
+mouse clicks, or other types of events.  Such applications are often
+very well suited to use an event loop.
+
+Applications that need to churn massively parallel algorithms are more
+suitable for running multiple (independent) threads on several CPU
+cores.  However, threaded applications must deal with the side effects
+of concurrency, like race conditions, deadlocks, live locks, etc.
+Writing error free threaded applications is hard, debugging them can be
+even harder.
+
+Sometimes the combination of multiple threads *and* an event loop per
+thread can be the best approach, but each application of course needs to
+be broken down individually to find the most optimal approach.  Do keep
+in mind, however, that not all systems your application will run on have
+multiple CPU cores -- some small embedded systems still use a single CPU
+core, even though they run Linux, with multiple threads a program may
+actually run slower!  Always profile your program, and if possible, test
+it on different architectures.
diff --git a/README.md b/README.md
index 0562991..10f87ec 100644
--- a/README.md
+++ b/README.md
@@ -12,7 +12,7 @@ libuEv | Simple event loop for Linux
 * [Using -luev](src/README.md#using--luev)
 * [Joystick Example](src/README.md#joystick-example)
 * [Build & Install](#build--install)
-* [Background](#background)
+* [Motivation](MOTIVATION.md#background)
 * [Origin & References](#origin--references)
 
 
@@ -59,38 +59,6 @@ examples, use the `--enable-examples` switch to the `configure` script.
 The resulting .so file is ~14 kiB (<kbd>make install-strip</kbd>).
 
 
-Background
-----------
-
-> “Why an event loop, why not use threads?”
-
-With the advent of light-weight processes (threads) programmers these
-days have a [golden hammer](http://c2.com/cgi/wiki?GoldenHammer) they
-often swing without consideration.  Event loops and non-blocking I/O is
-often a far easier approach, as well as less error prone.
-
-The purpose of many applications is, with a little logic sprinkled on
-top, to act on network packets entering an interface, timeouts expiring,
-mouse clicks, or other types of events.  Such applications are often
-very well suited to use an event loop.
-
-Applications that need to churn massively parallel algorithms are more
-suitable for running multiple (independent) threads on several CPU
-cores.  However, threaded applications must deal with the side effects
-of concurrency, like race conditions, deadlocks, live locks, etc.
-Writing error free threaded applications is hard, debugging them can be
-even harder.
-
-Sometimes the combination of multiple threads *and* an event loop per
-thread can be the best approach, but each application of course needs to
-be broken down individually to find the most optimal approach.  Do keep
-in mind, however, that not all systems your application will run on have
-multiple CPU cores -- some small embedded systems still use a single CPU
-core, even though they run Linux, with multiple threads a program may
-actually run slower!  Always profile your program, and if possible, test
-it on different architectures.
-
-
 Origin & References
 -------------------