Free software development for beginners
An introduction to free software development, for those
interested in participating.
http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel.html
Petter Reinholdtsen
pere@hungry.com
IFI/UiO, Forskningsparken rom 207 2004-04-27
Who am I
- been involved in free software development since 1992
- programmer and system administrator
- past and current contributor to several projects (linux,
glibc, kde, debian-{edu, gis, java, cdd}, mapserver,
openstreetmap.org, skolelinux, etc)
- debian developer
- initiater and current tech coordinator in skolelinux
- currently employed at USIT, UiO
Free Software - user freedom
- freedom to run the program as you wish for any purpose
- freedom to study and change the source code as you wish
- freedom to make and redistribute copies
- freedom to publish modified versions
Richard M. Stallmann, FSF
Getting involved and helping out
So, you found a nice project on Freshmeat, and want to help
improve it...
- get used to public review
- read the project documentation
- join the relevant mailing list, IRC channels, etc
- use mailing lists
- irc, wiki
- get to know the source
- understand licensing issues
- learn to use the bug tracking system (bts)
- start with the non-coding stuff (translations, documentation)
- do not take it personally
Reporting bugs
This software suck. A lot!
- test if the bug exist the latest version
- do not report duplicate bugs, check the bts and mailing
lists
- document how to reproduce the bug, and include relevant
information. get output from valgrind, strace, gdb and
ltrace.
- include info on possible workarounds, and patches if you
can.
- add more info if the bug is already reported
- use the relevang 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)
- remember to follow up your bug report.
an
example
Submitting patches
Fixing the problem is only half the work.
- if you can fix the problem you are facing, remember to let
the package author know about this.
- make a patch! (patch -u file.orig file.new >
myfix.diff)
- send the patch to the developer list, or possibly into the
bts (learn how the developers want it)
- do not forget to follow up the patch. Accept commend and
improve it until it is accepted by the developers.
- 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.
Joining a free software project
start by checking out the bugs in the btw
try to fix them
give feedback into the bts on the reported bugs, after trying
to reproduce
them.
- aktiv prosjektdeltager
- fiks feilene som er rapportert i bugrapport-systemet (prosjektet
_har_ et feilrapportsystem, ikke sant?)
- Test og gi tilbakemelding på rapporterte feil.
- sørg for at brukerdokumentasjonen er oppdatert, og henvis til
denne (så slipper du ekstraarbeide)
- sørg for at kildekoden du lager er selvdokumenterende, følger
kode-policy og har akkurat nok kommentarer til at formålet med
koden er lett å forstå
Starting a free software project
I got this idea for a piece of software...
- reuse when possible, prefer to improve existing
projects
- read other peoples code, download and test other peoples
programs
- understand software licenses
- consider sourceforge
-
- tools
- compiler
- libraries
- debugging utilities (gdb, ddd, dmalloc, valgrind, strace, ltrace,
electric fence, fncchk, etc)
This software suck. A lot! - Do not take it personally.
Running a successful free software project
- write down where you want the project to go
- do not accept every change. make sure you like it first
- let everyone work on the things that interests them, use the
carrot, as you have no whip
- set up and use a bts
- create web pages for your project, include screen shots, a
short summary and who to contact for more info
- 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
- involve the public mailing lists in the decision making
- automate everything
- set up system for public review of changes (anonymous CVS,
commit emails)
- communicate the intention behind the choice of license
- prosjektleder
- hold oversikt over hvem som gjør hva
- kommuniser prosjektplanen til alle prosjektdeltagerne
Conclusion
- working on free software is very rewarding and challenging
- nobody owns you a fawour
-
References
Thank you very much
Questions?