Back when PHP5 came along in many ways it meant a new stepping stone for PHP. To some extend this was caused by the fact that it was impossible to write E_STRICT compliant code that also worked on PHP4, since initially using "var" for properties didn't pass strict mode. As a result many people used this as an excuse to start over and I think overall this led to higher quality code, since the community had evolved from the skill set, but was held back by the legacy baggage. Then when PHP 5.3 came around with namespaces, it had a similar "cleansing" effect. So evolution was done partly by burning bridges. What is interesting is that with composer I see a process in the community of equal impact, yet instead of burning bridges, its building them.
As more and more projects adopt composer they will not only start using 3rd party code, they will also come to realize how easy it is for them to expose their code to 3rd parties. Obviously NIH syndrome will not be purged from the planet and maybe it should never get purged entirely anyway. But its already quite clear how much the landscape of the PHP community is changing with Symfony2, Doctrine, Zend Framework2, TYPO3 and many other projects having adopted composer.
While this is taking place I still see something odd and while I am going to explain this form the perspective of a Symfony2 user, I guess the same is true for other frameworks too: Higher level, framework dependent pieces of code are still being written in a coupled mindset. Just look on KnpBundles.com and see my many individual users but to some extend even worse groups of Bundles inside a single Github organization provide the same feature sets with more or less the same approach. Also several people are writing monolithic Bundles rather than feature focused solutions providing specific services or controllers.
Just yesterday I was chatting about shopping solutions for Symfony2. There are two well established projects with Vespolina and Sylius and again tons of others. Yet this developer was thinking of starting from scratch because there were certain things he didn't like about the existing solutions. But why this all or nothing mentality? Surely there must be something that works just fine. Why not simply ensure that those features are decoupled into libraries or separate Bundles instead, if they are not already? Then all time and resources can be directed at adding or reimplementing the things that are currently missing or that that do not approach the problem in the preferred way?
Now there is one reason why one might prefer monolithic or tightly coupled Bundles and that is that Symfony2 currently doesn't make it all that easy to manage cross Bundle configuration. Settings need to be repeated, Bundles need to be made aware of other Bundles etc. I think this is an area where we still have to put in work now that we are seeing more and more applications build on top of Symfony2, like for example eZPublish 5. As a first step in this direction I have created a PR that would allow a Bundle to offer a way to preprocess the application configuration to more easily integrate decoupled Bundles while minimizing the manual configuration. I would love to see some feedback, but also some more exploration of how to improve things in this area.