Break down the silos, PHP developers
Traditionally it has been quite hard (if not impossible in some cases) to merge two PHP applications on the server side in an elegant way. Thanks to the great work by the people in the PHP-FIG (Framework Interoperation Group) on PSR-7, we've got a common standard for achieving this by leveraging the HTTP protocol itself.
Thanks to the recent popularisation of the request-response mindset in the PHP developer community, this will gain more and more ground as the glue for merging applications together. Yet PSR-7 is a great example how tech is secondary to behaviour of people.
Working delivery logistics matter in software
StackPHP has allowed a similar approach to PSR-7 approach since 2013 by allowing development of Symfony HttpKernelInterface middleware. It demonstrates that only when (and if) great ideas reach a large mindshare will they gain mainstream adoption. Another example is the eZ Components project (now Zeta Components). These are high quality PHP components that do a very specific thing - and do it well.
eZ Components were largely developed by eZ Systems, a company that develops the eZ suite of products. eZ Components were adopted in their flagship product eZ Publish, but were not widely used in others. The key thing that lead to this was limited distribution methods. You had to take some extra steps to take eZ Components to use. Autoloaders were not a staple for PHP devs in 2007.
Once we got Composer up and running, it catched on like wildfire partly because the concept was already familiar to many through Node's NPM packet manager. Now it's near zero effort to include third party functionality - certainly easier than including C-extensions to the PHP standard library.
Just as with physical distribution of products, people will buy and use products that are easily available - they might not even be aware of great products not available in their region. Xiaomi smartphones are a great example if this, you've got to go out of your way to buy one in Europe.
Betraying Drupal
This is all great, but at least LAMP CMS developers mostly linger in their own silos. People call themselves Joomla, WordPress, Drupal, developers. Some probably call be an "eZ Publish developer", but I am not. I am a Web Developer with experience mainly in HTML, CSS, JavaScript, PHP and select supporting technologies. On a product level, I'm most routined with eZ and Symfony development currently.
So if we're all web developers, do I need to learn everything? Of course not, you'll just specialize in something. Content Management Systems all do pretty much the same thing, so it's quite quick to grab superficial knowledge and lingo from other similar tools. In companies which use multiple tools, this is a given. If you're in a purely Drupal oriented company, you'll likely not be exposed to discussions on WordPress plugins and security regularly.
Knowing alternatives outside of your core specialization, say Drupal, gives you perspective. You can still focus on Drupal. When deeper insight, hard routine and practical experience are required, that's when your Drupal expertise comes into play. Also consider Puli, a PHP asset manager, which allows us to share template packages, etc. across projects built with different tools.
Aren't you in the PHP/Symfony silo, yourself?
So here I am on a PHP and Symfony blog talking about breaking silos in PHP. But isn't being a PHP developer a huge silo, itself? Sure it is! And I am well aware of this, but given the current state of the technology and userbase I find it very interesting.
Sharing and stability of modern PHP make it interesting for me. Not geek points on using generators, promises and other EcmaScript 2015 goodies, for example. With the JavaScript world in a state of Flux (pun intended), I'll just be on the sidelines until it becomes more stable again. Back End developers turned Async Alpha Male can go home, the Front End has always been async.
The fact that Symfony uses a Zend component for PSR-7 support is a great example why PHP is all grown up. PHP frameworks are collaborating, not just competing. So let's create value, not repeat ourselves. DRY goes beyond code.