# HG changeset patch # User meillo@marmaro.de # Date 1226585200 -3600 # Node ID 24068a091af7135ce6296d8620658912f0ce3e3b # Parent a6aa37e12dff39e392489fa86e718049b7df7978 backuped and removed requirements part; moved part 2 back diff -r a6aa37e12dff -r 24068a091af7 thesis/pieces/requirements.tex --- /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 diff -r a6aa37e12dff -r 24068a091af7 thesis/tex/2-BecomingProjectLeader.tex --- 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} - diff -r a6aa37e12dff -r 24068a091af7 thesis/tex/2-FreeSoftwareProjects.tex --- 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. diff -r a6aa37e12dff -r 24068a091af7 thesis/tex/2-ProjectManagement.tex --- 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} - diff -r a6aa37e12dff -r 24068a091af7 thesis/tex/3-BecomingProjectLeader.tex --- /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} + diff -r a6aa37e12dff -r 24068a091af7 thesis/tex/3-FreeSoftwareProjects.tex --- /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. diff -r a6aa37e12dff -r 24068a091af7 thesis/tex/3-ProjectManagement.tex --- /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} + diff -r a6aa37e12dff -r 24068a091af7 thesis/tex/3-Requirements.tex --- 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} diff -r a6aa37e12dff -r 24068a091af7 thesis/tex/3-SecurityIssues.tex --- 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 diff -r a6aa37e12dff -r 24068a091af7 thesis/tex/3-Usecases.tex --- 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} - diff -r a6aa37e12dff -r 24068a091af7 thesis/thesis.tex --- 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{} +%\include{tex/2-} +%\include{tex/2-} +%\include{tex/2-} + \part{The masqmail project} -\include{tex/2-FreeSoftwareProjects} -\include{tex/2-BecomingProjectLeader} -\include{tex/2-ProjectManagement} - -\part{Requirements} -\include{tex/3-Usecases} -\include{tex/3-Requirements} -\include{tex/3-SecurityIssues} +\include{tex/3-FreeSoftwareProjects} +\include{tex/3-BecomingProjectLeader} +\include{tex/3-ProjectManagement} \part{Implementation} \include{tex/4-ProjectManagement}