--- a/ch02.roff	Wed Mar 07 14:33:03 2012 +0100
+++ b/ch02.roff	Wed Mar 07 14:33:19 2012 +0100
@@ -2,10 +2,85 @@
 .P
 foo
 
-.H1 "History to Understand
+.H1 "Historic Background
+.P
+In order to understand the state, goals and dynamics of a project,
+you need to know its history. MH comes from a time before the
+Internet, a time before networking became universal, a time when
+emailing was small, short and simple. Then it grew, spread and
+adopted to the changes. The core-concepts, however, remained the
+same. During the XXX a small group of students at the University of
+California, actively worked on MH. They added features and optimized,
+like it is common for scientific work. This is still in pre-ANSI C
+times. The source code contains many ancient parts. Code constructs
+specific to BSD or hardware of that time are usual.
+.P
+Nmh started eight years after the ANSI C standard had been
+established. A more modern coding style entered the code base. Still
+a part of the developers come from ``the old days''. The developer
+base became more diverse and thus the code. Programming practices
+from different decades merged into the project. Different coding
+styles came together. It appears as if multiple peers added code
+parts, resulting in a conclomeration rather than an homogenic
+of-one-cast mail system. Still, the basic concepts hold it together.
+They were mostly untouched throughout the years.
+.P
+Although, at the surface, nmh is a toolchest, meaning a collection
+of completely modularized small programs, on the source code level,
+it is much more interweaved. Parts of the basic functions are
+collected in a MH standard library, which is good, but often
+separate functions are compiled into programs, for effiency reasons.
+This lead to intricate innards.
+The advent of MIME rose the complexity of email by a magnitude. This
+is visible in nmh. The MIME-related parts are the most complex ones.
+It's also visible that MIME support had been added on top of the
+original MH later. The MH style made this easily possible, but it
+also lead to duplicated functions (e.g. \f(CWshow\fP, \f(CWmhshow\fP)
+and had not been thoroughly included into the concepts (e.g. the
+user-visible access to whole messages and MIME parts are inherently
+different).
 .P
-foo
+For compatibility's sake, it is a common understanding to have the
+default settings to be compatible, requiring any new feature to be
+explicitely enabled. This puts a burden on new users, because nmh
+out-of-the-box keeps staying in the same ancient style, where users
+usually want to have it practical for modern emailing.
+But of course, this depends on if nmh is seen to be a front-end or a
+back-end.
+
+.H1 "My Vision
+.P
+The general goals of the mmh project are the following:
+.BU
+I believe that mmh should be perfectly suited for modern emailing,
+out-of-the-box.
+.BU
+I care less about compatibility and more about conceptionally elegant
+approaches.
+.BU
+I care for general, clear, and simple concepts.
+.BU
+I like to create an of-one-style email system.
+.BU
+I plan to remove any optimizations that rises obscurity, unless it
+appears to be neccessary to make mmh usable at all.
+.P
+.B "The target user in mind
+likes Unix and its philosophy.
+He likes to use programs that are conceptionally appealing.
+He's familiar with the command line and enjoys its power.
+He is at least capable of shell scripting and wants to improve his
+productivity by scripting the mail system.
+His computer and operating system are from post-ANSI C times.
+He likes to attach files, exchanges text containing non-ASCII
+characters, signs or encrypts his messages.
+He does not use bulletin boards anymore, nor non-mbox style mail
+drops, nor does he rely on compatibility to nmh.
+He already has and MTA/MSA and MRA running or is able to set them
+up.
+He does not want to have to read a book in order to make his MUA
+usable.
 
 .H1 "Things to do
 .P
-foo
+