A slightly overweight 47-year-old walks up and says, “I plan to become the next Olympic medalist for track. What do you think?” I say, “Well, I like where you’re headed, anyways.”
In fairness, that guy would probably never make it to the Olympics. WordPress features many app framework and platform hallmarks, including core APIs and methods that automate and simplify otherwise complex operations like user authentication and remote data interaction. WordPress succeeds spectacularly largely because it emphasizes the publisher experience atop a capable, approachable, and open platform. Business-minded decision makers selecting a publishing system aren’t terribly interested in nuanced argument about PHP’s suitability to object-oriented software engineering.
So when the conversation is about “the best platform for content delivery and management”, there’s a compelling, evidence-based argument for WordPress. If the conversation is about “the best platform to engineer apps on top of”, it’s unclear that objective evaluation – of this admittedly murky and broad criteria – leads to “WordPress”, largely because this is a debate about the comparative merit of platform architecture. In a debate about architecture and engineering prowess, the freshest technologies – free from legacy weight and optimized for the latest real world use cases – are bound to excel. Our vision for auto-updates (Chrome-like updates that happen in the background without intervention) – which can succeed only with virtually guaranteed backwards compatibility – conflicts with a vision of a competitive, fresh software platform.
Unhealthy temptations
Some tangential, important context: I understand the temptation of a loyal, often insular community to think of every possible project as a nail when they only carry a hammer (Tom McFarlin effectively articulates the same point). There’s a cautionary joke told by doctors: take a difficult to diagnose patient to a neurologist, and they’ll receive a neurological diagnosis; take that patient to an oncologist, and they’ll find cancer. Engineers apply their personal tool belt to engineering problems. Salesmen push the product they have on the shelf.
…he’ll talk through the comparative merit of 3 or 4 different platforms, some of which he doesn’t support. I want to be that guy, not the “WordPress, f–k yea” guy.
Then there’s the fanboy thing. There’s nothing wrong with cheering for a team, until right and wrong is defined by the team. With my current fortunes tied to WordPress, a “WordPress good, platform X, bad” frame of mind is tempting – and dangerous. I don’t want to be that guy cheering for MovableType in 2008 or Adobe Flash in 2011. I’ve admired my friend and fellow web strategist John Eckman for years largely because you can describe your functional web platform requirements, and he’ll talk through the comparative merit of 3 or 4 different platforms, some of which he doesn’t support. I want to be that guy, not the “WordPress, f–k yea” guy.
This is why I describe 10up as a web publishing agency that has selected today’s best tool for our job (WordPress). It’s why I tell tiny e-commerce businesses that need simple storefronts that Shopify may be more appropriate than WordPress + eCommerce plugins. I told a large enterprise considering a complex WordPress-powered Intranet that there was a better choice given their requirements while two fellow “WordPress agencies” sold inane, expensive WordPress-based solutions. The client selected a better-matched tool, thanked me over lunch, and came back later with a project that was a great fit. Two months ago I dined with a former early paidContent editor, who told me Matt Mullenweg won her heart “back then” by copping to WordPress’s shortcomings – where it wasn’t a fit for some projects.
All of this is a long way of saying that when we assert WordPress as a solution, I try to suppress the fanboy (and salesman) in me shouting “go WordPress!” by asking myself, “Objectively, is WordPress the answer to this question?” Would I be selling WordPress as an app platform because it’s a great solution, or because I know WordPress? As a web professional, pushing WordPress to a client in the face of clearly better suited alternative is, from my perspective, tantamount to professional malpractice.
Is WordPress a good app platform, today?
So let’s get this out of the way: if you’ve been around the WordPress ecosystem for at least as long as I have (circa 7 years), you might remember a little project called BackPress. BackPress was a project intended to abstract and branch the application platform layer from WordPress so that it could be used as a framework for projects like bbPress 2.
As you probably know, bbPress 2 eventually ended up restarting as a WordPress dependant plugin, brilliantly engineered (by now 10upper then Automattician John James Jacoby) using WordPress’s native information architecture: there’s not one custom table in there. It’s a shining example of WordPress’s app platform potential. At least, until you listen to John describe the hoops he jumped through to make this work. That doesn’t mean bbPress 2 isn’t a great piece of software: it means if John came out of the woodwork today looking for a platform, its unlikely he would have selected WordPress. He did so because he wanted to add a forum layer atop a publishing system.
Perhaps needless to say, BackPress isn’t exactly alive and kicking. Read that again: the last project effectively intended to abstract WordPress’s application layer failed. In fairness, WordPress has grown quite a bit since the inception of BackPress. Was BackPress just a victim of bad timing?
I’ve presented on the evolution of WordPress’s data model, describing our increasingly abstracted model. Attending engineers (who weren’t falling asleep) like Mark Jaquith and Erick Hitter told me they were amused to look back at tables like “linkcatagories”, “post2cat”, and “link2cat”. It’s easy to forget the earliest releases of WordPress didn’t even have object (post) meta.
Still, it’s hard to look at fields like “ping_status” and “comment_status” in our objects table (or, “posts” table), to say nothing of tables dedicated to “links” and “comments”, and call this the schema of an optimized, generalized application platform, and not simply a highly flexible publishing data model.
Worse, our taxonomy architecture has fundamental flaws (watch the WordPress.tv version of my talk), which have kept term meta at bay for years (and fostered some ugly, unresolved bugs). Andrew Nacin, whom I’ve been annoying about this for at least two years, now assures us that he has a plan and that this is on the roadmap… thanks to app platform focus. Whatever I think about our end goal – we’ll come back to this – the Machiavellian in me is smirking.
There are other app platform hallmarks missing, like lack of efficient 1:1 object relationships. And while awkward naming conventions for objects derived from the “posts” heritage are, in reality, superficial, we have to admit, they are also confusing to would be app developers considering WordPress.
These are solvable problems. Still, we have a long row to hoe – and on the merits of abstracted data model and app platform, I’m not sure, objectively, that we can win an engineering argument.
You might remember a little project called BackPress.
About one month ago, I made a hard pitch to a versatile software engineer I admire to join 10up. He agonized over the choice for days before declining with a confession: “10up is an amazing company where anyone could learn a ton, and I can’t wait to see what your employees bring to the WP core in the coming years. WordPress just isn’t where I want to take my career, and I wouldn’t feel right giving you the work of someone who wasn’t 100% behind what 10up is trying to do.” Before sending me this final note (a model for “how to decline a job”), he admitted that if I was selling Symfony or some “more modern,” more powerful framework, he would take the job in a heartbeat.
During the WordCamp San Francisco after party, I told this story to Matt Mullenweg: “We need those elite engineers.” He told me I “dodged a bullet”: the idealist engineers never work out in a business-minded environment. He’s right (Yet Another Future Blog Post™). But I’m also not wrong. If we make WordPress about the ideals of openness and democratization of publishing, we’ll find great engineers who embrace this vision and roll their eyes at elitist programmers.
Seriously. @pdclark's story is the reason I keep working with WordPress. #wcpdx
— Eric Mann (@EricMann) August 10, 2013
Paul Clark’s (@pdclark) genuinely inspirational story wasn’t about database models or programming.
Positioned as an app platform, WordPress has a different case to plead: one based on engineering merit. To this point, I recently asked Nacin whether he thought PHP underpinnings posed a threat to WordPress. He paused uncharacteristically, after swatting my preceding points aside, and then said, “Maybe.”
So can we “reinvent” WordPress? With a rapid release cycle model, can we organically grow into a competitive, serious app platform and win not just the content management market, but a meaningful share of the bigger platform market? And if so, what does WordPress actually look like at the end of that path? This takes me to my next point.
Automated updates == backwards compatibility != radical reinvention
Earlier in the summer, I shared the stage with Acquia’s Chief Marketing Officer, Tom Wentworth, at CMS Expo, where we 7 panelists supposedly made the case for our content management system (Acquia is to Drupal loosely what Automattic is to WordPress). After expected belittling of WordPress as a publishing platform (“use Drupal if you want to make WordPress”), Tom touted the fantastic developer tools coming in Drupal 8, including Symfony underpinnings. I reminded the audience that far from an automatic update, Drupal 8 will require a rewrite of any websites. I asked why, if you’re a publisher (most at this CMS conference were), and not a hardcore engineer, you would want to rebuild every couple of years.
Nothing settles the CMS debate like 7 people with 40 minutes.
Even as an enterprise-centric vendor, I disagree with the vocal chorus objecting to WordPress’s intention to integrate automatic version updates. There will absolutely be a subset of use cases for whom disabling auto-updates will be critical, just like they disable WordPress’s current one click notice – the kind of highly controlled enterprise business environment that also disables automatic Windows updates. The “consumer” majority, however, will benefit from well executed, background updates. This is the future of software, this is why many organizations – including enterprises – embrace platforms as a service (PaaS) like WordPress.com and its VIP offshoot – and we should embrace this. And let’s remember, those large enterprises will not have trouble paying for someone to find the “don’t update” switch, even if it’s a constant “buried” in wp-config.
Here comes the “but”. This works in a “customer” or “consumer” centric vision, where we put the software’s use case (in our case, publishing content) above engineering purity. We can’t release an “automatic update” that breaks functionality. That’s perfectly consistent with WordPress’s aggressive backwards compatibility and rapidly growing “deprecated” scripts.
But… The audience for an “app platform” is very different then the audience for a “publishing system”: they are developers and engineers seeking sleek, modern tools. Even practical WordPress-loving engineers can be heard grousing about inconsistent naming conventions and difficult (virtually impossible?) to deprecate data models like our infamous $post and $wp_query super globals or fundamentally baked in, aging components like TinyMCE (the visual editor).
The audience for an “app platform” is very different then the audience for a “publishing system”…
In short: winning the hearts and minds of app engineers will necessitate a greater willingness to break old conventions which will break websites. Historically, we’ve been justifiably loathe – but willing – to break edge cases. That willingness took a dip with built-in, one click updates (in fairness: its conceivable the need simply took a dip, as WordPress matured). Now imagine background auto-updating.
Think of it this way: automated patch and service pack updating built into Windows and OS X (it’s coming in Mavericks) makes sense: it’s a natural evolution of ease of use for consumers. Now imagine an automated update from Windows XP to Windows Vista, or Windows 7 to Windows 8, or, even crazier, Windows 98 to Windows XP (let’s agree to pretend Windows Me didn’t happen). In each of those cases, Microsoft was willing to break support for certain API’s and data models (in fact, hardware driver incompatibilities between Vista and XP was a necessary step in the right direction, but actually contributed to early Vista woes, as consumers expected seamless upgrades). If Microsoft thought it could forever incrementally upgrade Windows XP, it might have had better consumer luck. It would also eventually die for want of developer abandonment – Windows is, after all, an operating system, what you might call a “desktop app” platform.
Tangent: even as I run a business focused mostly on larger business customers, I fervently advocate for consumer focus. Everyone is a consumer, including Chief Executives and IT Department managers, and passion for their consumer gadgetry infiltrates business. Microsoft Windows didn’t start as an enterprise-focused product, nor did the iPhone or Android. WordPress didn’t start in the enterprise. Each evolved to support those customer bases, sometimes awkwardly, driven by strong consumer tastes. This has afforded each of them long legs.
Is this all a matter of positioning?
I keep going back to the “platform stack” slide from the State of the Word that kicked this all off, thinking “this is right.” Thinking of WordPress as having layers, with uses cases (CMS, blog) as subsets of the low level, more abstracted information architecture and helpers is right. In fact, it strikes me as a touch ironic that this kind of thinking – separating the data structure and interaction from presentation (be it a website or app) – is in many ways a cop to the hardcore software engineers pushing WordPress to adopt a more refined MVC architecture.
That said, I think it’s inaccurate to think of “CMS” and “Blogging” as fundamentally different applications, as opposed to, broadly, “content publishing.” Within this frame, I don’t see the platform “layer” as a broadly abstract, separable platform. The app platform layer is built and optimized for content delivery by no accident of it being WordPress’s original intention.
Matt’s slide introducing the App Platform notion. It’s right to think of WordPress as an underlying content publishing platform. That doesn’t make it a generalized app platform.
So, if all Matt is saying is that the model and controllers should be thought of more as independent components to strengthen content delivery use cases like blogging and CMS, well then, breath wasted. I just don’t think we call that an “app platform.” Maybe a “publishing platform”.
I want to pull for the Cadillac of publishing systems, not the Visual Basic of application platforms.
If, however, our leadership intends to market position WordPress as a generalized “app platform” instead of a “publishing system”, my objection stands. I prefer to sell and apply the best solution. I want to pull for the Cadillac of publishing systems, not the Visual Basic of application platforms. (For those unaware: Visual Basic was… is?… known as a low barrier to entry, simpler programming language for Windows, but has never been taken seriously for more sophisticated or premium desktop applications.)
Right heading, wrong destination
Back to that aging, would-be Olympian from the first paragraph. I’ll wait while you re-read that. An old friend from my defense contractor days used to say, “Professionalism is understanding one’s limits.”
As a publishing engine, I’d pit WordPress against any competitor, certainly amongst open source alternatives that let publishers own their data. As an app platform? Just as our would be athlete has two legs and is capable of running, there are some solid use cases for WordPress as a platform, when the data model fits, which I’d call “content centric apps” or “publisher apps”. Which is why I think we should reframe WordPress not as a general purpose application platform, but as a “content delivery platform” or “publishing platform”.
…I think we should reframe WordPress not as a general purpose application platform, but as a “content delivery platform”…
In pursuing his dream, our aging Olympian in training will lose some fat, strengthen his core, and probably add years to his life and career. The added physical and mental strength will enable him to be outstanding at his craft (let’s say, construction) for years to come, rather than atrophying as he settles for his current crown as, um, best construction crew leader.
By refocusing on our underlying architecture, WordPress will strengthen its market position, extend its capabilities, and maybe even win over some of those elite engineers. I really do “like the way we’re heading.”
But maybe… our would-be medalist shouldn’t quit his day job.