Back in 2009 SubHub was one of the first companies to build a full website publishing platform on Drupal 7. So convinced were we that it was the key to developing the flexible website-building service that we wanted to offer, we began the build while Drupal 7 was still in beta. But there won’t be a Drupal 8 for SubHub – in 2012 it was back to PHP.
The plan was to extend the self-provisioning model that allowed SubHub clients to set up their own membership websites using our platform and templates, by developing a new ‘app store’ they could use to add functionality as and when they wanted.
Drupal promised the power and versatility we needed to make extra features – such as adding eCommerce functionality, for instance – accessible via a self-service platform. The idea was that clients would simply be able to pick something off the shelf, plug it into their site (and remove it whenever they liked), and their bill would be amended accordingly. This was a distinct advantage over Drupal’s arch-rival WordPress, where plug-ins have to be managed by the website provider. But in reality Drupal didn’t allow for the delivery of the simple, seamless, flexible solution we’d hoped for.
I’ve heard several people say that Drupal gets you 80 per cent of the way very quickly, but pushing through that last 20 per cent to get over the finishing line is a real challenge. We reached that 80 per cent way-marker, more or less. Embracing the open-source philosophy, we started collaborating with other players in the Drupal community, and we got a working app store live in 2010.
However, we soon realised that while the community respected what we were trying to do, they simply didn’t share the same motivation to make Drupal a highly commercial, competitive alternative to WordPress. And if you don’t have strong allies in the open-source world, you’re on your own. As a result, we found we just weren’t getting what we needed from the community or the system. We were looking to increase simplicity and create something that would be highly commercial – which turned out to be at odds with what the Drupal community was all about at its heart.
Drupal members relish large, bespoke projects – like custom builds – and it’s not in their interests to simplify something to the extent that customers can develop apps and websites for themselves. Also the community doesn’t have that inherent ‘commercial ecosystem’ like WordPress – which enables third parties to make a lot of revenue from plug-ins that allow clients to customise their site, for example.
Very often, the modules that developers contribute to the Drupal framework are built and maintained part-time, and as a result they are not always ‘plug and play’. We found we needed to do more work to integrate them into what we built than we’d anticipated, including a lot of testing to get them working properly.
Drupal is essentially very sophisticated and powerful – there’s more complexity in what is created with the system than with its alternatives – and for us that was a bit like using a bazooka when a peashooter might have done the job. A lot of what we wanted to do could have been achieved with much smaller, simpler solutions.
Drupal also makes it tougher for independent companies like us to find and retain talent – because it’s more complex and specialised, Drupal development skills are not as widely held as PHP skills. Drupal developers also tend to have different motivations and this may cause them to miss the most commercially expedient solution.
For SubHub, all of this added up to a development overhead that was greater than it needed to be for the size of the job. Things were not happening quickly enough – tasks were taking us 25 per cent longer to do – and we were spending more on them.
The decision to make a clean break and stop using Drupal was a commercial necessity for us. We’ve scrapped what we built using the framework and rebuilt it using PHP – which is the platform our existing customers’ websites were already sitting on. The free website solution we’d launched on the Drupal platform had 10,000 sign-ups, but we realised we were still a long way from the point at which customers would have all the functionality they needed to fully make the switch to Drupal, so we turned it off and went back to PHP.
PHP becomes even more simple and flexible when used in conjunction with a model view controller (MVC) framework. We began using it with CodeIgniter, and since then things have started moving a lot more quickly. We’re not alone: there have been others who have also announced they are leaving the Drupal world. It just doesn’t seem to be gaining momentum – it’s not becoming any more popular and its limitations are not being addressed. I think it will remain what it is: a select CMS solution without the widely available talent and options that smaller independent companies are seeking.