by Schuyler Erle
The recent launch of our OnLAMP open source web platform interest site was received with some consternation by certain parties at this year's LinuxWorld convention. O'Reilly Net staff on hand at the convention reported being asked many concerned questions from people using alternatives to the Linux / Apache / MySQL / ( Perl | Python | PHP ) hegemony.
"What about *BSD?" they were asked. "What about PostgreSQL? How about Roxen, or Ruby?" Meanwhile, back at the office, one member of our staff went out and registered the OnBAMP.com domain, and another quipped, "Maybe we should call the site OnBLARMP.com?"
But underneath all the questions and the witty remarks lies a real confusion at the heart of the Open Source community. When does advocacy of one particular application or platform or OS become detrimental to the growth or use of another similar package? Am I, by pointing out all the things I like about Linux, or about Perl, somehow implying that there's something wrong with *BSD or Python? Not necessarily. Yet this assumption, this "tribalism" (as Mark-Jason Dominus puts it), seems to infect our community every time there's an option between two or more tools that do similar things.
This confusion persists even here at the O'Reilly Network, where concern has been expressed that, with OnLAMP.com, we're binding ourselves and our efforts to a particular cross-section of the available technologies, almost willy-nilly. But I don't think that's really the case. Let's have another look at the "LAMP" acronym.
LAMP stands for Linux, Apache, MySQL, and P-for-Perl, PHP, or Python. Now, let's ask a silly question: What features do these packages have in common? First, they fulfill roles integral to any web-based application platform; namely, OS-level services, application-level services, databasing, and scripting. Second, they each excel at the task they were intended for, in terms of performance, flexibility, reliability, and scalability. Third, and possibly most importantly, they are all Open, if not Free outright. At the O'Reilly Network, we believe that these three features are crucial to providing web-based (or other network-based) application services, anywhere, anytime.
However, nowhere have we stated, nor should we ever state, that these are the only tools for the job. The *BSD operating systems are just as Open as Linux, and can be more or less useful to you personally than Linux, depending on your preferences. Apache may be the most popular webserver on the 'Net, but perfectly good alternatives exist (e.g., Roxen) that are just as Open. PostgreSQL may not always be as fast as MySQL, but it has features that MySQL doesn't. Perl may be faster and more widely supported than Python, but Python has Zope. Or maybe some of the newer languages, like Ruby or Pike, have fixed things you didn't like about the more established ones. Or maybe you just like Tcl. And so on.
As such, there isn't really any reason you can't (or shouldn't) use BAMP, (i.e. *BSD in place of Linux), LAPP (PostgreSQL in place of MySQL), or LRMP (Roxen), or even the unfortunate-sounding LAMR (with Ruby). The idea of interchangeable tools isn't new in the UNIX world, either. For almost thirty years, the *NIX communities have with one voice propounded the UNIX Tools Philosophy, which is usually stated as: "Each tool should do one job, and do it well." Well, things are more complicated these days than they were back when
grep were young. It's easy to argue that you don't need an alternative to
cat that does the same thing, but works differently. However, when you get into domains as large and as complicated as "operating systems" and "network servers" and "application development languages", things become a little blurred. In fact, in practice, the issues become very blurred, at least to the point where maybe, just maybe, there might be more than one way to seize the proverbial
cat by the
So, if the UNIX Tools Philosophy implies the old saw about "using the Right Tool for the job", then the LAMP Tools Philopsophy exhorts us to "use any Right Tool for the job," so long as it helps you get the job done. Which is really what LAMP is all about, ultimately: Using the tools to get the job done, and done well, every time. This situation, and Open Source advocacy in general, is not, to borrow a term from a recent Clay Shirky article, Pareto Optimal; that is, we can recommend and advise on the use of one operating system or scripting language, without implying anything to the detriment or expense of another. (For deeper insight into this idea, see Dominus's aforementioned article.)
Obviously, then, the choice of the "LAMP" acronym is merely a matter of convenience: It indicates examples of the tools that people can use to get their job done, and, furthermore, it's easy to pronounce in English. By the term LAMP, we at the O'Reilly Network mean to embrace all of the Open Source tools that people use in building network application platforms, and to emphasize the ways they can be combined, as parts of a functioning whole. And, besides, LAMP is "all the rage in Europe." =)