Turning hackability into a use case

I decided to write this article after reading The Decline of Drupal, or How to Fix Drupal 8 by Mike Schinkel. I am not a Drupal person at all, but what is discussed here is quite close to discussion I had with my friends from the Plone community, and I am quite sure it is not restricted to those 2 CMS.

The question here is how to preserve popularity (or maybe just approachability) when we decide to restrict hackability.

And just to make clear what "hackable" means, I will just quote Jennifer Lea Lampton (already quoted in Mike's article):

Back in the day, Drupal used to be hackable. And by "hackable" I mean that any semi-technical yahoo (that's me, btw) who needed a website could get it up and running, and then poke around in the code to see how it all worked. The code was fairly uncomplicated, though often somewhat messy, and that was fine. At the end of the day, it did what you needed.

A CMS story

In the beginning was the Hack

When a CMS is still young, it is still light and fresh, not heavily structured, hence it can be hacked in many ways. Hacking is even probably the official way to use it. And that is precisely what is fun and attracting about it. That is what might turn it into a success.

The first versions of Plone were so easy to hack, we had something we named TTW, standing for Through-The-Web, and designating a fantastic feature of Zope (the Plone application server) allowing to code scripts, templates or even classes directly from the web interface. It was great because it allowed a very large audience to be efficient with Plone.

I guess Drupal had also very attractive hacking possibilities like the Drupal hooks.

To hack or not to hack

But soon, some developers point that such hacking is probably not a good idea. They say hacking might seems smart and efficient and productive, but that is in fact the very opposite. It makes maintainability more difficult, it makes upgrades or migration sometimes totally impossible, it does not conform to the programming standards and best practices.

And they are actually right. But saying so (and being right) is obviously not enough to make people stop hacking.

Nevertheless a gap appears, and new versions are not as hack-friendly as it used to:

- "Hey, I cannot do that anymore!",

- "Right, but if you were doing it the right way, you wouldn't have to do it this way",

- "Mmmmokay...".

You shall not hack

A CMS is continuously evolving, its users expect it to be able to provide the cool new features invented on the web last week, and its developers want it to integrate the bright new frameworks invented on GitHub last month.

At some point, it is quite clear that offering hackabilty restricts its capacity to evolve, and endangers the system. To be able to survive to all the needed changes, it must rely on a strong and strict architecture.

And a version is released where hackabilty is banished (that's what Drupal 8 is about, right? I guess we did it with Plone 3, even if it is not that clear).

I want my hack back

This is probably a wise technical decision, and the core developers are very proud of it. The system is clean now, and we can confidently face our future challenges.

But it is also a very very impopular decision. A big part of the developers were using the hack way because they cannot afford investing time to learn the straight way, some of them do not even understand why the so called "straight way" is that better than their usual way.

By trying to make our CMS better, hence more attractive, we made it impopular. That is really unfortunate.

And if some of those disappointed people consider moving to another solution, ideally a brand new CMS still its early happy-hacking age, I have a bad news for them: there will be no new CMS (see my post Why CMS will not die).

Hacking is not a bug, it is a feature

The problem here is a severe misunderstanding.

Of course, on the development point of view, hackability can be considered as a flaw and a danger, but that is not the proper point of view here. We must consider it with the usage point of view, and regarding usage, hackability is a very valid use case.

It is even a major use case, and our CMS must preserve it, or it will be endangered.

Nevertheless, I agree that banishing hackability from the core is a good decision. So how do we manage that?

That is simple: we just produce a clean/straight/unhackable core, and we implement hackability on top of it as a feature.

Implementing hackability means offering tools to deeply change the behaviour or the appearence of our system without messing with its underlying architecture.

That is what Plone proposes with the Diazo theming tool: as theming was involving too many Plone knowledge, it was unapproachable for non-Plone integrators, so we provide a theming proxy which dynamically injects a static design on any Plone page using a simple set of rules, and it is entirely controlled from a nice web UI.

That is also my objective with Plomino, so people can easily create a custom application that will work in their Plone site without learning about complex frameworks.

But there are of course many other fields to cover.

It is not easy, because building a tool able to provide as much flexibility as code hacks is a complex challenge, but that is the only way to keep our CMS valid (and to keep it fun too), hence to keep our audience.