docs/diploma
diff thesis/attic/free-software-projects.tex @ 272:2aad3d950640
renamed pieces -> attic
author | meillo@marmaro.de |
---|---|
date | Thu, 15 Jan 2009 12:20:21 +0100 |
parents | thesis/pieces/free-software-projects.tex@4fabc8ac5538 |
children |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/thesis/attic/free-software-projects.tex Thu Jan 15 12:20:21 2009 +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 +