+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+ <head>
+ <link rel="stylesheet" href="../mrtg-td/slides.css" type="text/css">
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+ <meta name="Language" content="en">
+ <meta name="Author" content="Petter Reinholdtsen">
+ </head>
+ <body>
+
+ <h1>Free software development - community and technology</h1>
+
+ <p>An introduction to free software development, for those
+ interested in participating.</p>
+
+ <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>
+
+ <div class="presenter">Petter Reinholdtsen
+ <br>pere@hungry.com
+ <br>IFI/UiO, 2010-11-11</div>
+
+ <h2>Who am I</h2>
+
+ <ul>
+
+ <li>been involved in free software development since 1992</li>
+
+ <li>programmer and system administrator</li>
+
+ <li>past and current contributor to several projects (linux,
+ glibc, kde, debian-{edu, gis, java, cdd}, mapserver,
+ openstreetmap.org, skolelinux, etc)</li>
+
+ <li>debian developer</li>
+
+ <li>initiator and current tech coordinator in skolelinux</li>
+
+ <li>currently employed at USIT, UiO</li>
+
+ </ul>
+
+ <h2>Free Software - user freedom</h2>
+
+ <ul>
+
+ <li>freedom to run the program as you wish for any purpose</li>
+ <li>freedom to study and change the source code as you wish</li>
+ <li>freedom to make and redistribute copies</li>
+ <li>freedom to publish modified versions</li>
+
+ </ul>
+
+ <p><em>Richard M. Stallmann, FSF</em></p>
+
+ <h2>Getting involved and helping out</h2>
+
+ <p>So, you found a nice project on
+ <a href="http://freshmeat.net/">Freshmeat</a>, and want to help
+ improve it...</p>
+
+ <ul>
+
+ <li>get used to public review
+ <li>read the project documentation
+ <li>join the relevant mailing list, IRC channels, etc
+ <li>use mailing lists
+ <li>update the wiki
+ <li>get to know the source
+ <li>understand licensing issues
+ <li>learn to use the bug tracking system (bts)
+ <li>start with the non-coding stuff (translations, documentation)
+ <li>do not take it personally
+
+ </ul>
+
+ <h2>Reporting bugs</h2>
+
+ <p>This software sucks. A lot!</p>
+
+ <ul>
+
+ <li>test if the bug exist the latest version
+
+ <li>do not report duplicate bugs, check the bts and mailing
+ lists
+
+ <li>document how to reproduce the bug, and include relevant
+ information. get output from valgrind, strace, gdb and
+ ltrace.
+
+ <li>include info on possible workarounds, and patches if you
+ can.</li>
+
+ <li>add more info if the bug is already reported
+
+ <li>use the relevant bug reporting tool, such as bug-buddy (Gnome),
+ perlbug (Perl), reportbug (Debian) and sendpr (FreeBSD) or
+ use the projects bug reporting web site (bugzilla, request-tracker,
+ gnats, etc. check the project home page)
+
+ <li>remember to follow up your bug report.
+
+ </ul>
+
+ <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306147">an
+ example</a>
+
+ <h2>Submitting patches</h2>
+
+ <p>Fixing the problem is only half the work.</p>
+
+ <ul>
+ <li>if you can fix the problem you are facing, remember to let
+ the package author know about this.
+ <li>make a patch! (<tt>diff -u file.orig file.new >
+ myfix.diff</tt>)
+ <li>send the patch to the developer list, or possibly into the
+ bts (learn how the developers want it)
+
+ <li>do not forget to follow up the patch. Accept commend and
+ improve it until it is accepted by the developers.
+
+ <li>if you don't make sure the patch is accepted by the
+ developers, you will have to fix the same problem every time you
+ upgrade.
+
+ </ul>
+
+ <h2>Learn to use the available tools</h2>
+
+ <p>There are heaps of useful tools to make the development work
+ easier and safer as well as to increase the quality.</p>
+
+ <p>Examples include
+ <ul>
+ <li>version control systems (cvs, svn, git, bzr, etc)</li>
+ <li>coding environment (emacs, eclipse, etc)</li>
+ <li>build tools (gcc, jdk, make, autotools, etc)</li>
+ <li>debugging tools (gdb, ddd, valgrind, etc)</li>
+ <li>profiling tools (kcachegrind, kprof, etc)</li>
+ <li>test suite frameworks (dejagnu, junit, etc)</li>
+ </ul>
+<!--
+ <h2>Joining a free software project</h2>
+ <ul>
+
+ <li>start by checking out the bugs in the bts
+ <li>try to fix them
+
+ <li>give feedback into the bts on the reported bugs, after trying
+ to reproduce them.
+
+ <li>go through the user documentation, and submit suggestions for
+ improvement
+
+ <li>be active on the mailing lists, provide answers to the
+ questions (and use references tot he user documentation, to save
+ everybody some work)
+
+ <li>make sure the code you write is self documenting, follow the
+ code policy and include enough comments to make the purpose of the
+ code easy to understand.
+ </ul>
+-->
+ <h2>Starting a free software project</h2>
+
+ <p>I got this idea for a piece of software...</p>
+
+ <ul>
+
+ <li>reuse when possible, prefer to improve existing
+ projects</li>
+
+ <li>read other peoples code, download and test other peoples
+ programs</li>
+
+ <li>understand software licenses
+
+ <li>consider sourceforge
+
+ </ul>
+
+ <p>This software suck. A lot! - Do not take it personally.</p>
+
+ <h2>Use the best free development tools available</h2>
+
+ <ul>
+ <li>compile with lots of warnings
+ <li>use existing libraries, but avoid to many dependencies
+
+ <li>learn to use debugging utilities (gdb, ddd, dmalloc,
+ valgrind, strace, ltrace, electric fence, fncchk, etc)
+ <li>learn to use profiling tools (kprof, gprof, etc)
+ <li>write automatic self testing
+
+ <li>do automatic coverage testing to check the quality of the
+ self test
+
+ </ul>
+
+ <h2>Running a successful free software project I</h2>
+
+ <ul>
+
+ <li>be responsive to comments and suggestions
+ <li>write down where you want the project to go
+ <li>do not accept every change. make sure you like it first
+
+ <li>let everyone work on the things that interests them, use the
+ carrot, as you have no whip
+ <li>set up and use a bts
+
+ </ul>
+
+ <h2>Running a successful free software project II</h2>
+
+ <ul>
+
+ <li>create web pages for your project, include screen shots, a
+ short summary and who to contact for more info
+
+ <li>remember to include a README file in the tarball. it should
+ include the home page URL, the download site URL,
+ a short description of the project and where to send bug reports
+ and patches</li>
+ <li>involve the public mailing lists in the decision making
+ <li>automate everything
+
+ <li>set up system for public review of changes (anonymous CVS,
+ commit emails)
+ <li>communicate the intention behind the choice of license
+ </ul>
+
+ <h2>As the project grows larger</h2>
+
+ <p>Leading by example is your only option.</p>
+
+ <ul>
+
+ <li>communicate the project plan to all project members
+ <li>try to reduce friction and avoid hard language
+ <li>keep track of what everyone is working on
+ </ul>
+
+ <h2>Conclusion</h2>
+
+ <ul>
+
+ <li>working on free software is very rewarding and challenging
+
+ <li>nobody owns you a favour, get used to it
+
+ <li>do it for your own gain, not to get rewards from others
+
+ </ul>
+
+ <h2>References</h2>
+
+ <ul>
+
+ <li>"The Practice of Programming" by Kernighan and Pike.
+
+ <li>"<a href="http://opensource.mit.edu/online_paper">Free /
+ Open Source Research Community - online papers</a>,
+ <tt>http://opensource.mit.edu/online_paper</tt></li>
+
+ </ul>
+
+ <h2>Thank you very much</h2>
+
+ <h3>Questions?</h3>
+
+ </body>
+</html>
projects / homepage.git / commitdiff