Here is a possible synthesis of RichardGabriel's WorseIsBetter idea and GeoffreyMoore's TechnologyAdoptionLifecycle idea (see ISBN 0887308244). Lisp failed because the cognitive cost of learning Lisp is much higher than that of learning C (enough to be useful). It is easy to write a simple program in C. Lisp does not give sufficient benefits for the cognitive cost to be recouped.

C has a simpler interface. It is not as beautiful or general or abstract as Lisp. The less abstract something is, the easier it is to learn and the more likely it is to succeed in the market.

The same holds true with Microsoft. Microsoft's interfaces are mediocre but they were still relatively easy to learn. The Mac's interface was too well thought out to be communicated to a newbie in a few minutes. MS-DOS and even Windows makes baby-talk possible.

Perl and Python present the same allegory with different characters. Perl is less innovative and so is more "continuous" with existing languages.

Another key characteristic of successful software is incompleteness (rather than completeness - even though Alan Cooper would disagree). You implement only the parts you are sure about and which you know how to implement easily. Once you reach a point where you don't know how to proceed, stop and ship. 

An incomplete product allows other agents in the marketplace to extend it in different ways. Perfectly complete systems shut out serendipity. They forbid experimentation and parallel evolution of many different alternatives.

Once a successful path is discovered (Netscape), it can be bundled with the incomplete system. This allows the system to evolve in low-risk ways.

-- AsimJalis

Success is a transient thing, what is successful today may not be successful tomorrow. Witness Windows 1.0 --> Windows 2003. A basic concept, with time dependent implementations. Each iteration had a certain success, but as time and circumstances changed, the need for extensions, additions and enhancements are noted. As enhancements and improvements are added, weaknesses in the foundations are often discovered, requiring major overhauls and even abandonment and adoption of new foundations. Such a approach is said to be "topheavy" and is likely to evoke negative reactions when thing tumble down. True and lasting software successes (ones that will operate as well 50 or 100 years from now as well as they do now) must be built on a fixed and permanent foundation, not one which changes every 15 minutes. As an illustration: I am typing this entry using a Pentium-class machine, with Windows98 installed. In just a couple of months, active support for this foundational package is being abandoned. What does this mean? Practically and operationally it means if I wish to use any new software in the future, I must make sure it will work on my abandoned operating system, or I must scrap not only Windows98, but must buy the hardware necessary to run its replacement. Is this software success? It was, but it isn't. A perfectly working Powerpoint presentations prepared using Windows98 do not work the same way on WindowsXp. Is this software success? In a way it is, in another way it is not. Should one measure of software success be that products produced by a program be usable in the future? It should be, but it isn't. Right next to me is a 3.06 Ghz machine running WindowsXp, it still has a floppy drive, but future machines will probably not have them. Must I then maintain two machines to use the hundreds of floppies with the data and programs on them? Shouldn't have to, but probably will. -- AnonymousOnPurpose