Much of the code we are maintaining in Drupal today isn’t actually Drupal specific.
All these are functions or libraries that are either external libraries or that could very easily be part of an external library. None of them is Drupal-specific.
Recently we found a series of problems with Drupal’s OpenID implementation. We should share our implementation with other projects to minimize these sorts of glitches.
It would be not just beneficial to use more of other project’s code but to also make Drupal’s code available to other projects where it makes sense. Consider this example. I have written a PubsubHubbub subscriber and hub in a non-Drupal specific manner. In a nascent technology like PubsubHubbub it is crucial to share on the lowest common denominator: in this case, PHP. It was actually easy to write the library Drupal independent, but it was also a pain not to be able to rely on Drupal’s convenient library: drupal_http_request(), valid_url(), check_plain().
I couldn’t use any of the useful Drupal helper functions like check_plain() although they’re is no reason why they would be Drupal specific.
The application layer on the web is getting shaped by more and more standards and common best practices. We can’t afford to have a Drupal-only implementation for all of them. We need to get better in integrating with non-Drupal specific code. Let’s open the doors.
Let’s write less Drupal code. Alex Barth (alex_b)
Much of the code we are maintaining isn’t actually Drupal-specific.