I’ll start with just saying I’m a huge fan of history. I am also a huge believer that that to understand something, you have to not only know what the current situation is but how and why you ended up there (Event Sourcing applied to real life).

The history of the PHP community is really interesting, although I’m by no means the best expert on it (Although I’d highly recommend sitting down with Cal Evans or Ben Ramsey to chat about it). Ultimately, the PHP community developed in such a way that it consisted of various silos or micro-ecosystems. These silos are often based around projects but are sometimes also based around locations or languages. Ther PHP community has many sub-communities such as the PHP German-speaking community, or the US PHP Community or the European PHP Community or the Symfony Community or the Drupal Community. There is absolutely nothing wrong with this, and it’s fantastic to see so many different communities revolving around the wider PHP ecosystem.

However, in the past few years, probably down to a few select factors (Composer, OOP, the FIG and more conferences), I feel like the walls are being beaten down between these different communities and that’s a wonderful thing too.

In terms of code, people are sharing libraries a lot more, and the phrase ‘Proudly invented elsewhere’ has become something that people not just say but something people are exactly as the term describes, they are proud to say it. This has been made possible through things like proper OOP/namespacing in PHP and composer; but also a wider attitude change in that no longer is it the case that rolling your own and reinventing the wheel is the first go-to solution (where previously it often would be, and you’d only use someone else’s package if you found it difficult to solve yourself).

On an in-person level, I see more and more new faces at conferences each year, both speaking and attending, at generalised PHP conferences and these people are often people who have been to Symfony or Drupal or WordPress conferences before, and just beginning to reach out to the wider PHP community. Jenny Wong did an amazing keynote at PHP UK a few years ago on just this, the integration of the WordPress community into the wider PHP community which I’d highly recommend watching.

Finally, and most importantly to me, is that different communities are seeing the value in working together towards shared aims. Some years ago, it would have perhaps seemed impossible to think that the frameworks Zend Framework, Symfony, Laravel, Slim could all be sitting around the same table working together; nor that consumer applications phpBB, Drupal, Joomla and eZpublish would also be sitting around that same table, also working together. Yet this is what the PHP FIG has shown (both physically at php[tek] in 2009 but also a body with all of these projects having been members) is possible when people look towards the future and work together. We all have so much we can learn from each other because all these different projects have their own experiences and expert pools, and the fact we’re all willing to teach each other these things in this multi-directional street ensures that everyone benefits. The new PHP FIG mission statement addresses this:

The PHP FIG aims to advance the PHP ecosystem and promote good standards by bringing together projects and people to collaborate

The PHP FIG’s primary aim is not to create standards for technical interoperability, but to bring projects and people from all over the PHP ecosystem together so that they can work together towards common aims.

I believe this is the future of both our industry and our community: with PHP projects that are essentially competitors (including financially in terms of the companies backing these frameworks and applications) working together on shared and common aims. This would both increase the monetary value of our entire ecosystem; but also makes all our lives as developers easier and promotes better package development and optimal usage as developers choose which framework and application they want to use based on their needs and wants as opposed to requirements due to ugly dependency trees or the inability to change your caching library.