Free software development - community and technology

An introduction to free software development, for those interested in participating.

http://www.hungry.com/~pere/mypapers/free-sw-devel/free-sw-devel3.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
• initiator 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
• update the 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 sucks. 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 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)
• remember to follow up your bug report.

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! (diff -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.

Learn to use the available tools

There are heaps of useful tools to make the development work easier and safer as well as to increase the quality.

Examples include

• version control systems (cvs, svn, git, bzr, etc)
• coding environment (emacs, eclipse, etc)
• build tools (gcc, jdk, make, autotools, etc)
• debugging tools (gdb, ddd, valgrind, etc)
• profiling tools (kcachegrind, kprof, etc)
• test suite frameworks (dejagnu, junit, etc)

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

This software sucks. A lot! - Do not take it personally.

Use the best free development tools available

• compile with lots of warnings
• use existing libraries, but avoid to many dependencies
• learn to use debugging utilities (gdb, ddd, dmalloc, valgrind, strace, ltrace, electric fence, fncchk, etc)
• learn to use profiling tools (kprof, gprof, etc)
• write automatic self testing
• do automatic coverage testing to check the quality of the self test

Running a successful free software project I

• be responsive to comments and suggestions
• 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

Running a successful free software project II

• 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

As the project grows larger

Leading by example is your only option.

• communicate the project plan to all project members
• try to reduce friction and avoid hard language
• keep track of what everyone is working on

Conclusion

• working on free software is very rewarding and challenging
• nobody owns you a favour, get used to it
• do it for your own gain, not to get rewards from others

References

• "The Practice of Programming" by Kernighan and Pike.
• "Free / Open Source Research Community - online papers, http://opensource.mit.edu/online_paper

Thank you very much

Questions?