# HG changeset patch # User meillo@marmaro.de # Date 1226682794 -3600 # Node ID 4fabc8ac55382c4dff65f0f47c30ee52b77bd530 # Parent 62d24bf36a5f4d7f32961bf8232cb7e6790aa063 excluded text about history of masqmail and about free software projects diff -r 62d24bf36a5f -r 4fabc8ac5538 thesis/pieces/free-software-projects.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/thesis/pieces/free-software-projects.tex Fri Nov 14 18:13:14 2008 +0100 @@ -0,0 +1,128 @@ +\section{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. + +\subsection{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} + + +\subsection{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 + + +\subsection{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. + + +\subsection{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. + + +\subsection{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. + + +\subsection{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 62d24bf36a5f -r 4fabc8ac5538 thesis/pieces/masqmail-history.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/thesis/pieces/masqmail-history.tex Fri Nov 14 18:13:14 2008 +0100 @@ -0,0 +1,27 @@ +\section{History} +%TODO: let oliver prove read it! +%FIXME: add references +%FIXME: where does the name come from: masqdialer (guessed) + +The date of the first release (version 0.0.1) is unknown. +The only information available is, that it was packaged for \debian\ at 15\nth\ of September in 1999. +Further releases were made every few weeks or month during 2000, 2001 and 2002. +Development ended in mid-2003 in a hard stop. +The last ordinary release known to me is version 0.2.20, released on 4\nth\ of June in 2003. + +During the time of development, Oliver released 53 versions. +That means a new release in less than every 20 days in average! + +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. + +One extra release (version 0.2.21) was made by him in November 2005. +This one is only available from the \debian\ pool. +Comparing it to version 0.2.20 shows, that no source code was altered. +Only building documents (like Makefiles) and \debian\ packageing documents were changed. +That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package. + +In May 2000 the minor version number increased to `1'. +Nothing special is mentioned in the documentation about that. +When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail. +At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series. +His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.