Supporting Free Software
a reflection on keeping the machine running
by
<xunker@pyxidis.org>
December 2001
To much in these days of the Internet and endless information we loose sight of the fact that everything you use (especially software) has to be created by humans, and most of the time they don't come out and ask for any remuneration.
But in this day and age of enlightenment we should also be aware that people cannot live on good intentions alone and as the amount of free software increases, the audience must start to participate and support it.
Before we begin, it is important to get some things out of the way. First, this work uses my definition of "free software" which isn't quite the same as other Free Software definitions. My version of free software is software given without the author requiring or even expecting any sort of reciprocity; one may also call this the "Free as in Beer Camp". Usually this means the software is also "Open Source" (as most of these elements described below reflect) but even free, closed source software deserves recognition (that is freely usable, not shareware).
There are a number of ways to do this; some may be more effective than others but all are better than sitting around waiting for "the other guy" to take your obligations for you. It's a lot like PBS without Inspector Poirot.
Money
The easiest way is with those happy markers that are exchanged for goods and services, also know to the world as money. Cash. If you find something massively useful there are three feasible ways here to do it.
The first is if the people responsible for the product also sell a "boxed version", buy it if it's a product you use daily. Prime examples of this are vendors of various Linux distributions and *BSD projects.
The next way is very similar in the vein of 'micropayments', or 'pocket change donations'. These would be ideal for small but insanely useful tools that you use daily or larger products that you only use occasionally. Places like PayPal and Amazon.com are now offering automated systems to allow people to donate arbitrarily small amounts of cash via credit card, though they also skim an apprecable amount off the top. To get past this you can in also just send a cheque, money order or whatnot to the people in the project responsible for such things. And remember, some of these projects can be qualified as 'non-profit organizations' and so your donation may be tax deductable, but check with your accountant to make sure.
A third way of monetary remuneration is to participate in merchandising. Some projects, especially the more "hip" ones, will have various paraphernalia for sale through places like CafePress, CopyLeft, ThinkGeek and other outlets. With these places, especially CafePress, the sale price above a creation cost goes to the seller so if you buy a KDE shirt for 14.95 but the production cost is only 13.95, the KDE project would get $1.00. Pretty straight forward, huh? Just make sure you get the right size, and that the profits of said sale do, in fact, return to the project.
Writting New Code
This option (and the next few) are sadly one that you can only do if you have certain skills. In this case, you contribute your time in payment for their time.
Too often when using something we say "well, this is great, but it would be even better if it did <feature>!". Well, as programmers, if we say that we have the option (if we know the language) stop talking and add that feature. As Mark Tain put it, "Everyone compains about the weather, but nobody does anything about it." This is a lot more involved than just sending money, but it is also more valuable because not only are you extending the project, but you're also contributing you time which, if you're a coder, is probably worth quite a lot per hour.
Fixing Old Code
This goes along very nicely with the above, except in this case it's not adding features but squashing bugs. In a way this is even harder because, depending on the bug, it requires a lot of time invested in the understanding of the code, the finding of the bug and the weaving of a patch into the existing codebase. But in a away, it's even more useful because as glaring as not having a certain feature is, it's even more of a malady to have a broken feature.
Something that can also go with fixing old code is "freshening" old code to use newer standards, libraries and the like. Excellent examples are changes to use more standard codebases and supporting ratified changes to old data formats.
Reporting Bugs (and suggesting suggestions)
What's the saying? "Those who can't do, delegate?" Something like that. Well, there are a large portion of people who use free software that either are not programmers or simply aren't proficient in the language said code is written in. In this case, bugs can still be found and hopefully will be picked up and fixed by someone who can. Of course, it still helps to have an understanding of the way the system works and to give a detailed bug report because few things are more annoying when a bug is reported with an explanation that consists of little more than "when I push the 'load' button my mouse explodes" when, if they had given a little more research and said "..it explodes because I have a quantity of C-4 attached to it" I could fix the problem in a few minutes ("remove the plastic explosive from your mouse or use Semtex or some other 'supported' incendiary device.").
As for suggestions, feature requests have have received a bad rap over the last small amount of time. Mostly this is because the suggestions being brought up have already been addressed and are quite obvious. But, there are some suggestions that are excellent, especially when they come from someone who uses the product in a profession capacity and can give detailed reasons and designs for a feature. "It needs a 'save' feature" is not a good suggestion; "I needs a 'save as Widget 2.4 non-interlaced format' feature because modern Widget Lathes use that format" is a good feature request because it outlines the scope of the request and the reasons for it.
Writing Documentation
Something that free software has been lacking by-and-large has been detailed documentation. Sure, there have always been README's and HOWTO's, but writting in-depth drool-proof explanations of features have never been a programmers strong suit, and technical documentation has never been palpable by the general public.
Writing documentation is probably the worst part of programming, especially for the programmer themselves. Since they wrote it, they understand it intimately and have a hard time visualizing how it is for those who have never used it before. This is where a 3rd party comes in. Even though it may seem to the the simples tool in the world, chances are there is someone out there who is unsure about some aspect of it's function.
Supporting the Community
A more informal and lax side of documentation is support of the user community, but instead of chiseling instructions in stone, this becomes a "share what you know" deal. Hanging out on usenet, IRC or even in web-forums and answering questions is probably one of the best ways to help people and is one of the things that free software is famous for: users helping users.
Telling someone to read the man page isn't an answer, and neither is insulting their aptitude. Ask if they've read the documentation, and if they have, it just may be that either they overlooked the answer or their situation is really not covered anywhere else.
Pizza (and other intangibles)
Most people know about how the maintainer of
Samba asks nothing of payment except that if you find his software useful you buy him a pizza (or make arrangments for having one delivered). As silly as this sort of thing sounds, it's not a bad option because not only are you giving an actual something, but you also went to the work of arranging it's delivery and that sort of support is welcome, as is food.
Developers will often ask for silly things, but sometimes more serious things like archane technical documentation, equipment and even insider insight. The next time you see a projects' news log that says "we'd like to port TurboSpaz 7 to the Fibiddly 4000, but we don't have one", remember the Fidibbly 4000 that you're using as a doorstop after you took it as a ransom bargaining tool from you last job when they went titsup.com. If you're not using it, they sure could; you could outright give it to them, loan it to them or just put it up on the net for them to use remotely.
Thanks
Last, but certainly not least, is the tried and true tradition of giving credit where credit is due. Developers love getting an email at 2am some Tuesday morning that just says "love the software, keep up the good work". Sure, it's not money, jewels or stock, but it does mean a lot; it means their work actually means something and someone really does give a damn about what they're doing. Warm fuzzies go a long way even in these modern times.
In closing I'd like to use the words of Danny Elfman (for his words carry far more weight then mine ever could) by saying:
It all comes down to
look out for each other;
no one else will.