This article originally appeared in TidBITS on 2000-03-13 at 12:00 p.m.
The permanent URL for this article is: http://tidbits.com/article/5842
Include images: Off

Poll Results: Long in the Tooth

by Adam C. Engst

Last week's poll asking about your oldest regularly used program proved fascinating in a number of ways, not the least of which was in the enthusiasm it generated on TidBITS Talk, where we heard about the many old programs still in regular use throughout the Macintosh world. I was surprised that messages to TidBITS Talk had little duplication - most people seemed to have different favorites.

<http://db.tidbits.com/getbits.acgi?tbpoll=32>
<http://db.tidbits.com/getbits.acgi?tlkthrd=969>

The Numbers -- We weren't surprised that few TidBITS readers use only recent programs - only 9 percent of respondents said their oldest program was less than 5 years old. We also weren't surprised by the number of people who use programs that were 5 to 10 years old - a total of 68 percent of respondents. For instance, the oldest program I regularly use turns out to be Peter Lewis's Finger client, which remains my preferred method of doing whois lookups on domain names despite its last revision in 1994. However, a whopping 23 percent of respondents still used programs that were 11 or more years old. Considering that the Macintosh has only existed since 1984, we were stunned that such elderly programs were still in regular use.

To be fair, had we broken out the years past 11, the answers probably would have fit a standard bell curve with the top of the curve at about 7 years, so perhaps it's not so surprising. Still, the mere fact that programs from 1984 run in Mac OS 9 on today's G4-based Power Macs is testament to how well Apple has handled backward compatibility over the years and to the code created by those early Macintosh developers.

The Rationale -- The reasons why people continue to use these programs vary widely.

<http://db.tidbits.com/article/05519>
<http://db.tidbits.com/getbits.acgi?tlkthrd=971>

Lessons -- It strikes me that there are some important lessons for software developers and for the Macintosh community at large, but I continue to have trouble winnowing them out. Should developers carefully avoid including certain features in programs to make upgrades compelling? Probably, and there are also trade-offs in development time versus feature completeness. Are upgrades often over-priced? No question. Do software companies rely on upgrade revenue to survive? Absolutely. Do software companies also rely on the splash of an upgrade to stay in the eye of the market? Indeed. Should users stick with versions of programs that meet their needs? Yes. Does the Macintosh community have some sort of an obligation to support software companies, or should survival go only to those companies that can appeal to a sufficiently large number of users? Good question.

These issues have been hashed over in the past in TidBITS Talk, but in the end, I think we end up with an uneasy synergy, where we in the Macintosh community rely on software companies to provide the quality programs we need to make the Macintosh experience compelling, but those companies in turn rely on us for financial support. Everyone's happy when the synergy works, but if either side fails to live up to its side of the bargain, the relationship fall apart. That's what happens when software companies release buggy software, fail to provide necessary tech support, or release more for-pay upgrades than seem warranted. And the Macintosh community is quick to complain when a favorite program is orphaned, be it MORE or Emailer; in the end, however, those orphaned programs must not have sold sufficiently well to overcome other obstacles to continued development.

<http://db.tidbits.com/getbits.acgi?tlkthrd=122>
<http://db.tidbits.com/getbits.acgi?tlkthrd=816>
<http://db.tidbits.com/getbits.acgi?tlkthrd=857>

Alternate business models have been tried, but none have proved sufficiently successful to convert existing companies to a new way of thinking. Perhaps there's room for improvement in that area, but until a new approach can be shown to work, the Macintosh community and software developers will just have to agree to abide by the tenuous contract that ensures our mutual future.