When I left the Drupal project, it was without a doubt the single most formative event of my life. I was involved for years at the heart of an open source community, the vast majority of it on a purely volunteer basis. Yet it took me less than a year of working with it professionally to abandon it all.
Since then, while it's still helped pay the bills, I've always resented it, but kept on observing it from the sidelines. It took me a long while to realize what was actually bothering me. It wasn't the people. They were genuine, honest, dedicated. It was the system they had made themselves part of. A system that's always there, but invisible, only expressed through the choices they collectively make for themselves.
See, because of Anonymous' Scientology protests, I'd been reading up on it. Not the teachings of L. Ron Hubbard, but the organization he created. How it works, which pressures it places on people, what it tells them, and what they tell themselves. One of the most educational videos is an interview with Jason Beghe—a Hollywood actor who followed the religion for decades, before leaving completely disillusioned. The resemblance to my experience was uncanny.
Now, the open source world and Drupal in particular are self-aware enough to laugh at their own cult-like vibes. There are celebrated symbols, massive gatherings, songs and mascots, the lot. That's not the comparison I'm trying to make.
Rather, it's what Scientology convinces people of. To understand it, you have to know how it works.
They find people who are down and offer them a completely supportive environment. They teach them basic academic and motivational skills, and then set them loose on the teachings of L. Ron Hubbard. What follows is a long and manipulative process, taught by others who are also merely cogs in the machine, a bit further up the food chain.
The advice slowly but surely evolves from practical life skills to deluded pseudoscience and science fiction, including promises of perfect health and perfect memory. The Scientologist quickly notices they are not succeeding, not getting any wins. The cognitive dissonance is resolved with a single meme: Scientology works. If it doesn't work, it's because you're applying it wrong. If you can convince people there is meaning somewhere, they will find it, no matter what. Stories of aliens in volcanos might seem ridiculous, but is it any more ridiculous than Moses parting the sea?
This encourages Scientologists to put up a fake facade to each other, and it becomes a giant club of people who are all secretly miserable on the inside. They refuse to admit it to themselves and each other, because it is a taboo in their social circle. Instead, they hope that the next exercise, the next counselling session, the next book or video tape, will be the one that makes everything better. To further fuel this desire, the Church eagerly re-releases old materials with minor updates, often at exorbitant prices.
The overall idea is simple: if you keep giving us your time and money, we will save you, and then you can save the world.
Now let's look at how Drupal operates. The goal of the Drupal project is, by design, one that is perpetual: to build and maintain the Drupal software. It is implicitly assumed that this is so, because the web is always changing. Each release supposedly brings the software in line with the latest trends and brings new, innovative features.
Well first of all, we can now safely observe that is no longer the case. What Drupal has been arduously doing for the past few years is keeping up with what was fashionable several years ago. The websites that the majority of users now spend their time on—Facebook, YouTube, Twitter, Gmail—bear little resemblance to the mid-2000s web portals that Drupal still creates out of the box, or the tools it offers to manage them.
I'd like to propose a radically different view: Drupal is perpetual, because there is no real goal and never really has been. It merely sustains itself.
Whatever it is that Drupal is supposed to be, there is no specification for it. No global plans were ever drawn up, no requirements to verify. The development process is always the same: notice something Drupal does not do, figure out which pieces need to change in order to add it, and then make only those changes. Implicitly, it's assumed that everything that currently is, should be. That somehow, an invisible person has gone over it all, and decided that this is still the best way to realize their master plan.
There is no-one doing that. The list of people who remember where it all came from only gets shorter. The one person who is ostensibly at the top hasn't done any actual architecting in years. Can he still look at any line of the code and know what it does? Can anyone else?
For example, when the Drupal project sets its mind to usability, the question is always, "Which new components can we build to improve this UI?" These are two questions that have been mangled into one: What's the best UI for this scenario? and Which components do we need to make good UIs? Instead of focusing on the end-result, the focus is on the process of development: to make Drupal better, piece by piece. Better for what?
Take Spark Drupal, the effort to add inline editing. It's an admirable goal to add WYSIWYG. But what is being built bears little resemblance to what was considered normal in desktop publishing a decade ago. When you create a new document on the desktop, you get an empty document. You flip from slide to slide in Keynote as you click and drag and edit. You don't fill out a form and save the file first before seeing it. Neither do you have to save the title separately from the body.
The act of inline editing isn't something that should be done piecemeal, textfield by textfield. Rather, a user should be presented with the website as an open canvas, able to make any number of changes freely. They should be able to click around, see a change in context on multiple pages, and publish them after. Unsaved changes shouldn't be an exceptional edge case to be solved with a Yes/No popup, they should be the primary way of interacting with the system.
The problem here is one of architecture: Drupal's UI layer is incapable of lying. It's only designed to show you the current state of a database. Yet by design, any client-side UI has to show you what you want to see, rather than what's actually stored server side.
That's what we know after decades of experience in building intuitive publishing UIs. If Drupal wants to keep up, why isn't it building that? They are adding styluses to their BlackBerries when they should be designing iPhones.
A similar problem exists in the latest efforts to improve the core architecture with Symfony. See, they're not bringing Drupal into the world of Symfony. They're bringing Symfony into the world of Drupal. The already impossibly-headed hydra is merely being reconfigured and augmented, rather than slain and resurrected from its ashes. There is always an overarching Drupal-way that must be maintained, a sensibility and taste that is superior. Chx said as much: Drupal always did it better. Always. What is that, other than a belief?
The development cycle is then a precarious process of trying to build a product that nobody understands, on a foundation of slowly shifting quicksand. Which then leads to the next release: a giant orgy of enthusiasm, the next best thing, the most amazing Drupal ever. If that's the case, why do developers instantly start developing again? I thought you guys just said you were done fixing things. It's because of what happens next.
The entire Drupal ecosystem springs into action. Clients are notified, updates are scheduled, new development is requisitioned, and the bills get paid. Until the next release, when things will break again. And remember, If your Drupal site is not usable, you're using Drupal wrong. Sound familiar? Don't you just love your vanilla contrib site whose UI resembles Hotmail before Gmail showed them up? Aren't we all happy? If what separates a good Drupal site from a bad one is not found in Drupal at all, then what is the purpose of going through it?
After more than a decade of development, Drupal the Software has already died the death of a thousand cuts several times over. The frog has been cooked by raising the temperature degree by degree. It's now dead, but rather than get rid of it, they've slit it open on the operating table and hooked it up to a Frankenstein-like machine that makes its limbs twitch in a convincing fashion. Enough to impress the clients, and bill them for it, release after release.
The Drupal project was modelled after the successful OS projects of its time, such as the Linux kernel. A core was created, an ecosystem of contributed modules on top. But the Linux kernel works because it has a well defined goal: to provide a complete environment to run native binaries correctly and safely. The purpose of drivers is to provide a uniform abstraction as well as specialize. If an application breaks, someone fucked up, and regression tests are written to avoid it.
In this light, Drupal's insistence that breaking backwards compatibility is necessary to maintain innovation is a complete misdirection. There are no stable APIs, no cleanly separate parts to interface between, nor is their behavior prescribed in anything but the code itself. Everything is connected, and no core changes can be made without forcing everyone to invest again. It is a symptom of an architecture that is perpetually unprepared for the future.
The Drupal community thrives on hard work, respect and admiration. Accomplishments are celebrated, new people are recruited, business deals are struck, and the numbers keep swelling, both the people and the money involved. But whenever Drupal 8 and Drupal 9 will get here, several years from now, they will still have the exact same problem. They'll have built an incomplete answer to two separate questions that were incorrectly smushed together. It's impossible to fix simply by chopping the result in two, you have to reorganize the question itself.
Drupal has always aimed to eliminate the middle men, to empower end-users. Yet it has become the biggest community of middle men around. For Drupal's mission to succeed, it has to be abandoned in its current form entirely, and be reborn as a dozen different solutions to individual problems, each of which can stand alone. Structure, layout, templating, formatting, visualization, interaction, these are the tools of the publisher. Not database entities and router links.
But this article doesn't change anything. Power is never threatened by truth, only by a better lie. Drupal has already been displaced, not by other CMSes, but by hosted services, which provide a better illusion of control than the promise of having the source code. How much control do Drupal clients truly have over it at the end of the day, when it's implemented at a cost of hundreds of dollars per hour, often just for ticking a couple of boxes in the back-end?
It's interesting to note that Drupal's star ascended simultaneously with the release and subsequent stagnation of IE6. Now the dark days of HTML4 are finally behind us, we find Drupal has spent its time solving problems of its own making, rather than showing the way ahead.
I can only conclude that Drupal has become the Scientology of open source. It's an ant mill of sincerity, each person taking their cue from those that came before, all convinced there is cake in the middle. As they march in circles, those that fall off are quickly replaced with others. It is both amazing and terrifying that the internet has allowed such a structure to form, fuelling an entire ecosystem of misplaced commerce with nothing but good intentions. I managed to reach the middle, there was nothing there.
People. Just stop.
Drupal is a tool that can be used to solve problems. It has passionate people who work to improve the tool so that others can use it to solve their problems. It is by no means perfect, just like any other technology on the planet. Bringing in religious parallels is clearly a reflection on the author, and not the community that is being targeted.