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