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

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

Reporting bugs

Joining a free software project

Starting a free software project

• Reuse when possible, improve existing projects
• - avoid starting from scratch, reuse an existing project if possible. - public review (anonymous CVS, commit emails) - bug tracking systems - licenses - download and test other peoples the programs - read other peoples code - give well-formed bug reports, and include a patch if possible - let everyone work on the things that interests them - do not accept every change. make sure you like it first - write down where you want the project to go - web pages - screen shots - short summary - who to contact for more info - source README - home page URL - download site URL - short description - where to send bug reports and patches - consider sourceforge - tools - compiler - libraries - debugging utilities (gdb, ddd, dmalloc, valgrind, strace, ltrace, electric fence, fncchk, etc) - avoid duplicate work (check freshmeat) - bruker - hold deg til de store distribusjenene - hvis du finner feil - fortell din lokale sysadmin om feilen, og be personen teste nyere versjoner og/eller å skrive en feilrapport - sysadmin/feilrapportør - Hvis du finner en feil - søk i bug-databasen til produktet om dette er en kjent feil - hvis ikke, test siste utgave lokalt - hvis feilen fremdeles er der, og er gjenproduserbar, send en feilrapport (valgrind, strace, gdb, ltrace) - hvis feilen ikke er fikset, men utviklerne er klar over denne, send en feilrapport til! - sørg for at feilrapporten inneholder nødvendig informasjon for å gjenprodusere feilen og hvordan systemet ditt er konfigurert - bruk gjerne feilrapporteringsverktøy som bug-buddy (Gnome), perlbug (Perl), reportbug (Debian) sendpr (FreeBSD), eller produktets feilrapporterings-webside (bugzilla, request-tracker, gnats e.l. Se på prosjektets hjemmeside) - husk å følge opp feilrapporten din - patch-bidragsyter - Hvis du har muligheten til å rette feilen selv, pass på fortelle prosjekt-delagerene om fiksen - lag en patch! (patch -u fil.org fil.ny > minfiks.patch) - send denne til utvikler-mailinglisten, og følg med om den blir inkludert, eller om den krever mere fiksing. - ikke "glem" en patch. blir den ikke akseptert, sørg for å fikse patchen så den blir akseptert. - "glemte" patcher _vil_ skape merarbeide for deg neste gang programmet skal oppgraderes. - 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å - prosjektleder - hold oversikt over hvem som gjør hva - kommuniser prosjektplanen til alle prosjektdeltagerne

  Conclusion

  References

  Thank you very much

  Questions?