mypapers/free-sw-devel/free-sw-devel3.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 - community and technology</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-devel3.html">http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel3.html</a></tt></p>
  17
  18     <div class="presenter">Petter Reinholdtsen
  19       <br>pere@hungry.com
  20       <br>IFI/UiO,  2010-11-11</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 sucks.  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>Learn to use the available tools</h2>
 130
 131     <p>There are heaps of useful tools to make the development work
 132       easier and safer as well as to increase the quality.</p>
 133
 134     <p>Examples include
 135     <ul>
 136       <li>version control systems (cvs, svn, git, bzr, etc)</li>
 137       <li>coding environment (emacs, eclipse, etc)</li>
 138       <li>build tools (gcc, jdk, make, autotools, etc)</li>
 139       <li>debugging tools (gdb, ddd, valgrind, etc)</li>
 140       <li>profiling tools (kcachegrind, kprof, etc)</li>
 141       <li>test suite frameworks (dejagnu, junit, etc)</li>
 142     </ul>
 143 <!--
 144     <h2>Joining a free software project</h2>
 145     <ul>
 146
 147     <li>start by checking out the bugs in the bts
 148     <li>try to fix them
 149
 150     <li>give feedback into the bts on the reported bugs, after trying
 151     to reproduce them.
 152
 153     <li>go through the user documentation, and submit suggestions for
 154     improvement
 155
 156     <li>be active on the mailing lists, provide answers to the
 157     questions (and use references tot he user documentation, to save
 158     everybody some work)
 159
 160     <li>make sure the code you write is self documenting, follow the
 161     code policy and include enough comments to make the purpose of the
 162     code easy to understand.
 163     </ul>
 164 -->
 165     <h2>Starting a free software project</h2>
 166
 167     <p>I got this idea for a piece of software...</p>
 168
 169     <ul>
 170
 171       <li>reuse when possible, prefer to improve existing
 172       projects</li>
 173
 174       <li>read other peoples code, download and test other peoples
 175       programs</li>
 176
 177       <li>understand software licenses
 178
 179       <li>consider sourceforge
 180
 181     </ul>
 182
 183     <p>This software sucks.  A lot! - Do not take it personally.</p>
 184
 185     <h2>Use the best free development tools available</h2>
 186
 187     <ul>
 188       <li>compile with lots of warnings
 189       <li>use existing libraries, but avoid to many dependencies
 190
 191       <li>learn to use debugging utilities (gdb, ddd, dmalloc,
 192         valgrind, strace, ltrace, electric fence, fncchk, etc)
 193       <li>learn to use profiling tools (kprof, gprof, etc)
 194       <li>write automatic self testing
 195
 196       <li>do automatic coverage testing to check the quality of the
 197         self test
 198
 199     </ul>
 200
 201     <h2>Running a successful free software project I</h2>
 202
 203     <ul>
 204
 205       <li>be responsive to comments and suggestions
 206       <li>write down where you want the project to go
 207       <li>do not accept every change.  make sure you like it first
 208
 209       <li>let everyone work on the things that interests them, use the
 210       carrot, as you have no whip
 211       <li>set up and use a bts
 212
 213     </ul>
 214
 215     <h2>Running a successful free software project II</h2>
 216
 217     <ul>
 218
 219       <li>create web pages for your project, include screen shots, a
 220       short summary and who to contact for more info
 221
 222       <li>remember to include a README file in the tarball.  it should
 223       include the home page URL, the download site URL,
 224       a short description of the project and where to send bug reports
 225       and patches</li>
 226       <li>involve the public mailing lists in the decision making
 227       <li>automate everything
 228
 229       <li>set up system for public review of changes (anonymous CVS,
 230       commit emails)
 231       <li>communicate the intention behind the choice of license
 232     </ul>
 233
 234     <h2>As the project grows larger</h2>
 235
 236     <p>Leading by example is your only option.</p>
 237
 238     <ul>
 239
 240       <li>communicate the project plan to all project members
 241       <li>try to reduce friction and avoid hard language
 242       <li>keep track of what everyone is working on
 243     </ul>
 244
 245     <h2>Conclusion</h2>
 246
 247     <ul>
 248
 249       <li>working on free software is very rewarding and challenging
 250
 251       <li>nobody owns you a favour, get used to it
 252
 253       <li>do it for your own gain, not to get rewards from others
 254
 255     </ul>
 256
 257     <h2>References</h2>
 258
 259     <ul>
 260
 261       <li>"The Practice of Programming" by Kernighan and Pike.
 262
 263       <li>"<a href="http://opensource.mit.edu/online_paper">Free /
 264       Open Source Research Community - online papers</a>,
 265       <tt>http://opensource.mit.edu/online_paper</tt></li>
 266
 267     </ul>
 268
 269     <h2>Thank you very much</h2>
 270
 271     <h3>Questions?</h3>
 272
 273   </body>
 274 </html>