D8 and Third-Party Code

A friend asked why Drupal has such a Not invented here (NIH) syndrome. Here is my quick rebuttal:

Even before our recent commit of Symfony's Classloader and HttpFoundation components, Drupal core has long history of embracing third party code ...

• Database abstraction layer. Drupal supported both Postgres and MySQL early on. We used the PEAR DB library to support both. We then used our own abstraction layer until Drupal 7 when we became one of the only projects to embrace PHP's PDO abstraction layer.
• Drupal's XMLRPC server is largely based on Incutio.
• Drupal's Testing Framework started with Simpletest . It has since drifted.
• Drupal was the first major project to adopt jQuery. Drupal's vote of confidence helped jQuery surpass MooTools and Prototype. jQuery has gone on to be the most awesome project ever. Drupal 7 uses lots of jQuery plugins and projects, jQuery UI, jQuery Form, jQuery Once, jQuery Cookie, Farbtastic
• Drupal uses the Archive_Tar library from PEAR to zip/unzip packages during web-based module install
• Drupal uses pluggable subsystems to support third party code. Pluggable field storage is our nod to MongoDB, Pluggable cache/session is our nod to Redis and Memcache.
• Drupal 7 adopted PHPass algorithm for secure password hashing.
• Drupal has embraced open standards. OpenID and RDFa come to mind.

Drupal Contrib has a massive number of integrations with 3rd party code. There are simple jQuery plugin wrapper modules, deep ApacheSolr integration, and everything in between. Not even sure how to express how deeply the Contrib community embraces 3rd party code.

I guess that some people mistake Drupal's strict policy of avoiding third party code on cvs.drupal.org and git.drupal.org for NIH. That policy is a legal/licensing decision, and not reflective of our warmth for 3rd party code, IMO.

It us true that it can be hard to get third party code into Drupal core. I think that's true for first party code.