1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/thesis/pieces/requirements.tex	Thu Nov 13 15:06:40 2008 +0100
     1.3 @@ -0,0 +1,38 @@
     1.4 +\chapter{Use cases}
     1.5 +
     1.6 +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.
     1.7 +
     1.8 +%FIXME: rewrite!
     1.9 +%       How do I write use cases??
    1.10 +%       Are use cases the right tool for what I need, at all??
    1.11 +
    1.12 +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.
    1.13 +
    1.14 +\masqmail\ must deliver mail to its destination.
    1.15 +
    1.16 +Mail must be send with different settings, if someone uses more than one internet connection.
    1.17 +
    1.18 +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.
    1.19 +
    1.20 +If the computer goes online, all mail for outside destinations, should be send through the active route.
    1.21 +
    1.22 +Local mail should be send at once, independent of the online state.
    1.23 +
    1.24 +\masqmail\ may act as \NAME{SMTP} server. To receive email from other hosts.
    1.25 +
    1.26 +Mail for local users should be delivered by \masqmail\ itself or passed to \name{mail delivery agent}s.
    1.27 +
    1.28 +\masqmail\ needs to provide the same interface as \sendmail\ has, for being a drop-in replacement.
    1.29 +
    1.30 +
    1.31 +%TODO: add Schaeffter's ideas here
    1.32 +\chapter{Requirements}
    1.33 +
    1.34 +\section{Structure}
    1.35 +\section{Security}
    1.36 +\section{Usability}
    1.37 +\chapter{Security issues}
    1.38 +
    1.39 +%TODO: write about:
    1.40 +% #ifdefs in code
    1.41 +% the single setuid root binary

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

     3.1 --- a/thesis/tex/2-FreeSoftwareProjects.tex	Wed Nov 12 18:03:36 2008 +0100
     3.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.3 @@ -1,127 +0,0 @@
     3.4 -\chapter{About \freesw\ projects}
     3.5 -
     3.6 -% http://www.faqs.org/docs/artu/
     3.7 -
     3.8 -There are several differences between \freesw\ projects and projects about proprietary software.
     3.9 -To understand \freesw\ projects, one needs to understand \freesw\ itself first.
    3.10 -
    3.11 -\section{About \freesw}
    3.12 -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.
    3.13 -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.
    3.14 -One could say, the \GPL\ catalized the \name{Free Software movement}.
    3.15 -
    3.16 -% http://www.fsf.org/about/what-is-free-software
    3.17 -
    3.18 -After all, the \GPL\ was not the first \freesw\ license used.
    3.19 -The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
    3.20 -Licenses providing the same rights have been used since long time ago.
    3.21 -But none of them was so often (re)used by other projects---thus gattering less awareness.
    3.22 -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.
    3.23 -
    3.24 -\freesw\ gives freedoms to its users.
    3.25 -In contrast to proprietary software restricting the users freedom.
    3.26 -The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
    3.27 -% http://www.gnu.org/philosophy/free-sw.html
    3.28 -% http://www.fsf.org/licensing/essays/free-sw.html
    3.29 -\begin{enumerate}
    3.30 -	\item The freedom to run the program, for any purpose (freedom 0).
    3.31 -	\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.
    3.32 -	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
    3.33 -	\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.
    3.34 -\end{enumerate}
    3.35 -
    3.36 -
    3.37 -\section{The term ``Open Source''}
    3.38 -\name{Open Source Software} often stands for the same as \freesw.
    3.39 -But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
    3.40 -
    3.41 -\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.
    3.42 -
    3.43 -% http://www.gnu.org/philosophy/open-source-misses-the-point.html
    3.44 -% http://catb.org/~esr/open-source.html
    3.45 -
    3.46 -
    3.47 -\section{Development of \freesw}
    3.48 -Having source code available and the right to modify it, encouridges programmers to actually do so.
    3.49 -Their modifications are manifoldly.
    3.50 -Some tailor the software to their needs.
    3.51 -Some add features.
    3.52 -Some do it just for fun.
    3.53 -There are no limitations---whoever wants to, may work on it.
    3.54 -
    3.55 -Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
    3.56 -The process of development is watchable by everyone.
    3.57 -
    3.58 -The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
    3.59 -
    3.60 -Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
    3.61 -
    3.62 -The following text will focus on the ``bazaar'' model.
    3.63 -
    3.64 -
    3.65 -\section{The role of the community}
    3.66 -\freesw\ projects rise and fall with their community!
    3.67 -
    3.68 -Most \freesw\ programs are developed by a very small group of programmers, often only one person.
    3.69 -But they are used by many people.
    3.70 -In between the programmers and the users, are people located who are a bit of both.
    3.71 -These are the ones that write documentation, find bugs and probably even fix it.
    3.72 -They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
    3.73 -The program is often spread by their ``advertising''.
    3.74 -
    3.75 -The \emph{community} consists of the actual developers and all users that contribute to the program.
    3.76 -Contribution can be one of the described ways, or others like providing a server for the project website for example.
    3.77 -
    3.78 -\emph{Community} is everyone who is in contact through the project.
    3.79 -Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
    3.80 -
    3.81 -There will hardly be a community if no communication channels are available.
    3.82 -If the development team does not provide them, there is a chance that encouraged users set them up on their own.
    3.83 -But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
    3.84 -
    3.85 -Projects without a good community tend to die sooner or later.
    3.86 -
    3.87 -
    3.88 -\section{Evolution of a community}
    3.89 -Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
    3.90 -He starts developing.
    3.91 -When others get in contact with the project, there may be some who are so much interested that they start co-developing.
    3.92 -Others report bugs, and some only use the program.
    3.93 -
    3.94 -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.
    3.95 -The size ratio of the groups vary by type of project.
    3.96 -
    3.97 -One should have that in mind, when starting a \freesw\ project.
    3.98 -
    3.99 -
   3.100 -\section{Creating a strong community}
   3.101 -Building up a good community needs some effort of the main developers.
   3.102 -%TODO: search for documents about this topic
   3.103 -
   3.104 -First communication channels need to be set up, to enable the growth of a community.
   3.105 -
   3.106 -Second, development should be visible by everyone who is interested in it.
   3.107 -Time between work done on the project and its visibility to the public should be kept short.
   3.108 -This makes it interesting for other developers to join.
   3.109 -Developers are the core of a community.
   3.110 -
   3.111 -Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
   3.112 -Releases are (more) stable versions, primary for users.
   3.113 -They should be created, frequently.
   3.114 -People will more likely use programs of active projects.
   3.115 -
   3.116 -Fourth, the developers should try to get the users ``in the boat''.
   3.117 -Good communities have a large group of users that do not only receive, but also give something back to the project.
   3.118 -The project leaders should motivate users to contribute.
   3.119 -This unlocks a big work force and gets lot of unexiting work done.
   3.120 -
   3.121 -Fifth, documentation matters.
   3.122 -Good documentation makes it easy for users and developers to start.
   3.123 -And it helps to avoid a lot of unsatisfaction.
   3.124 -Documentation is something that shows quality and that people care about the project.
   3.125 -
   3.126 -And sixth, project leaders should be good souvereigns.
   3.127 -They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
   3.128 -
   3.129 -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!
   3.130 -Volunteer work lives by acknowledgement of the effort spent.

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

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

     6.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     6.2 +++ b/thesis/tex/3-FreeSoftwareProjects.tex	Thu Nov 13 15:06:40 2008 +0100
     6.3 @@ -0,0 +1,127 @@
     6.4 +\chapter{About \freesw\ projects}
     6.5 +
     6.6 +% http://www.faqs.org/docs/artu/
     6.7 +
     6.8 +There are several differences between \freesw\ projects and projects about proprietary software.
     6.9 +To understand \freesw\ projects, one needs to understand \freesw\ itself first.
    6.10 +
    6.11 +\section{About \freesw}
    6.12 +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.
    6.13 +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.
    6.14 +One could say, the \GPL\ catalized the \name{Free Software movement}.
    6.15 +
    6.16 +% http://www.fsf.org/about/what-is-free-software
    6.17 +
    6.18 +After all, the \GPL\ was not the first \freesw\ license used.
    6.19 +The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
    6.20 +Licenses providing the same rights have been used since long time ago.
    6.21 +But none of them was so often (re)used by other projects---thus gattering less awareness.
    6.22 +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.
    6.23 +
    6.24 +\freesw\ gives freedoms to its users.
    6.25 +In contrast to proprietary software restricting the users freedom.
    6.26 +The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
    6.27 +% http://www.gnu.org/philosophy/free-sw.html
    6.28 +% http://www.fsf.org/licensing/essays/free-sw.html
    6.29 +\begin{enumerate}
    6.30 +	\item The freedom to run the program, for any purpose (freedom 0).
    6.31 +	\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.
    6.32 +	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
    6.33 +	\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.
    6.34 +\end{enumerate}
    6.35 +
    6.36 +
    6.37 +\section{The term ``Open Source''}
    6.38 +\name{Open Source Software} often stands for the same as \freesw.
    6.39 +But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
    6.40 +
    6.41 +\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.
    6.42 +
    6.43 +% http://www.gnu.org/philosophy/open-source-misses-the-point.html
    6.44 +% http://catb.org/~esr/open-source.html
    6.45 +
    6.46 +
    6.47 +\section{Development of \freesw}
    6.48 +Having source code available and the right to modify it, encouridges programmers to actually do so.
    6.49 +Their modifications are manifoldly.
    6.50 +Some tailor the software to their needs.
    6.51 +Some add features.
    6.52 +Some do it just for fun.
    6.53 +There are no limitations---whoever wants to, may work on it.
    6.54 +
    6.55 +Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
    6.56 +The process of development is watchable by everyone.
    6.57 +
    6.58 +The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
    6.59 +
    6.60 +Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
    6.61 +
    6.62 +The following text will focus on the ``bazaar'' model.
    6.63 +
    6.64 +
    6.65 +\section{The role of the community}
    6.66 +\freesw\ projects rise and fall with their community!
    6.67 +
    6.68 +Most \freesw\ programs are developed by a very small group of programmers, often only one person.
    6.69 +But they are used by many people.
    6.70 +In between the programmers and the users, are people located who are a bit of both.
    6.71 +These are the ones that write documentation, find bugs and probably even fix it.
    6.72 +They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
    6.73 +The program is often spread by their ``advertising''.
    6.74 +
    6.75 +The \emph{community} consists of the actual developers and all users that contribute to the program.
    6.76 +Contribution can be one of the described ways, or others like providing a server for the project website for example.
    6.77 +
    6.78 +\emph{Community} is everyone who is in contact through the project.
    6.79 +Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
    6.80 +
    6.81 +There will hardly be a community if no communication channels are available.
    6.82 +If the development team does not provide them, there is a chance that encouraged users set them up on their own.
    6.83 +But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
    6.84 +
    6.85 +Projects without a good community tend to die sooner or later.
    6.86 +
    6.87 +
    6.88 +\section{Evolution of a community}
    6.89 +Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
    6.90 +He starts developing.
    6.91 +When others get in contact with the project, there may be some who are so much interested that they start co-developing.
    6.92 +Others report bugs, and some only use the program.
    6.93 +
    6.94 +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.
    6.95 +The size ratio of the groups vary by type of project.
    6.96 +
    6.97 +One should have that in mind, when starting a \freesw\ project.
    6.98 +
    6.99 +
   6.100 +\section{Creating a strong community}
   6.101 +Building up a good community needs some effort of the main developers.
   6.102 +%TODO: search for documents about this topic
   6.103 +
   6.104 +First communication channels need to be set up, to enable the growth of a community.
   6.105 +
   6.106 +Second, development should be visible by everyone who is interested in it.
   6.107 +Time between work done on the project and its visibility to the public should be kept short.
   6.108 +This makes it interesting for other developers to join.
   6.109 +Developers are the core of a community.
   6.110 +
   6.111 +Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
   6.112 +Releases are (more) stable versions, primary for users.
   6.113 +They should be created, frequently.
   6.114 +People will more likely use programs of active projects.
   6.115 +
   6.116 +Fourth, the developers should try to get the users ``in the boat''.
   6.117 +Good communities have a large group of users that do not only receive, but also give something back to the project.
   6.118 +The project leaders should motivate users to contribute.
   6.119 +This unlocks a big work force and gets lot of unexiting work done.
   6.120 +
   6.121 +Fifth, documentation matters.
   6.122 +Good documentation makes it easy for users and developers to start.
   6.123 +And it helps to avoid a lot of unsatisfaction.
   6.124 +Documentation is something that shows quality and that people care about the project.
   6.125 +
   6.126 +And sixth, project leaders should be good souvereigns.
   6.127 +They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
   6.128 +
   6.129 +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!
   6.130 +Volunteer work lives by acknowledgement of the effort spent.

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

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

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

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

    11.1 --- a/thesis/thesis.tex	Wed Nov 12 18:03:36 2008 +0100
    11.2 +++ b/thesis/thesis.tex	Thu Nov 13 15:06:40 2008 +0100
    11.3 @@ -33,15 +33,15 @@
    11.4  \include{tex/1-Comparision}
    11.5  \include{tex/1-Masqmail}
    11.6  
    11.7 +%\part{}
    11.8 +%\include{tex/2-}
    11.9 +%\include{tex/2-}
   11.10 +%\include{tex/2-}
   11.11 +
   11.12  \part{The masqmail project}
   11.13 -\include{tex/2-FreeSoftwareProjects}
   11.14 -\include{tex/2-BecomingProjectLeader}
   11.15 -\include{tex/2-ProjectManagement}
   11.16 -
   11.17 -\part{Requirements}
   11.18 -\include{tex/3-Usecases}
   11.19 -\include{tex/3-Requirements}
   11.20 -\include{tex/3-SecurityIssues}
   11.21 +\include{tex/3-FreeSoftwareProjects}
   11.22 +\include{tex/3-BecomingProjectLeader}
   11.23 +\include{tex/3-ProjectManagement}
   11.24  
   11.25  \part{Implementation}
   11.26  \include{tex/4-ProjectManagement}