Why is Drupal still a Gated Community?

Submitted by dryer on Sun, 02/21/2016 - 17:54
Drupal is a closed community

The Drupal project is a great example of Open Source. A vibrant community with fanatical users and lots of great events held around the world multiple times a year, all around the world. Drupal is used to create web sites for communities as well as multinational corporations.

Since the launch of Drupal 7, and during the years leading up to Drupal 8 the community has been drumming about becoming a part of the larger PHP community. Some months after the launch of Drupal 8, the relationship with the PHP community and it's members like Symfony remains lopsided. Drupal takes a lot and gives little back.

Drupal is making steps to using more generic PHP methods with Drupal 8.1 by removing packaged dependencies, opting for Composer installs instead. But without making bits and pieces of Drupal reusable to the rest of the PHP community this is of little use. You've got to use the whole of Drupal to use Drupal. Sure you could decouple by using the REST API with JavaScript, but Drupal is hardly unique in that respect.

Where as some pieces could be taken out and become general purpose. The PHP Frameworks have already done that, with Symfony usingZend components and vice versa. The Drupal Commerce project is the best example of sharing, by splitting functions in to general purpose PHP components.

The core Drupal development should go more of this way instead of locking developers to proprietary module mechanisms. By gradually adopting and contributing to a more generic resource handling model with Puli, for example. Duplicating ground level efforts like HTTP caching leads to more duplication and lock-in as opposed to adopting and contributing components applicable more universally.

In the process of what has lead to what Drupal is today, it brought great wealth and power to a lot of people, including Dries Buytaert in the form of Acquia. With vested financial interest in the success of the product, core functionalities like the Content Storage and Views are unlikely to be split out to be exploited elsewhere. Continuing on the path of being a platform for proprietary monoliths is where the money is at.

Individual functionalities a Composer GUI, for example could be built in a way that they could be used in other PHP projects and distributed via Composer, instead of requiring going all-in Drupal by using the closed Drupal.org infrastructure. Be web developers first, PHP developers second and Drupal developers third.

Ask not what PHP can do for Drupal, but what Drupal can do for PHP.