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
• 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 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 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.

Joining a free software project

• start by checking out the bugs in the bts
• try to fix them
• give feedback into the bts on the reported bugs, after trying to reproduce them.
• go through the user documentation, and submit suggestions for improvement
• be active on the mailing lists, provide answers to the questions (and use references tot he user documentation, to save everybody some work)
• 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.

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 suck. 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?