docs/diploma

annotate thesis/pieces/free-software-projects.tex @ 184:b0adae481138

moved content
author meillo@marmaro.de
date Mon, 29 Dec 2008 14:05:24 +0100
parents
children
rev   line source
meillo@91 1 \section{About \freesw\ projects}
meillo@91 2
meillo@91 3 % http://www.faqs.org/docs/artu/
meillo@91 4
meillo@91 5 There are several differences between \freesw\ projects and projects about proprietary software.
meillo@91 6 To understand \freesw\ projects, one needs to understand \freesw\ itself first.
meillo@91 7
meillo@91 8 \subsection{About \freesw}
meillo@91 9 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.
meillo@91 10 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.
meillo@91 11 One could say, the \GPL\ catalized the \name{Free Software movement}.
meillo@91 12
meillo@91 13 % http://www.fsf.org/about/what-is-free-software
meillo@91 14
meillo@91 15 After all, the \GPL\ was not the first \freesw\ license used.
meillo@91 16 The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
meillo@91 17 Licenses providing the same rights have been used since long time ago.
meillo@91 18 But none of them was so often (re)used by other projects---thus gattering less awareness.
meillo@91 19 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.
meillo@91 20
meillo@91 21 \freesw\ gives freedoms to its users.
meillo@91 22 In contrast to proprietary software restricting the users freedom.
meillo@91 23 The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
meillo@91 24 % http://www.gnu.org/philosophy/free-sw.html
meillo@91 25 % http://www.fsf.org/licensing/essays/free-sw.html
meillo@91 26 \begin{enumerate}
meillo@91 27 \item The freedom to run the program, for any purpose (freedom 0).
meillo@91 28 \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.
meillo@91 29 \item The freedom to redistribute copies so you can help your neighbor (freedom 2).
meillo@91 30 \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.
meillo@91 31 \end{enumerate}
meillo@91 32
meillo@91 33
meillo@91 34 \subsection{The term ``Open Source''}
meillo@91 35 \name{Open Source Software} often stands for the same as \freesw.
meillo@91 36 But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
meillo@91 37
meillo@91 38 \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.
meillo@91 39
meillo@91 40 % http://www.gnu.org/philosophy/open-source-misses-the-point.html
meillo@91 41 % http://catb.org/~esr/open-source.html
meillo@91 42
meillo@91 43
meillo@91 44 \subsection{Development of \freesw}
meillo@91 45 Having source code available and the right to modify it, encouridges programmers to actually do so.
meillo@91 46 Their modifications are manifoldly.
meillo@91 47 Some tailor the software to their needs.
meillo@91 48 Some add features.
meillo@91 49 Some do it just for fun.
meillo@91 50 There are no limitations---whoever wants to, may work on it.
meillo@91 51
meillo@91 52 Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
meillo@91 53 The process of development is watchable by everyone.
meillo@91 54
meillo@91 55 The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
meillo@91 56
meillo@91 57 Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
meillo@91 58
meillo@91 59 The following text will focus on the ``bazaar'' model.
meillo@91 60
meillo@91 61
meillo@91 62 \subsection{The role of the community}
meillo@91 63 \freesw\ projects rise and fall with their community!
meillo@91 64
meillo@91 65 Most \freesw\ programs are developed by a very small group of programmers, often only one person.
meillo@91 66 But they are used by many people.
meillo@91 67 In between the programmers and the users, are people located who are a bit of both.
meillo@91 68 These are the ones that write documentation, find bugs and probably even fix it.
meillo@91 69 They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
meillo@91 70 The program is often spread by their ``advertising''.
meillo@91 71
meillo@91 72 The \emph{community} consists of the actual developers and all users that contribute to the program.
meillo@91 73 Contribution can be one of the described ways, or others like providing a server for the project website for example.
meillo@91 74
meillo@91 75 \emph{Community} is everyone who is in contact through the project.
meillo@91 76 Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
meillo@91 77
meillo@91 78 There will hardly be a community if no communication channels are available.
meillo@91 79 If the development team does not provide them, there is a chance that encouraged users set them up on their own.
meillo@91 80 But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
meillo@91 81
meillo@91 82 Projects without a good community tend to die sooner or later.
meillo@91 83
meillo@91 84
meillo@91 85 \subsection{Evolution of a community}
meillo@91 86 Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
meillo@91 87 He starts developing.
meillo@91 88 When others get in contact with the project, there may be some who are so much interested that they start co-developing.
meillo@91 89 Others report bugs, and some only use the program.
meillo@91 90
meillo@91 91 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.
meillo@91 92 The size ratio of the groups vary by type of project.
meillo@91 93
meillo@91 94 One should have that in mind, when starting a \freesw\ project.
meillo@91 95
meillo@91 96
meillo@91 97 \subsection{Creating a strong community}
meillo@91 98 Building up a good community needs some effort of the main developers.
meillo@91 99 %TODO: search for documents about this topic
meillo@91 100
meillo@91 101 First communication channels need to be set up, to enable the growth of a community.
meillo@91 102
meillo@91 103 Second, development should be visible by everyone who is interested in it.
meillo@91 104 Time between work done on the project and its visibility to the public should be kept short.
meillo@91 105 This makes it interesting for other developers to join.
meillo@91 106 Developers are the core of a community.
meillo@91 107
meillo@91 108 Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
meillo@91 109 Releases are (more) stable versions, primary for users.
meillo@91 110 They should be created, frequently.
meillo@91 111 People will more likely use programs of active projects.
meillo@91 112
meillo@91 113 Fourth, the developers should try to get the users ``in the boat''.
meillo@91 114 Good communities have a large group of users that do not only receive, but also give something back to the project.
meillo@91 115 The project leaders should motivate users to contribute.
meillo@91 116 This unlocks a big work force and gets lot of unexiting work done.
meillo@91 117
meillo@91 118 Fifth, documentation matters.
meillo@91 119 Good documentation makes it easy for users and developers to start.
meillo@91 120 And it helps to avoid a lot of unsatisfaction.
meillo@91 121 Documentation is something that shows quality and that people care about the project.
meillo@91 122
meillo@91 123 And sixth, project leaders should be good souvereigns.
meillo@91 124 They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
meillo@91 125
meillo@91 126 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!
meillo@91 127 Volunteer work lives by acknowledgement of the effort spent.
meillo@91 128