--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/thesis/pieces/requirements.tex	Thu Nov 13 15:06:40 2008 +0100
@@ -0,0 +1,38 @@
+\chapter{Use cases}
+
+Here follow typical use cases for \masqmail. If other \MTA{}s are better suited for certain use cases, it will be mentioned. The use cases are prestage for defining the requirements.
+
+%FIXME: rewrite!
+%       How do I write use cases??
+%       Are use cases the right tool for what I need, at all??
+
+The user writes email with one of the common programs (e.g. \path{/bin/mail} or \name{mutt}). \masqmail\ must provide an interface, to that prepared mail can be handled over.
+
+\masqmail\ must deliver mail to its destination.
+
+Mail must be send with different settings, if someone uses more than one internet connection.
+
+If the machine is offline, no mail, destinated to the internet, must be send. It needs to be queued until an online connection gets established.
+
+If the computer goes online, all mail for outside destinations, should be send through the active route.
+
+Local mail should be send at once, independent of the online state.
+
+\masqmail\ may act as \NAME{SMTP} server. To receive email from other hosts.
+
+Mail for local users should be delivered by \masqmail\ itself or passed to \name{mail delivery agent}s.
+
+\masqmail\ needs to provide the same interface as \sendmail\ has, for being a drop-in replacement.
+
+
+%TODO: add Schaeffter's ideas here
+\chapter{Requirements}
+
+\section{Structure}
+\section{Security}
+\section{Usability}
+\chapter{Security issues}
+
+%TODO: write about:
+% #ifdefs in code
+% the single setuid root binary

--- a/thesis/tex/2-BecomingProjectLeader.tex	Wed Nov 12 18:03:36 2008 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,4 +0,0 @@
-\chapter{Becoming project leader}
-\section{History of \masqmail}
-\section{Taking it}
-

--- a/thesis/tex/2-FreeSoftwareProjects.tex	Wed Nov 12 18:03:36 2008 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,127 +0,0 @@
-\chapter{About \freesw\ projects}
-
-% http://www.faqs.org/docs/artu/
-
-There are several differences between \freesw\ projects and projects about proprietary software.
-To understand \freesw\ projects, one needs to understand \freesw\ itself first.
-
-\section{About \freesw}
-The term ``Free Software'' was coined by the \name{Free Software Foundation} (short: \NAME{FSF}), founded by Richard~M.\ Stallman (known as ``RMS'') in 1985.
-Although various licenses make software free, none of them represents the thinking of \freesw\ like the the \GNU\ \gpl\ (short: \GPL). Its first version was written by Stallman in 1989.
-One could say, the \GPL\ catalized the \name{Free Software movement}.
-
-% http://www.fsf.org/about/what-is-free-software
-
-After all, the \GPL\ was not the first \freesw\ license used.
-The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
-Licenses providing the same rights have been used since long time ago.
-But none of them was so often (re)used by other projects---thus gattering less awareness.
-Further more was the \GPL\ created to be a \emph{general} license for all kinds of programs, unlike most other licenses written for one particular program.
-
-\freesw\ gives freedoms to its users.
-In contrast to proprietary software restricting the users freedom.
-The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
-% http://www.gnu.org/philosophy/free-sw.html
-% http://www.fsf.org/licensing/essays/free-sw.html
-\begin{enumerate}
-	\item The freedom to run the program, for any purpose (freedom 0).
-	\item The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
-	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
-	\item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
-\end{enumerate}
-
-
-\section{The term ``Open Source''}
-\name{Open Source Software} often stands for the same as \freesw.
-But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
-
-\name{Open Source Software} is a subset of \freesw, meaning: All \freesw\ is \name{Open Source}, but there exists \name{Open Source Software} that is not free.
-
-% http://www.gnu.org/philosophy/open-source-misses-the-point.html
-% http://catb.org/~esr/open-source.html
-
-
-\section{Development of \freesw}
-Having source code available and the right to modify it, encouridges programmers to actually do so.
-Their modifications are manifoldly.
-Some tailor the software to their needs.
-Some add features.
-Some do it just for fun.
-There are no limitations---whoever wants to, may work on it.
-
-Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
-The process of development is watchable by everyone.
-
-The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
-
-Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
-
-The following text will focus on the ``bazaar'' model.
-
-
-\section{The role of the community}
-\freesw\ projects rise and fall with their community!
-
-Most \freesw\ programs are developed by a very small group of programmers, often only one person.
-But they are used by many people.
-In between the programmers and the users, are people located who are a bit of both.
-These are the ones that write documentation, find bugs and probably even fix it.
-They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
-The program is often spread by their ``advertising''.
-
-The \emph{community} consists of the actual developers and all users that contribute to the program.
-Contribution can be one of the described ways, or others like providing a server for the project website for example.
-
-\emph{Community} is everyone who is in contact through the project.
-Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
-
-There will hardly be a community if no communication channels are available.
-If the development team does not provide them, there is a chance that encouraged users set them up on their own.
-But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
-
-Projects without a good community tend to die sooner or later.
-
-
-\section{Evolution of a community}
-Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
-He starts developing.
-When others get in contact with the project, there may be some who are so much interested that they start co-developing.
-Others report bugs, and some only use the program.
-
-After some time, one will find a small group of core developers, a larger group of contributers (bugs, patches, documentation) and a very large group of users.
-The size ratio of the groups vary by type of project.
-
-One should have that in mind, when starting a \freesw\ project.
-
-
-\section{Creating a strong community}
-Building up a good community needs some effort of the main developers.
-%TODO: search for documents about this topic
-
-First communication channels need to be set up, to enable the growth of a community.
-
-Second, development should be visible by everyone who is interested in it.
-Time between work done on the project and its visibility to the public should be kept short.
-This makes it interesting for other developers to join.
-Developers are the core of a community.
-
-Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
-Releases are (more) stable versions, primary for users.
-They should be created, frequently.
-People will more likely use programs of active projects.
-
-Fourth, the developers should try to get the users ``in the boat''.
-Good communities have a large group of users that do not only receive, but also give something back to the project.
-The project leaders should motivate users to contribute.
-This unlocks a big work force and gets lot of unexiting work done.
-
-Fifth, documentation matters.
-Good documentation makes it easy for users and developers to start.
-And it helps to avoid a lot of unsatisfaction.
-Documentation is something that shows quality and that people care about the project.
-
-And sixth, project leaders should be good souvereigns.
-They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
-
-Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way!
-Volunteer work lives by acknowledgement of the effort spent.

