"Linux Gazette...making Linux just a little more fun!"

A letter linked on Slashdot got me thinking. It was written by Christoph Pfisterer when he resigned from the Fink project. (Fink is an attempt to "bring the full world of Unix Open Source software to Darwin and Mac OS X.") But it's not Fink itself I want to focus on, but the fact that it's free software. A developer is resigning from a free-software project because of the unappreciative demands of its users. He writes, "I'm tired of dealing with people who don't appreciate what they get for free. I'm tired of dealing with people who think they have a commercial-grade, 24/7, one hour turn-around time support contract with Fink.... I'm tired of people who complain loudly when something doesn't work, but fall silent when asked to help in fixing it.... I'm tired of putting my professional future at risk by neglecting my studies."

Here's the original letter: https://www.geocrawler.com/lists/3/SourceForge/11114/125/7038861/

This is one of the dangers every free-software developer faces. Have you hugged your favorite free-software developer today? OK, I'm joking. But if there's a free program you use a lot and really depend on, especially one that doesn't get a lot of recognition or is maintained by one volunteer, tell them how much you appreciate it. Consider giving a financial or in-kind donation to them or to their favorite free-software organization or charity. Or send a donation to the Electronic Frontier Foundation in their name. Love makes the world go round, and recognition (and taking care of the developers' material needs) helps the free-software world go round.

Another way to show your appreciation is to become a contributing user. You can code, write documentation, submit bug reports, or answer newbie questions. Many projects have a TODO list showing work they'd like to do when they have time. Are any of those goals things you can do? You may find that one of those TODO items would actually benefit you too.

As the adage goes, "If you can't code, write documentation." Are there parts of the documentation you feel are lacking? Is there any documentation at all? What advice did you wish you had when you first installed the program? Put it in a HOWTO. LG has been running several articles about documentation in the past couple issues, and January and February will bring even more.

Some projects have a closed development team, meaning they don't accept code from outside the core team. But even these sites are happy to receive bug reports from users, especially if the reports include a proposed fix or at least some research into what might be causing the problem and how to solve it. OK, maybe "happy" isn't the right word, because it means more work for them. But this additional work leads to a more bulletproof product.

The more users actively contribute on a project's bugtracker and mailing lists, the more the core developers will feel that their effort is worthwhile, and that translates into better software.

Also, participating in the development of your favorite software helps give you a sense of ownership in it. Which gives you something to brag about to your friends.

Mike Orr

Mike ("Iron") is the Editor of Linux Gazette. You can read what he has to say in the Back Page column in this issue. He has been a Linux enthusiast since 1991 and a Debian user since 1995. He is SSC's web technical coordinator, which means he gets to write a lot of Python scripts. Non-computer interests include Ska/Oi! music and the international language Esperanto. The nickname Iron was given to him in college--short for Iron Orr, hahaha.

---

Copyright © 2001, Mike ("Iron") Orr.
Copying license https://www.linuxgazette.net/copying.html
Published in Issue 73 of Linux Gazette, December 2001

---