1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/thesis/pieces/free-software-projects.tex	Fri Nov 14 18:13:14 2008 +0100
     1.3 @@ -0,0 +1,128 @@
     1.4 +\section{About \freesw\ projects}
     1.5 +
     1.6 +% http://www.faqs.org/docs/artu/
     1.7 +
     1.8 +There are several differences between \freesw\ projects and projects about proprietary software.
     1.9 +To understand \freesw\ projects, one needs to understand \freesw\ itself first.
    1.10 +
    1.11 +\subsection{About \freesw}
    1.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.
    1.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.
    1.14 +One could say, the \GPL\ catalized the \name{Free Software movement}.
    1.15 +
    1.16 +% http://www.fsf.org/about/what-is-free-software
    1.17 +
    1.18 +After all, the \GPL\ was not the first \freesw\ license used.
    1.19 +The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
    1.20 +Licenses providing the same rights have been used since long time ago.
    1.21 +But none of them was so often (re)used by other projects---thus gattering less awareness.
    1.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.
    1.23 +
    1.24 +\freesw\ gives freedoms to its users.
    1.25 +In contrast to proprietary software restricting the users freedom.
    1.26 +The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
    1.27 +% http://www.gnu.org/philosophy/free-sw.html
    1.28 +% http://www.fsf.org/licensing/essays/free-sw.html
    1.29 +\begin{enumerate}
    1.30 +	\item The freedom to run the program, for any purpose (freedom 0).
    1.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.
    1.32 +	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
    1.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.
    1.34 +\end{enumerate}
    1.35 +
    1.36 +
    1.37 +\subsection{The term ``Open Source''}
    1.38 +\name{Open Source Software} often stands for the same as \freesw.
    1.39 +But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
    1.40 +
    1.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.
    1.42 +
    1.43 +% http://www.gnu.org/philosophy/open-source-misses-the-point.html
    1.44 +% http://catb.org/~esr/open-source.html
    1.45 +
    1.46 +
    1.47 +\subsection{Development of \freesw}
    1.48 +Having source code available and the right to modify it, encouridges programmers to actually do so.
    1.49 +Their modifications are manifoldly.
    1.50 +Some tailor the software to their needs.
    1.51 +Some add features.
    1.52 +Some do it just for fun.
    1.53 +There are no limitations---whoever wants to, may work on it.
    1.54 +
    1.55 +Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
    1.56 +The process of development is watchable by everyone.
    1.57 +
    1.58 +The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
    1.59 +
    1.60 +Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
    1.61 +
    1.62 +The following text will focus on the ``bazaar'' model.
    1.63 +
    1.64 +
    1.65 +\subsection{The role of the community}
    1.66 +\freesw\ projects rise and fall with their community!
    1.67 +
    1.68 +Most \freesw\ programs are developed by a very small group of programmers, often only one person.
    1.69 +But they are used by many people.
    1.70 +In between the programmers and the users, are people located who are a bit of both.
    1.71 +These are the ones that write documentation, find bugs and probably even fix it.
    1.72 +They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
    1.73 +The program is often spread by their ``advertising''.
    1.74 +
    1.75 +The \emph{community} consists of the actual developers and all users that contribute to the program.
    1.76 +Contribution can be one of the described ways, or others like providing a server for the project website for example.
    1.77 +
    1.78 +\emph{Community} is everyone who is in contact through the project.
    1.79 +Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
    1.80 +
    1.81 +There will hardly be a community if no communication channels are available.
    1.82 +If the development team does not provide them, there is a chance that encouraged users set them up on their own.
    1.83 +But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
    1.84 +
    1.85 +Projects without a good community tend to die sooner or later.
    1.86 +
    1.87 +
    1.88 +\subsection{Evolution of a community}
    1.89 +Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
    1.90 +He starts developing.
    1.91 +When others get in contact with the project, there may be some who are so much interested that they start co-developing.
    1.92 +Others report bugs, and some only use the program.
    1.93 +
    1.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.
    1.95 +The size ratio of the groups vary by type of project.
    1.96 +
    1.97 +One should have that in mind, when starting a \freesw\ project.
    1.98 +
    1.99 +
   1.100 +\subsection{Creating a strong community}
   1.101 +Building up a good community needs some effort of the main developers.
   1.102 +%TODO: search for documents about this topic
   1.103 +
   1.104 +First communication channels need to be set up, to enable the growth of a community.
   1.105 +
   1.106 +Second, development should be visible by everyone who is interested in it.
   1.107 +Time between work done on the project and its visibility to the public should be kept short.
   1.108 +This makes it interesting for other developers to join.
   1.109 +Developers are the core of a community.
   1.110 +
   1.111 +Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
   1.112 +Releases are (more) stable versions, primary for users.
   1.113 +They should be created, frequently.
   1.114 +People will more likely use programs of active projects.
   1.115 +
   1.116 +Fourth, the developers should try to get the users ``in the boat''.
   1.117 +Good communities have a large group of users that do not only receive, but also give something back to the project.
   1.118 +The project leaders should motivate users to contribute.
   1.119 +This unlocks a big work force and gets lot of unexiting work done.
   1.120 +
   1.121 +Fifth, documentation matters.
   1.122 +Good documentation makes it easy for users and developers to start.
   1.123 +And it helps to avoid a lot of unsatisfaction.
   1.124 +Documentation is something that shows quality and that people care about the project.
   1.125 +
   1.126 +And sixth, project leaders should be good souvereigns.
   1.127 +They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
   1.128 +
   1.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!
   1.130 +Volunteer work lives by acknowledgement of the effort spent.
   1.131 +

     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/thesis/pieces/masqmail-history.tex	Fri Nov 14 18:13:14 2008 +0100
     2.3 @@ -0,0 +1,27 @@
     2.4 +\section{History}
     2.5 +%TODO: let oliver prove read it!
     2.6 +%FIXME: add references
     2.7 +%FIXME: where does the name come from: masqdialer (guessed)
     2.8 +
     2.9 +The date of the first release (version 0.0.1) is unknown.
    2.10 +The only information available is, that it was packaged for \debian\ at 15\nth\ of September in 1999.
    2.11 +Further releases were made every few weeks or month during 2000, 2001 and 2002.
    2.12 +Development ended in mid-2003 in a hard stop.
    2.13 +The last ordinary release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
    2.14 +
    2.15 +During the time of development, Oliver released 53 versions.
    2.16 +That means a new release in less than every 20 days in average!
    2.17 +
    2.18 +Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
    2.19 +
    2.20 +One extra release (version 0.2.21) was made by him in November 2005.
    2.21 +This one is only available from the \debian\ pool.
    2.22 +Comparing it to version 0.2.20 shows, that no source code was altered.
    2.23 +Only building documents (like Makefiles) and \debian\ packageing documents were changed.
    2.24 +That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
    2.25 +
    2.26 +In May 2000 the minor version number increased to `1'.
    2.27 +Nothing special is mentioned in the documentation about that.
    2.28 +When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail.
    2.29 +At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series.
    2.30 +His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.