--- a/thesis/tex/2-ProjectManagement.tex	Wed Nov 12 18:03:36 2008 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,8 +0,0 @@
-\chapter{Project management}
-\section{Infrastructure}
-\section{Community}
-\section{Development}
-\section{Documentation}
-\section{Quality assurance}
-\section{Distribution}
-

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/thesis/tex/3-BecomingProjectLeader.tex	Thu Nov 13 15:06:40 2008 +0100
@@ -0,0 +1,4 @@
+\chapter{Becoming project leader}
+\section{History of \masqmail}
+\section{Taking it}
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/thesis/tex/3-FreeSoftwareProjects.tex	Thu Nov 13 15:06:40 2008 +0100
@@ -0,0 +1,127 @@
+\chapter{About \freesw\ projects}
+
+% http://www.faqs.org/docs/artu/
+
+There are several differences between \freesw\ projects and projects about proprietary software.
+To understand \freesw\ projects, one needs to understand \freesw\ itself first.
+
+\section{About \freesw}
+The term ``Free Software'' was coined by the \name{Free Software Foundation} (short: \NAME{FSF}), founded by Richard~M.\ Stallman (known as ``RMS'') in 1985.
+Although various licenses make software free, none of them represents the thinking of \freesw\ like the the \GNU\ \gpl\ (short: \GPL). Its first version was written by Stallman in 1989.
+One could say, the \GPL\ catalized the \name{Free Software movement}.
+
+% http://www.fsf.org/about/what-is-free-software
+
+After all, the \GPL\ was not the first \freesw\ license used.
+The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
+Licenses providing the same rights have been used since long time ago.
+But none of them was so often (re)used by other projects---thus gattering less awareness.
+Further more was the \GPL\ created to be a \emph{general} license for all kinds of programs, unlike most other licenses written for one particular program.
+
+\freesw\ gives freedoms to its users.
+In contrast to proprietary software restricting the users freedom.
+The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
+% http://www.gnu.org/philosophy/free-sw.html
+% http://www.fsf.org/licensing/essays/free-sw.html
+\begin{enumerate}
+	\item The freedom to run the program, for any purpose (freedom 0).
+	\item The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
+	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
+	\item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
+\end{enumerate}
+
+
+\section{The term ``Open Source''}
+\name{Open Source Software} often stands for the same as \freesw.
+But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
+
+\name{Open Source Software} is a subset of \freesw, meaning: All \freesw\ is \name{Open Source}, but there exists \name{Open Source Software} that is not free.
+
+% http://www.gnu.org/philosophy/open-source-misses-the-point.html
+% http://catb.org/~esr/open-source.html
+
+
+\section{Development of \freesw}
+Having source code available and the right to modify it, encouridges programmers to actually do so.
+Their modifications are manifoldly.
+Some tailor the software to their needs.
+Some add features.
+Some do it just for fun.
+There are no limitations---whoever wants to, may work on it.
+
+Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
+The process of development is watchable by everyone.
+
+The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
+
+Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
+
+The following text will focus on the ``bazaar'' model.
+
+
+\section{The role of the community}
+\freesw\ projects rise and fall with their community!
+
+Most \freesw\ programs are developed by a very small group of programmers, often only one person.
+But they are used by many people.
+In between the programmers and the users, are people located who are a bit of both.
+These are the ones that write documentation, find bugs and probably even fix it.
+They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
+The program is often spread by their ``advertising''.
+
+The \emph{community} consists of the actual developers and all users that contribute to the program.
+Contribution can be one of the described ways, or others like providing a server for the project website for example.
+
+\emph{Community} is everyone who is in contact through the project.
+Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
+
+There will hardly be a community if no communication channels are available.
+If the development team does not provide them, there is a chance that encouraged users set them up on their own.
+But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
+
+Projects without a good community tend to die sooner or later.
+
+
+\section{Evolution of a community}
+Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
+He starts developing.
+When others get in contact with the project, there may be some who are so much interested that they start co-developing.
+Others report bugs, and some only use the program.
+
+After some time, one will find a small group of core developers, a larger group of contributers (bugs, patches, documentation) and a very large group of users.
+The size ratio of the groups vary by type of project.
+
+One should have that in mind, when starting a \freesw\ project.
+
+
+\section{Creating a strong community}
+Building up a good community needs some effort of the main developers.
+%TODO: search for documents about this topic
+
+First communication channels need to be set up, to enable the growth of a community.
+
+Second, development should be visible by everyone who is interested in it.
+Time between work done on the project and its visibility to the public should be kept short.
+This makes it interesting for other developers to join.
+Developers are the core of a community.
+
+Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
+Releases are (more) stable versions, primary for users.
+They should be created, frequently.
+People will more likely use programs of active projects.
+
+Fourth, the developers should try to get the users ``in the boat''.
+Good communities have a large group of users that do not only receive, but also give something back to the project.
+The project leaders should motivate users to contribute.
+This unlocks a big work force and gets lot of unexiting work done.
+
+Fifth, documentation matters.
+Good documentation makes it easy for users and developers to start.
+And it helps to avoid a lot of unsatisfaction.
+Documentation is something that shows quality and that people care about the project.
+
+And sixth, project leaders should be good souvereigns.
+They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
+
+Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way!
+Volunteer work lives by acknowledgement of the effort spent.

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/thesis/tex/3-ProjectManagement.tex	Thu Nov 13 15:06:40 2008 +0100
@@ -0,0 +1,8 @@
+\chapter{Project management}
+\section{Infrastructure}
+\section{Community}
+\section{Development}
+\section{Documentation}
+\section{Quality assurance}
+\section{Distribution}
+

