xmotd: Writing Free Software
“Every program in development at MIT expands until it can read mail.” --Unknown
Users invariably suggest enhancements, because the developer cannot anticipate all the uses for the software. A good rule of thumb is that for each person who asks for an enhancement, assume ten do not. My decision to implement the suggested enhancements was based on coding time versus how many users I thought would benefit from the feature. For example, I would guess that the -usedomainnames (4) option is rarely used other than at the site of the user who suggested it. I added it only because the overhead was one extra line of code in the function that generated the timestamp.
Another example: the -wakeup option initially specified an hourly period using an integer argument. When someone requested finer granularity (15 minutes sleep time) the argument was changed to a floating-point number with the fractional portion used to represent minutes.
The change was simple and didn't break backwards compatibility with -wakeup operation in the previous version. Users tend to be frustrated (to the point of not bothering to upgrade) when successive versions introduce incompatibilities with previous versions.
If a particular feature is implemented, it is wise to add an option to disable that feature because it is very likely that someone else may not like it. I added -timestamp to allow the default timestamp name “.xmotd” to be overridden after a user request. Put simply—provide lots of options.
There is a certain amount of personal gratification in writing software, but developers are happier when people actually use the software. Many features now incorporated into xmotd were suggested by users (systems administrators) at other sites. Unsolicited e-mail from users is a good indicator of popularity and is very inspiring to developers. If you enjoyed using some software (regardless of whether it's free) and know the author's address, I would urge you to write him a brief note. The euphoria from reading a note of thanks is ineffable. As a benchmark, I have received 107 e-mail messages regarding xmotd, versus 10 messages for xabacus and xsecure combined (a pair of X applications I had authored prior to xmotd).
The e-mail I have received about xmotd can be categorized as follows (ordered from least encouraging to most encouraging; too many from the beginning of the list may make you want to give up writing free software):
Your program didn't compile. Do you know why?
I didn't read the README file, how do I install your software?
I'm too lazy to read the documentation, how do I use this feature?
The documentation for using this feature is unclear.
Can you add this feature?
Your program doesn't work.
Thanks for writing this cool software.
The documentation for using this feature is unclear, here is a fix.
There's a bug in your cool software, and here's the patch.
Here's some code that implements a new feature and makes your software even cooler.
Wasteful duplication is common in the free software world. Given that Unix has been around for more than a quarter century, it is very likely that a solution to a problem has already been developed and you need to find it. On the other hand, commercial software has a colossal advertising budget and therefore mediocre software is often guaranteed commercial success. The ubiquitous and global nature of the Web is altering the balance. (When digital cash becomes a common transaction medium, it will become easy to charge for software.)
The Web allows software to have its own home page, providing inexpensive, world-wide advertising that precludes a marketing department. (5) New versions can be announced with varying amounts of fanfare. In some cases, major undertakings like the GIMP paint program or the Gnus newsreader for Emacs evolve around a mailing list subscribed to by a dedicated following interested in discussing and implementing enhancements. A catalog of free software would be a great benefit to both the developers and the users of free software. [The Linux Software Map on Sunsite is easily searched and functions as a catalog; however, it is not always up to date—Editor]
The rewards for commercial software are money and, often, fame. The rewards for writing famous, free software are recognition, a reputation and, at best, fanatic adoration. Many developers of free software share the sentiment illustrated in the opening epigraph. We write software because it's fun; it's more fun when people actually use it. Making it freely available guarantees that the greatest number of people will use it. Very often, free tools are the only alternative for those administrators who administer vast networks with minimal resources.
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- The Ubuntu Conspiracy
- A First Look at IBM's New Linux Servers
- Vigilante Malware
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- Vagrant Simplified
- Libreboot on an X60, Part I: the Setup
- System Status as SMS Text Messages
- Dealing with Boundary Issues
- Bluetooth Hacks
- Non-Linux FOSS: Code Your Way To Victory!