In 1998, Michael Kunze wrote an article for c't, a biweekly German computing magazine, hoping to demonstrate that free software could be an effective substitute for its commercial counterparts. In the article, he coined the acronym "LAMP" to describe an illustrative collection of available software - the Linux operating system; the Apache Web server; the MySQL relational database management system; and the Perl, Python, and/or PHP scripting languages - that could provide an end-to-end free computing environment. Kunze hoped that the acronym-loving IT community would remember LAMP in connection with the proposition that free software deserved serious consideration as an alternative to commercial software.

Seven years on, with Kunze's thesis well proven, the LAMP acronym has been co-opted by the marketing department of at least one of the LAMP constituents to stand for an altogether different proposition; that Linux, Apache, MySQL, and the "P" scripting languages should constitute the open source stack of interest when considering software alternatives. It's a proposition that is equally specious, insidious, and fatuous.

It's specious because, while it's initially plausible, it is ultimately wrong. Those open source components are well known, readily available, and work well together for many tasks, particularly for serving Web sites without update-intensive database requirements. However, LAMP's role as a merely illustrative stack of open source offerings is hardly ever acknowledged; in reality, each layer of the LAMP stack is fungible. No one layer was expressly designed to work with the others, and neither do any of them work better with the others than do alternatives. For example, the PostgreSQL and EnterpriseDB databases work just as well with "L," "A," and "P" as does MySQL. Similarly acceptable substitutions are, of course, available for each other layer in the stack.

As an aside, the "P" layer does stand as something of an exception, as three choices-Perl, Python, and PHP-are commonly admitted, but even here questions are raised: What happened to Ruby and all the others? What if Larry Wall's "Practical Extraction and Report Language" (a backronym, at that) had actually been "Gloria," as he is said to have considered? GLAMP, indeed.

The irony is that the LAMP shorthand is frequently encountered in open-minded discussions concerning open source alternatives to stacks of expensive commercial software. Open source advocates promoting LAMP actually do a disservice to their listeners by providing them with useful (i.e., LAMP is one choice) but incomplete (i.e., there are many choices) information.

What's insidious about the popular tendency to refer to LAMP as if it were the open source alternative to closed source technology stacks is that the notion is taking hold gradually, subtly, and harmfully. Each time this particular stack is tendered without explanation as a proxy for open source software, generally there's another opportunity for the two to be misidentified as synonyms. The danger is that this specific software combination will become so institutionalized that an enterprise finding one layer of LAMP unsuitable will end its inquiry, declaring that "the" open source stack cannot meet its needs. That's bad for Linux, bad for open source software, and bad for enterprises.

Finally, the notion that the LAMP constituents constitute the "official" or even "preferred" open source alternatives to commercial software is fatuous in the face of the open source ethos, which, among other virtues, is characterized by transparency and choice.

Kudos to Kunze for getting us started in the right direction. Now, it's time to elevate our discussion.