|
|
|
|
|
|
|
|
One programmer's experience developing freely available software for Linux.
by Luis A. Fernandes
Lucy: ``What happens if you practice the piano for 20 years and then end up not being rich and famous?''
Schroeder: ``The joy is in the playing.''
--Peanuts
xmotd is a message-of-the-day browser that runs under the X Window System. It was written to ease the burden of the local systems administrator in making day-to-day announcements of general interest to students and faculty using the computer network in the Electrical and Computer Engineering Department at Ryerson Polytechnic University, Toronto, Canada. This is a chronicle of my experiences developing a program that started as a trivial, single purpose tool and evolved into one with numerous features suggested by its users.
It was a late August afternoon in 1993 when Nick Colonello, the department's system administrator, and I were discussing the past school year and how it would have been nice to be able to let students logging in to the system know important information. With the following school year less than a month away, I boasted that I could write a simple message browser in about 10 minutes that could be run automatically by xdm (the X display manager) when students logged in. He agreed that it was a good idea and I proceeded to complete version 0.1 in under 30 minutes; it was called xbanner.(1) Visually, it consisted of a text widget where the message would be displayed, and a ``dismiss'' button, in the top-left corner of the window, used to close the window. For a brief moment, it looked supremely functional. But I was not satisfied--it looked utilitarian and ugly. (See Figure 1.)
In another half hour, version 0.2 was completed with an aesthetic re-fit consisting of a label widget that displayed a title, a separator widget (purely decorative) to separate the title from the text and another label widget to display a bitmap (a logo of our computer network). This was the version that was first installed on our system.
A few weeks later, Luis Lopes, the systems administrator in the Computer Science department dropped by for a visit and expressed interest in installing xbanner on his system. I was duly impressed that someone I knew would actually find something I wrote useful.
In March of the following year I read a post in comp.windows.x asking how a message of the day could be displayed when running X and xdm. Not knowing where it would be taking me, I innocently followed up saying that I had hacked together such a program and was willing to share it. Within a few hours I received two e-mail messages, and the next morning had another asking for a copy of xbanner. Now I was truly impressed.
Its popularity was never anticipated. It was as if no one had thought the world needed such a program. Indeed, a cursory investigation, prior to beginning work on xbanner, would have revealed the existence of a similar tool that, with minor modifications, could easily fit whatever new specifications were demanded. However, at this time the Web was in its infancy and archie was the de facto, parochially-minded, search tool of choice. Obscurity and ignorance condemned useful software to languish on ftp sites around the world.
I first learned of xmessage's existence when Vivek Khera e-mailed me a shell-script that used xmessage, in conjunction with other Unix programs, as a message-of-the-day browser. xmessage, written by Stephen Glidea of the eX Consortium (2), is a generic tool that can be used to browse a text file or display a message. It consists of a widget in which the text is displayed and an ``okay'' button in the bottom left corner of the window. (See Figure 2.)
Notice the remarkable aesthetic similarities between xmotd 0.1 and xmessage. In a market with several similar, feature-rich tools, aesthetics are often the deciding factor for a user. In a recent interview, the late Seymour Cray noted the importance of aesthetics: ``I've enjoyed the aesthetics part of building computers because it's any extra little thing you add that is clearly your own personality being projected in the product.''
In addition to aesthetics, flexibility also plays a major role in selection. Experience has shown that users have a preference for application software that allows them to solve their problems, rather than overpowers by solving the programmer's problems. Usually, a programmer writes a program to solve a particular problem, then gives it away with the hope that others will benefit from it. Typical end-users do not find much use for this kind of software because it was written ``by programmers, for programmers''. It performs a single job--nothing more, nothing less. Common shortcomings of this type of software include:
Software that allows infinite customization (3) endears itself to users dedicated enough to read the documentation because it gives them complete power--the same sense of creative power the developer felt when designing the software.
For example, xmotd's customizable bitmap was a relatively minor coding burden (an additional 10 lines of code to read in and validate a bitmap file) that affords the end-user a personal touch to what would otherwise be very bland software. The EE department's logo was originally hard-coded as the default image in the internal version of xmotd (now suitably renamed). When I uploaded xmotd to the eX Consortium's archive, I hard-coded in the X logo. One of the first requests I received was for the ability to change the logo. A less-than -optimal (and therefore temporary) solution I implemented was to amend the README with instructions on modifying the source code so a different bitmap could be compiled in. However, I found that people were very reluctant to modify code; they preferred something simpler. It then occurred to me to use the X logo as the default image and add a -bitmap option to allow the user to override the logo with one of his choice.
``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):
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.
``A work of art is never complete; the artist merely abandons it.'' --Unknown
Three years (and 14 releases) later, I thought xmotd was approaching completion; i.e., every option that could possibly have been added had been. Since December 1996, however, more suggestions (which will be incorporated into version 1.15 of xmotd) were submitted, including one for running the HTML version within an Intranet and having it spawn a web browser when an URL was clicked. I should note that xmotd gained popularity when it began supporting HTML. (See Figure 3.)
My advice to eager developers is, first, not to begin writing software without ascertaining whether a similar package exists (web space can be effortlessly searched these days); if it exists, consider extending it rather than starting from scratch. Second, write the software with full intent of incorporating user suggestions (don't ignore your users) and bug fixes following the first release (version 1.0 is never the last release). Finally, write software that keeps pace with advances in technology (e.g., Java) or face obsolescence. People will begin to use software only if it satisfies their needs and will continue using it only if it evolves to accommodate their changing needs. Persevere until the day you write software that receives the world-wide acclaim we all dream about.
Per Abrahamsen, Derek Fedak and Lars Magne Ingebrigtsen shared insights that helped shape an early draft of this article. The author's photograph comes to you courtesy of Jason Naughton whose perseverance got the Sun video camera working. The Peanuts quote is by Charles Schulz, copyright United Feature Syndicate.
Luis Fernandes is a hacker. Winning the honourable mention in Sun's Alpha Java Programming Contest was an indescribable moment of his life. His definition of fun includes hacking X and Java; listening to music (composed before 1800 and played on period instruments, in particular); reading unusually good books and generally doing anything creative. He can be reached via e-mail at elf@ee.ryerson.ca.
