1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 18 11:53:04 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 18 11:54:04 2009 +0100
     1.3 @@ -467,11 +467,9 @@
     1.4  \subsection{Discussion}
     1.5  
     1.6  
     1.7 -\subsubsection*{Quality improvements} % PRO
     1.8 +\subsubsection*{Quality improvements}
     1.9  
    1.10 -Most quality properties can hardly be added to a software afterwards. Hence, if reliability, extendability, or maintainability shall be improved, a redesign of \masqmail\ is the best way to take. This is also true for adding modularity with internal and external interfaces, which is highly prefered from the architectural point of view (see section \ref{sec:discussion-mta-arch}).
    1.11 -
    1.12 -The wish for good reliability, extendability, and maintainability inevitably point towards a rewrite using a modern, modular architecture. The need for further features, especially ones that require changes in \masqmail's structure, support the decision for a new design too. Hence a rewrite is enfavored if \masqmail\ should become a modern \MTA, with good quality properties.
    1.13 +Most quality properties can hardly be added to a software afterwards. Hence, if reliability, extendability, or maintainability shall be improved, a redesign of \masqmail\ is the best way to take. The wish to improve quality inevitably point towards a modular architecture. Modularity with internal and external interfaces is highly prefered from the architectural point of view (see section \ref{sec:discussion-mta-arch}). The need for further features, especially ones that require changes in \masqmail's structure, support the decision for a new design too. Hence a rewrite is enfavored if \masqmail\ should become a modern \MTA, with good quality properties.
    1.14  
    1.15  
    1.16  
    1.17 @@ -485,7 +483,7 @@
    1.18  \hfill\cite[page 55]{graff03}
    1.19  \end{quote}
    1.20  
    1.21 -They also recommend to add wrappers and interposition filters \emph{around} applications, but more as repair techniques if it is not possible to design security \emph{into} a software the first way \cite[pages~71--72]{graff03}.
    1.22 +They also suggest to add wrappers and interposition filters \emph{around} applications, but more as repair techniques if it is not possible to design security \emph{into} a software the first way \cite[pages~71--72]{graff03}.
    1.23  
    1.24  \person{Hafiz} adds: ``The major idea is that security cannot be retrofitted \emph{into} an architecture.'' \cite[page 64]{hafiz05} (emphasisis added).
    1.25  
    1.26 @@ -500,7 +498,7 @@
    1.27  
    1.28  \codeinput{input/masqmail-sloccount.txt}
    1.29  
    1.30 -The development cost in money is not relevant for a \freesw\ project with volunteer developers, but the development time is. About 24 man-months are estimated. The current code base was written almost completely by \person{Oliver Kurth} within four years in his spare time. This means he needed around twice as much time. Of course, he programmed as a volunteer developer not as an employee with eight work-hours per day.
    1.31 +The development costs in money are not relevant for a \freesw\ project with volunteer developers, but the development time is. About 24 man-months are estimated. The current code base was written almost completely by \person{Oliver Kurth} within four years in his spare time. This means he needed around twice as much time. Of course, he programmed as a volunteer developer not as an employee with eight work-hours per day.
    1.32  
    1.33  Given the assumptions that (1) an equal amount of code needs to be produced for a new designed \masqmail, (2) a third of existing code can be reused plus concepts and knowledge, and (3) development speed is like \person{Kurth}'s. Then it would take between two and three years for one programmer to produce a redesigned new \masqmail\ with the same features that \masqmail\ now has. Less time would be needed if a simpler architecture allows faster development, better testing, and less bugs. Of course more developers would speed it up too.
    1.34  
    1.35 @@ -509,38 +507,40 @@
    1.36  
    1.37  \subsubsection*{Risks}
    1.38  
    1.39 -If the gained result still overwights the development effort, risks are something more to consider.
    1.40 +The gained result might still overwights the development effort. But risks are something more to consider.
    1.41  
    1.42  A redesign and rewrite of software from scratch is hard. It takes time to design a new architecture, which then must prove that it is as good as expected. As well is much time and work needed to implement the design, test it, fix bugs, and so on. If flaws in the design appear during prototype implementation, it is necessary to start again.
    1.43  
    1.44 -Such a redesign can fail at many points and it is for long unclear if the result is really better than what is already existent. Even if it is working, it is still not matured then.
    1.45 +Such a redesign can fail at many points and it is for long unclear if the result is really better than the code that is already existent. Even if the new code is working like expected, it is still not matured.
    1.46  
    1.47 -One thing is clear: Starting a redesign and rebuild \emph{is} a risky decision.
    1.48 +One thing is clear: Doing a redesign and rebuild \emph{is} a risky decision.
    1.49  
    1.50  
    1.51  
    1.52  \subsubsection*{Existing code is precious}
    1.53  
    1.54 -If a new design needs much effort and additionally is a risk, what about the alternative then?
    1.55 +If a new design needs much effort and additionally is a risk, what about the existing code base then?
    1.56  
    1.57 -Adding new functionality to an existing code base seems to be a secure and cheap strategy. The existing code is known to work and features can often be added in small increments. The risk of wasted effort if a new design fails is hardly existent. And the faults in the current design are already made and most probably fixed.
    1.58 +Adding new functionality to an existing code base seems to be a secure and cheap strategy. The existing code is known to work and features can often be added in small increments. Risks like wasted effort if a new design fails are hardly existent. And the faults in the current design are already made and most probably fixed.
    1.59  
    1.60 -Also functionality that is hard to add incrementally into the application, like support for new protocols, may be addable by ``translation programs'' to the outside. \masqmail\ can be secured to a huge amount by guarding it with wrappers that block attackers. Spam and malware scanners can be included by running two instances of \masqmail. All those methods base on the current code which they can indirectly improve.
    1.61 +And functionality that is hard to add incrementally into the application, like support for new protocols, may be addable by ``translation programs'' to the outside. \masqmail\ can be secured to a huge amount by guarding it with wrappers that block attackers. Spam and malware scanners can be included by running two instances of \masqmail. All those methods base on the current code which they can indirectly improve.
    1.62  
    1.63 -The required effort is probably under thirty percent of a new design and work directly shows results. These are strong arguments against a new design.
    1.64 +The required effort is probably under one third of a new design and work directly shows results. These are strong arguments against a new design.
    1.65  
    1.66  
    1.67 -%XXX
    1.68 +
    1.69  
    1.70  \subsubsection*{Repairing}
    1.71  
    1.72 -Repair strategies are only useful in the short time view and in times of trouble. But if the future is bright, one does best by investing. Here it means investing time in redesigning to build up a more modern product. cf. ch02: the future is bright!
    1.73 +Besides these advantages of existing code, one must not forget that further work on it is often repair work. Small bug fixes are not the problem, but adding something for which the software originally was not designed for are problems. Such work often destroys the clear concepts of the software, especially in interweaved monolithic code.
    1.74  
    1.75 -\masqmail\ should have already been redesigned in 2002 or so, when the old design was still quite suitable ... it already delayed too long.
    1.76 +Repair strategies are useful, but only in the short-time view and in times of trouble. If the future is bright, however, one does best by investing into a software. As shown in section \ref{sec:market-analysis-conclusion}, the future for \MTA{}s is bright, currently. This means it is time to invest into a redesigning to build up a more modern product.
    1.77  
    1.78 -Clinging to much to existing code will be no help, it is an indicator for fear. Having the courage to through bad code away to make it better, shows the view forward.
    1.79 +In the author's view is \masqmail\ already needing a redesign since about 2003 when the old design was still quite suitable \dots\ it already delayed too long.
    1.80  
    1.81 -Further development on base of current code needs to improve the quality properties too. Some quality requirements can be achieved by adding wrappers or interposition filters from the outside. For those is the development effort approximately equal to a solution by new design. But for quality requirements like extendability or maintainability, the effort does increase with expotentionel rate as development proceeds. But without those properties development of a software will most likely come to a dead end.
    1.82 +%Clinging to much to existing code will be no help, it is an indicator for fear. Having the courage to through bad code away to make it better, shows the view forward.
    1.83 +
    1.84 +Anyway, further development on base of current code needs to improve the quality properties too. Some quality requirements can be satisfied by adding wrappers or interposition filters from the outside. For those is the development effort approximately equal to a solution with a new design. But for adding quality requirements like extendability or maintainability which affect the source code throughout, the effort does increase with exponential rate as development proceeds. In case these properties get not improved, development will likely come to a dead end sooner or later.
    1.85  
    1.86  
    1.87  
    1.88 @@ -548,12 +548,13 @@
    1.89  
    1.90  \subsubsection*{A guard against dead ends}
    1.91  
    1.92 -But a new design does also protect against dangers. Changing requirements are a risk for software if it does not evolve with them. A famous example is \sendmail, which had nearly a monopoly for a long time. But when security became important \sendmail\ was only repaired, instead of removing the problem sources. Thus security problems reappeared and over the years \sendmail's market share shrinked as more secure \MTA{}s became available. %fixme: declined ??
    1.93 -\sendmail's reaction to the changed requirements, in form of \name{sendmail X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s.
    1.94 +A new design does protect against such dead ends.
    1.95  
    1.96 -Redesigning a software as requirements change helps keeping it alive. % add quote: ``one thing surely remains: change'' (something like that)
    1.97 +Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail, which had an almost monopoly for a long time. But when security became important \sendmail\ was only repaired instead of removing the problem sources---its unsecure design. Thus security problems reappeared and over the years \sendmail's market share shrinked as more secure \MTA{}s became available. %fixme: declined ??
    1.98 +\sendmail's reaction to the new requirements, in form of \name{sendmail X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s. Redesigning a software as requirements change helps keeping it alive. % add quote: ``one thing surely remains: change'' (something like that)
    1.99  
   1.100 -Another danger is complexity which is likely to appear by constantly working on the same code base. It is even more likely if the code base has a monolithic architecture. A good example for simplicity is \qmail\ which consists of small independent modules, each with only about one thousand lines of code. Such simple code makes it obvious to understand what it does. The \name{suckless} project \citeweb{suckless.org} advertizes a philosophy of small and simple software by following the thoughts of the \unix\ inventors \cite{kernighan84} \cite{kernighan99}. Simple, small, and clear code reduces bugs and, as the code function becomes obvious, it is a large step towards security.
   1.101 +Another danger is the dead end of complexity which is likely to appear by constantly working on the same code base. It is even more likely if the code base has a monolithic architecture. A good example for simplicity is \qmail\ which consists of small independent modules, each with only about one thousand lines of code. %fixme: proof
   1.102 +Such simple code makes it obvious to understand what it does. The \name{suckless} project \citeweb{suckless.org} for example advertizes such a philosophy of small and simple software by following the thoughts of the \unix\ inventors \cite{kernighan84} \cite{kernighan99}. Simple, small, and clear code avoids complexity and is thus also a strong prequisite for security.
   1.103  
   1.104  
   1.105  
   1.106 @@ -561,27 +562,25 @@
   1.107  
   1.108  \subsubsection*{Modularity}
   1.109  
   1.110 -The (by design) modular structure makes it also easy to add further functionality. \person{Sill} for example describes integrating the \name{amavis} filter framework into the \qmail\ system can be done by renaming the \name{qmail-queue} module to \name{qmail-queue-real} and renaming the \name{amavis} to \name{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in \qmail\ needs to be changed. This is a very admirable approach, but only possible in a modular system that consists of independent executables.
   1.111 +The avoidence of dead ends is essential for further development on current code too. Hence it is mandatory to refactor the existing code base sooner or later. Most important is the intention to modularize it, as it improves many quality requirements, eases further development, and essentially improves securtiy.
   1.112  
   1.113 -Extendability does suffer from the monolithic architecture and is nearly impossible to improve without changing the programs structure. This property can hardly be retrofitted into software. Extendability is expected become important in the future as new protocols need to be supported.
   1.114 +One example how modular structure makes it easy to add further functionality: \person{Sill} describes that integrating the \name{amavis} filter framework into the \qmail\ system can be done by renaming the \name{qmail-queue} module to \name{qmail-queue-real} and renaming the \name{amavis} to \name{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in the \qmail\ system needs to be changed. This is a very admirable approach, but only possible in a modular system that consists of independent executables.
   1.115  
   1.116 +This thesis showed several times that modularity is the key property for good software design. This property can hardly be retrofitted into software. Hence development on base of current code will need a throughout restructuring too to modularize the source code. Thus a new design is similar to such a throughout refactoring, except without depending on current code.
   1.117  
   1.118 -Hence, to be able to develop \masqmail\ for a long time, it is a must to refactor the existing code with the intention to modularize it. A new design is similar to such a throughout refactoring, except without basing on current code.
   1.119  
   1.120  
   1.121  
   1.122  
   1.123  
   1.124 +\subsubsection*{Function versus quality}
   1.125  
   1.126 +Remarkable is the distribution of functional and non-functional requirements to the strategies. The strategies for current code (\St1+2) have a functional to non-functional ratio of 10 to 3. The new design strategy (\St3) has a ratio of 5 to 12.
   1.127  
   1.128 +This leaves current code to be better suited for adding functionality, and a new design to be better suited for quality improvements. Both strategies need to improve function as well as quality, but the difference determines the focus of the strategy.
   1.129  
   1.130 -\subsubsection*{Split between function and quality}
   1.131 -
   1.132 -Remarkable is the distribution of the score points between functional and non-functional requirements. S1 (Improve current code) gets most points from functional requirements. Thus it is the best strategy to improve them. S3 (New design), in contrast, scores high for non-functional requirements. Thus it is best chosen to improve the software's quality. S2 (Wrappers and interposition filters) is balanced.
   1.133 -
   1.134 -a question of order:
   1.135 -- repair: first function, then quality
   1.136 -- redesign: first quality, then function
   1.137 +Easier work is likely to be done earlier in Free Software projects than hard work. Thus by choosing \St1+2 volunteer developers tend to implement function first and delay quality improvements, no matter what the suggested order is. \St3 in contrast would support %fixme: beguenstigen
   1.138 +early quality improvements and later function improvements. This is real-life experience in Free Software development.
   1.139  
   1.140  
   1.141  
   1.142 @@ -590,39 +589,38 @@
   1.143  
   1.144  \subsubsection*{The break even}
   1.145  
   1.146 -The effort needed is much smaller than for a new design plus improvements on the first view. But to have similar quality properties in four years, a \masqmail\ that is based on current code will probably require as much effort as a new designed \masqmail\ will take. For all further development afterwards, the new design will scale nearly linear while the old code will require exponentiell more work.
   1.147 +It is important to keep the time dimension in mind. This includes the  separation into a short-time and a long-time view. The short-time view shall cover between two and four years. The long-time view is the following time. % fixme: find sources!
   1.148  
   1.149 -It \emph{is} important to design from scratch somewhen! But when?
   1.150 +In the short-time view, the effort for improving the existing code is much smaller than the effort for a new design plus improvements. But to have similar quality properties at the end of the short-time frame, a \masqmail\ that is based on current code will probably require nearly as much effort as a new designed \masqmail\ will take. For all further development afterwards, the new design will scale well while the old code will require exponentiel more work.
   1.151 +
   1.152 +In the long-time view, a restructuring for modularity is necessary anyway. The question is, when to do it: Right at the start in a new design, or later in some restructuring.
   1.153  
   1.154  
   1.155  
   1.156  
   1.157  \subsubsection*{The problem with ``good enough''}
   1.158  
   1.159 -do not try to safe obsolete stuff. This will not work (see sendmail).
   1.160 +The decision for later restructuring is problematic. Functionality is often more wanted than quality, so further function is prefered over better quality, as quality is still ``good enough''. But it might be still ``good enough'' the next time, and the time after that one, and so on.
   1.161  
   1.162 -It is often done in commercial software, when it's about making money. Free software with volunteer programmers in contrast care about good software..
   1.163 +Quality improving is no popular work but it is required to avoid dead ends. As more code increases quality and modularity improvement work, it is better to do it early. Afterwards all further development profits from it.
   1.164  
   1.165 -If the design is bad, one should never hesitate to abandonne obsolete stuff and build it from scratch. (cf. makefiles and tab).
   1.166 +Also if some design is bad one should never hesitate to erase it and rebuild it in a sane way.
   1.167  
   1.168 -But making a cut is hard, as it is still ``good enough''.
   1.169 +However, making such a cut is hard, especially if the bad design is still ``good enough''.
   1.170  
   1.171 -(It already is too late.)
   1.172  
   1.173  
   1.174  
   1.175  
   1.176  \subsubsection*{Bonus: Good software, good feelings}
   1.177  
   1.178 -repairing leaves a worse feeling. Free Software ``sells'' if it has a good userbase. Although qmail is somehow outdated and its author has released no new version since about 10 years, qmail has a very strong userbase and community.
   1.179 +One last argument shall be added. It is more common for Free Software but can be seen in non-free software too.
   1.180  
   1.181 -Good design, concepts and philosophy gives users good feelings and faith for the software. They become interested in using it and to contribute.
   1.182 +Free Software ``sells'' if it has a good user base. Although \qmail\ is somehow outdated and its author has released no new version since about 10 years, \qmail\ still has a very strong user base and community.
   1.183  
   1.184 +Good concepts, sound design, and a sane philosophy gives users good feelings for the software and faith in it. They become interested in using it and to contribute. In contrast does constantly repairing and reappearing weaknesses leave a bad feeling.
   1.185  
   1.186 -
   1.187 -The goal is good software. The wish to do good work is the motivation volunteers have. Work plans that lead to a good product will motivate volunteers to help with it. Hence more helpers may make the 2,5 man years for the new design, even become less absolute time than, few helping people that try to improve the existing code.
   1.188 -
   1.189 -
   1.190 +The motivation most volunteer developers have is their wish of doing good work to create software of value. Projects that follow admireable plans towards a good product will motivate volunteers to help with it. More helpers can get the 2,5 man-years for a new design in less absolute time done. Additionally is a good developers base the best start for a good user base, and users define a software's value.
   1.191  
   1.192  
   1.193  
   1.194 @@ -633,6 +631,13 @@
   1.195  
   1.196  \section{Result}
   1.197  
   1.198 +
   1.199 +what stands against the new design? 
   1.200 +- dev time/effort
   1.201 +- risk of failure
   1.202 +- time delay
   1.203 +
   1.204 +
   1.205  A program's structure is primary its architecture. Which is the most influencing design decision, and has the greatest impact on the program's future capabilities. The architecture defines what the program can do, and how it can be used. If the architecture does not fit to the requirements, development will reach a dead end \dots\ further work then will make everything worse. The only good solution then is to change the architecture, which, sadly but most likely, means a redesign from scratch.
   1.206  
   1.207  The most needed features---authentication and encryption---can be added to the current code base with changes in only few parts of the source. These changes should be made soon. Archiving of mail is another feature to add then. More complete logging coverage, reporting of unsafe environment, and fixing high risk security flaws are quality improvements to do. All this work should be done on basis of the current code.