--- a/thesis/tex/3-Requirements.tex	Wed Nov 12 18:03:36 2008 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,5 +0,0 @@
-\chapter{Requirements}
-
-\section{Structure}
-\section{Security}
-\section{Usability}

--- a/thesis/tex/3-SecurityIssues.tex	Wed Nov 12 18:03:36 2008 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,5 +0,0 @@
-\chapter{Security issues}
-
-%TODO: write about:
-% #ifdefs in code
-% the single setuid root binary

--- a/thesis/tex/3-Usecases.tex	Wed Nov 12 18:03:36 2008 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,2 +0,0 @@
-\chapter{Use cases}
-

--- a/thesis/thesis.tex	Wed Nov 12 18:03:36 2008 +0100
+++ b/thesis/thesis.tex	Thu Nov 13 15:06:40 2008 +0100
@@ -33,15 +33,15 @@
 \include{tex/1-Comparision}
 \include{tex/1-Masqmail}
 
-\part{The masqmail project}
-\include{tex/2-FreeSoftwareProjects}
-\include{tex/2-BecomingProjectLeader}
-\include{tex/2-ProjectManagement}
+%\part{}
+%\include{tex/2-}
+%\include{tex/2-}
+%\include{tex/2-}
 
-\part{Requirements}
-\include{tex/3-Usecases}
-\include{tex/3-Requirements}
-\include{tex/3-SecurityIssues}
+\part{The masqmail project}
+\include{tex/3-FreeSoftwareProjects}
+\include{tex/3-BecomingProjectLeader}
+\include{tex/3-ProjectManagement}
 
 \part{Implementation}
 \include{tex/4-ProjectManagement}