What Makes a Popular CMS?

This afternoon my good friend over at Boeing sent me a link to Paul Graham's 2001 piece on popular programming languages. You might have heard of Paul--he and Robert Morris wrote the software that drove Yahoo Store, a hugely influential system in 2001.

Considering that he's advocating a new spin on LISP, I thought the analogy would fit well with Plone's circumstances. He has 12 explicit metrics of popularity as they apply to programming languages and one implicit measure--let's see how far I can stretch them to cover CMS.

The implicit metric is very powerful abstractions. Hands down Python, Zope, and Plone blow the others away. An object-oriented database, archetypes/dexterity, Python (instead of Perl/PHP)... the list goes on and on, but let's dive into the 12 explicit measures of popularity.

1. The Mechanics. The mechanism of being popular is poorly understood in the WWW. What makes a video go viral? What does make a CMS popular? Do popular CMS deserve their popularity? Is it worth trying to define a good CMS? How would you do it? Let's look at webmasters and web designers, putting on that lens and seeing what shakes out. (Bear in mind that site users are incredibly important, but they often lack leverage in pre-selecting the underlying CMS.) Here's a quote from Graham with my transliteration from programming languages to CMS in brackets.

It's true, certainly, that most people don't choose [CMSs] simply based on their merits. Most [developers] are told what [CMS] to use by someone else.... So whether or not a [CMS] has to be good to be popular, I think a [CMS] has to be popular to be good. And it has to stay popular to stay good. The state of the art ... doesn't stand still.

2. External Factors. In a chicken-and-egg manner, a popular CMS has to be the underlying system of popular sites. One way to describe this situation is to say that a language isn't judged on its own merits. A CMS does need a good implementation, of course, and this must be free. Companies will pay for software, but individual freelance designer might not, and it's the designers you need to attract.

A language also needs to have a book about it. The book should be thin, well-written, and full of good examples. K&R is the ideal here [for languages, ed.]. At the moment I'd almost say that a language has to have a book published by O'Reilly. That's becoming the test of mattering to hackers.

I would now argue that a book published by Packt is the CMS benchmark. :-)

3. Brevity. Given that you can supply the three things any CMS needs -- a free implementation, a book, and means to rapidly prototype (see below)--how do you make a CMS language that webmasters and designers will like?

Paul makes the point that hackers need a language that is terse and weakly typed for speed of, well, hacking. Interestingly, he emphasizes that white space matters, which of course is a Python trademark. Referring to the LISP commands car and cdr:

And they are also different lengths, meaning that the arguments won't line up when they're called, as car and cdr often are, in successive lines. I've found that it matters a lot how code lines up on the page.

4. Usability. Graham, referring to programming languages, calls this hackability. There is one thing more important than brevity to a web designer: being able to do what you want--in our case, creating websites. I believe this translates into usability, another huge asset with Plone.

A recent blog post by PJ Grisel takes (IMHO unfair) aim at, among other things, Plone usability. But when I get desperate calls from the SharePoint user upstairs, I realize how smooth things are running in the Plone world.

5. Rapid Prototyping. Graham labels his 5th measure throwaway programs, which translates to prototyping in my world. To be attractive to site builders, a CMS must be good for building the kinds of sites they need to produce, which are often quick off-the-cuff demos for prospective customers.

What makes a [CMS] good for throwaway [systems]? To start with, it must be readily available. A throwaway [web portal] is something that you expect to write in an hour. So the [CMS] probably must already be installed on the computer you're using. It can't be something you have to install before you use it. It has to be there.

This often is the case when it comes to creating CMS-based websites on inexpensive, dare I say, cheap, LAMP servers. That said, the Plone installers get you up and running in less than 15 minutes on your desktop. With minimal instruction, a site designer can be customizing a functional prototype in evening.

That huge learning curve that everyone talks about may just turn out to be a myth. Heavy customization may take you deep into the bowels of Zope, but I rarely need more than CSS, ArgoUML, and cursory Python ability to produce wonderfully sophisticated portals. One doesn't need to know eight frameworks to be able to deploy a Plone site.

6. Libraries. Graham continues with the topic of libraries, which might be the equivalent of products in Plone.

Of course the ultimate in brevity is to have the program already written for you, and merely to call it. And this brings us to what I think will be an increasingly important feature of programming languages: library functions. Perl wins because it has large libraries for manipulating strings.

Python remains an strong contender here with its excellent libraries for manipulating not only strings but HTML, XML, and SQL. Since 1998 I've not gone data mining without my HTMLlib.

Back on track with CMS and Plone products, we are seeing some real maturity in key add-ons. Jazkarta's recent post ("May I borrow that?") about the products that make Oxfam America rock is very welcome.

7. Syntax. Sorry folks, I'm open to nominations as to what exactly the CMS equivalent of syntax might be. Its certainly a higher order concept having to do with the rules that apply to languages. In a CMS, this might transcend the underlying framework and relate to site organization, navigation, and how to make content meaningful (and possibly searchable). Comments welcome on this topic.

