]> pere.pagekite.me Git - homepage.git/blob - mypapers/free-sw-devel/free-sw-devel.html
Generated.
[homepage.git] / mypapers / free-sw-devel / free-sw-devel.html
1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2 <html>
3 <head>
4 <link rel="stylesheet" href="../mrtg-td/slides.css" type="text/css">
5 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
6 <meta name="Language" content="en">
7 <meta name="Author" content="Petter Reinholdtsen">
8 </head>
9 <body>
10
11 <h1>Free software development for beginners</h1>
12
13 <p>An introduction to free software development, for those
14 interested in participating.</p>
15
16 <p><tt><a href="http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel.html">http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel.html</a></tt></p>
17
18 <div class="presenter">Petter Reinholdtsen
19 <br>pere@hungry.com
20 <br>IFI/UiO, Forskningsparken rom 207 2004-04-27</div>
21
22 <h2>Who am I</h2>
23
24 <ul>
25
26 <li>been involved in free software development since 1992</li>
27
28 <li>programmer and system administrator</li>
29
30 <li>past and current contributor to several projects (linux,
31 glibc, kde, debian-{edu, gis, java, cdd}, mapserver,
32 openstreetmap.org, skolelinux, etc)</li>
33
34 <li>debian developer</li>
35
36 <li>initiator and current tech coordinator in skolelinux</li>
37
38 <li>currently employed at USIT, UiO</li>
39
40 </ul>
41
42 <h2>Free Software - user freedom</h2>
43
44 <ul>
45
46 <li>freedom to run the program as you wish for any purpose</li>
47 <li>freedom to study and change the source code as you wish</li>
48 <li>freedom to make and redistribute copies</li>
49 <li>freedom to publish modified versions</li>
50
51 </ul>
52
53 <p><em>Richard M. Stallmann, FSF</em></p>
54
55 <h2>Getting involved and helping out</h2>
56
57 <p>So, you found a nice project on
58 <a href="http://freshmeat.net/">Freshmeat</a>, and want to help
59 improve it...</p>
60
61 <ul>
62
63 <li>get used to public review
64 <li>read the project documentation
65 <li>join the relevant mailing list, IRC channels, etc
66 <li>use mailing lists
67 <li>update the wiki
68 <li>get to know the source
69 <li>understand licensing issues
70 <li>learn to use the bug tracking system (bts)
71 <li>start with the non-coding stuff (translations, documentation)
72 <li>do not take it personally
73
74 </ul>
75
76 <h2>Reporting bugs</h2>
77
78 <p>This software suck. A lot!</p>
79
80 <ul>
81
82 <li>test if the bug exist the latest version
83
84 <li>do not report duplicate bugs, check the bts and mailing
85 lists
86
87 <li>document how to reproduce the bug, and include relevant
88 information. get output from valgrind, strace, gdb and
89 ltrace.
90
91 <li>include info on possible workarounds, and patches if you
92 can.</li>
93
94 <li>add more info if the bug is already reported
95
96 <li>use the relevant bug reporting tool, such as bug-buddy (Gnome),
97 perlbug (Perl), reportbug (Debian) and sendpr (FreeBSD) or
98 use the projects bug reporting web site (bugzilla, request-tracker,
99 gnats, etc. check the project home page)
100
101 <li>remember to follow up your bug report.
102
103 </ul>
104
105 <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306147">an
106 example</a>
107
108 <h2>Submitting patches</h2>
109
110 <p>Fixing the problem is only half the work.</p>
111
112 <ul>
113 <li>if you can fix the problem you are facing, remember to let
114 the package author know about this.
115 <li>make a patch! (<tt>diff -u file.orig file.new >
116 myfix.diff</tt>)
117 <li>send the patch to the developer list, or possibly into the
118 bts (learn how the developers want it)
119
120 <li>do not forget to follow up the patch. Accept commend and
121 improve it until it is accepted by the developers.
122
123 <li>if you don't make sure the patch is accepted by the
124 developers, you will have to fix the same problem every time you
125 upgrade.
126
127 </ul>
128
129 <h2>Joining a free software project</h2>
130 <ul>
131
132 <li>start by checking out the bugs in the bts
133 <li>try to fix them
134
135 <li>give feedback into the bts on the reported bugs, after trying
136 to reproduce them.
137
138 <li>go through the user documentation, and submit suggestions for
139 improvement
140
141 <li>be active on the mailing lists, provide answers to the
142 questions (and use references tot he user documentation, to save
143 everybody some work)
144
145 <li>make sure the code you write is self documenting, follow the
146 code policy and include enough comments to make the purpose of the
147 code easy to understand.
148 </ul>
149
150 <h2>Starting a free software project</h2>
151
152 <p>I got this idea for a piece of software...</p>
153
154 <ul>
155
156 <li>reuse when possible, prefer to improve existing
157 projects</li>
158
159 <li>read other peoples code, download and test other peoples
160 programs</li>
161
162 <li>understand software licenses
163
164 <li>consider sourceforge
165
166 </ul>
167
168 <p>This software suck. A lot! - Do not take it personally.</p>
169
170 <h2>Use the best free development tools available</h2>
171
172 <ul>
173 <li>compile with lots of warnings
174 <li>use existing libraries, but avoid to many dependencies
175
176 <li>learn to use debugging utilities (gdb, ddd, dmalloc,
177 valgrind, strace, ltrace, electric fence, fncchk, etc)
178 <li>learn to use profiling tools (kprof, gprof, etc)
179 <li>write automatic self testing
180
181 <li>do automatic coverage testing to check the quality of the
182 self test
183
184 </ul>
185
186 <h2>Running a successful free software project I</h2>
187
188 <ul>
189
190 <li>be responsive to comments and suggestions
191 <li>write down where you want the project to go
192 <li>do not accept every change. make sure you like it first
193
194 <li>let everyone work on the things that interests them, use the
195 carrot, as you have no whip
196 <li>set up and use a bts
197
198 </ul>
199
200 <h2>Running a successful free software project II</h2>
201
202 <ul>
203
204 <li>create web pages for your project, include screen shots, a
205 short summary and who to contact for more info
206
207 <li>remember to include a README file in the tarball. it should
208 include the home page URL, the download site URL,
209 a short description of the project and where to send bug reports
210 and patches</li>
211 <li>involve the public mailing lists in the decision making
212 <li>automate everything
213
214 <li>set up system for public review of changes (anonymous CVS,
215 commit emails)
216 <li>communicate the intention behind the choice of license
217 </ul>
218
219 <h2>As the project grows larger</h2>
220
221 <p>Leading by example is your only option.</p>
222
223 <ul>
224
225 <li>communicate the project plan to all project members
226 <li>try to reduce friction and avoid hard language
227 <li>keep track of what everyone is working on
228 </ul>
229
230 <h2>Conclusion</h2>
231
232 <ul>
233
234 <li>working on free software is very rewarding and challenging
235
236 <li>nobody owns you a favour, get used to it
237
238 <li>do it for your own gain, not to get rewards from others
239
240 </ul>
241
242 <h2>References</h2>
243
244 <ul>
245
246 <li>"The Practice of Programming" by Kernighan and Pike.
247
248 <li>"<a href="http://opensource.mit.edu/online_paper">Free /
249 Open Source Research Community - online papers</a>,
250 <tt>http://opensource.mit.edu/online_paper</tt></li>
251
252 </ul>
253
254 <h2>Thank you very much</h2>
255
256 <h3>Questions?</h3>
257
258 </body>
259 </html>