In Mourning for Statftime

The open source movement, prompted a lot by the success of Linux, recognized that proprietary software, huge software fees and licensing agreements that promised nothing did not guarantee that the needs of the computer community would be met. Collaboration, coordination and communication protect the community from alienation by the companies that were supposed to be serving it. End users of open source often talk about how great open source developers are, volunteering or, at least, contributing the source code that makes the community a better place.

But sometimes the developers, who are at the bottom rung on a software company's ladder, fare no better in the open source world. Some open source developers want contribute source code in order to better the world, or maybe some small corner of it. But when you release something into the world, there's no guarantee that it will be respected. Celebrities own their images and the characters they create. If an ad company wants to make a TV commercial featuring a celebrity, they must get the approval of that celebrity or their estate. This protects the integrity of the celebrity's work.

There is no such protection in the open source movement: there is no guarantee that the source code will be used in the way intended, nor that the author will be recongized or credited.

When I wrote "Linux Shell Scripting with Bash", the main utility for getting statistics on a file was GNU stat. stat displayed information about the file (it's age, when it was last modified, and so on) in a human-readable table. Unfortunately, human-readable output is not necessarily easy to use in shell scripting. If you want to look up this kind of information and use it in a shell script, you would have to do a lot of work and hope that the table layout wouldn't change in the future and break your script.

Linux author Warren Gay recognized this problem and suggested creating a new utility to work along side of stat. statftime would provide similar information to stat, but would use a formatting string so a shell script could easily get the information it needed. In addition, the formatting string made it easy to use the stat information to create new filenames for incoming files or rotated logs. With his blessing, I wrote statftime and released it under the GPL to work along side of stat.

statftime was never widely adopted in Linux distributions, despite the obvious advantages over stat and being described in my book. But I recently looked again at the stat command, I was surprised to see that stat now has a special formatting string option to make it emulate statftime.

stat was trying to be two different tools with different audiences, but at the same time with statftime's features apparently "shoe-horned" into the project in such a way that it doesn't make any logic design sense. A badly designed project is now a doubly badly designed project and little statftime is left ignored.

In my unfinished book, "The Big Online Book of Linux Startups", I write that some open source developers should never join or create an open source project for fame or loneliness. Just like the statftime project, good projects are likely to be stolen and adapted into larger, inferior projects. Take, for example, Python, which has been discussed at large at recent PegaSoft meetings. Python was originally designed for ease of use and clean syntax. Over the years developers have "stolen" ideas from other languages and forced them into Python without adapting them, and modern Python--like Perl and PHP--suffer from losing its distinct identity--let alone any common sense relationships between their features. To use these languages, you need to know a half-a-dozen other languages to recognize where some of the features come from and how to use them.

Likewise, stat now acts like two entirely different and incompatible commands.

But one thing is true: don't write open source software for the betterment of the world. The world will not care about you any more than the big software monopolies that fight open source. The lowly open source developer can only take pride--and hope--that somewhere, the efforts he put into making the world a better place are being used, even if they are only shadows of what they were intended to be. Sometimes the Lone Coder, like the Lone Ranger, must ride off into the sunset without a word of thanks.

Talk back on the Linux Cafe.

October 16, 2005