8. Efficiency. While speed of a language is one thing, speed of a website is another altogether.

As Knuth pointed out long ago, speed only matters in certain critical bottlenecks. And as many programmers have observed since, one is very often mistaken about where these bottlenecks are.

The nature of speed, as perceived by the end-user, may be changing. With the rise of server-based applications, more and more programs may turn out to be i/o-bound. It will be worth making i/o fast. The language can help with straightforward measures like simple, fast, formatted output functions, and also with deep structural changes like caching and persistent objects.

Users are interested in response time. But another kind of efficiency will be increasingly important: the number of simultaneous users you can support per processor. Many of the interesting applications written in the near future will be server-based, and the number of users per server is the critical question for anyone hosting such applications. In the capital cost of a business offering a server-based application, this is the divisor.

Nuff said.

9. Time. Graham discusses time in a novel way and reflects on "the garage guys" (open source) and the "big bang approach" (commercial).

The last ingredient a popular [CMS] needs is time. No one wants to [develop sites using a framework] that might go away, as so many [CMSs] do. So most [designers] will tend to wait until a [CMS] has been around for a couple years before even considering using it.

The good news is, simple repetition solves the problem. All you have to do is keep telling your story, and eventually people will start to hear. It's not when people notice you're there that they pay attention; it's when they notice you're still there.

If you look at the dominant technologies today, you'll find that most of them grew organically.

Plone continues to grow organically and still gains ground in important areas like government web portals. In my day-job we've been "ramen profitable" for several years, where we don't need to raise funds for the web team to survive. And now that our skunk works has been around for five years, people are standing up and taking notice. People are listening to the story. (BTW, see Graham's July 2009 essay for more on ramen profitability.)

10. Redesign. The concept of redesigning certainly resonates with the current Plone community. 3.3 is out there, 4.0 expected by Christmas, and 5.0 PLIPs are already coming thick and fast. Graham has a great description of a two-cycle innovation engine:

In the first phase of the two-cycle innovation engine, you work furiously on some problem, inspired by your confidence that you'll be able to solve it. In the second phase, you look at what you've done in the cold light of morning, and see all its flaws very clearly. But as long as your critical spirit doesn't outweigh your hope, you'll be able to look at your admittedly incomplete system, and think, how hard can it be to get the rest of the way?

11. Plone. Of course Graham expounds the virtues of LISP in his 11th point. Here I include some quotes from another of his 2001 articles, The Other Road Ahead:

When we look back on the desktop software era, I think we'll marvel at the inconveniences people put up with, just as we marvel now at what early car owners put up with. For the first twenty or thirty years, you had to be a car expert to own a car.

There is now another way to deliver software that will save users from becoming system administrators. Web-based applications are programs that run on Web servers and use Web pages as the user interface. For the average user this new kind of software will be easier, cheaper, more mobile, more reliable, and often more powerful than desktop software.

With Web-based software, most users won't have to think about anything except the applications they use. All the messy, changing stuff will be sitting on a server somewhere, maintained by the kind of people who are good at that kind of thing.

When you install software on your desktop computer, you can only use it on that computer. Worse still, your files are trapped on that computer.

Think back on Plone in 2001... now reflect on where we are today. CMS have freed the user's files that were trapped on that desktop, or worse still, trapped in that maze of mirrors people call their shared drives. While web developers have to worry about the details under the hood, to continue the metaphore, our users, our content providers are getting more and more power, convenience, and usability. Web designers are the ones who must put structure, order, organization, and context into the content provided. Plone can't do that for them (yet :-)).

12. The Dream System. Paul has a more recent essay about "The Power of the Marginal." In it he has some remarks that the Plone community can take comfort in when others make Plone and Zope's edge technology an issue (and complain about the name of your visual editor). When someone next drags out the Google Trends graph for Drupal-Joomla-Plone, take heart:

This leads to my final suggestion: a technique for determining when you're on the right track. You're on the right track when people complain that you're unqualified, or that you've done something inappropriate. If people are complaining, that means you're doing something rather than sitting around, which is the first step. And if they're driven to such empty forms of complaint, that means you've probably done something good.

If you make something and people complain that it doesn't work, that's a problem. But if the worst thing they can hit you with is your own status as an outsider, that implies that in every other respect you've succeeded. Pointing out that someone is unqualified is as desperate as resorting to racial slurs. It's just a legitimate sounding way of saying: we don't like your type around here.

But the best thing of all is when people call what you're doing inappropriate. I've been hearing this word all my life and I only recently realized that it is, in fact, the sound of the homing beacon. "Inappropriate" is the null criticism. It's merely the adjective form of "I don't like it."

So that, I think, should be the highest goal for the marginal. Be inappropriate. When you hear people saying that, you're golden. And they, incidentally, are busted.