On the sustainability of Symfony
At time of writing the Symfony project maintains 34 individual PHP Components and a Full Stack Framework. The components are individual functional bits that can be adopted to PHP applications using Composer and the autoloading mechanism.
The Framework is a mix of code and principes tying the components to form a base for creating custom applications. The Framework offers common functionalities like configuration, authentication, authorisation, caching and form handling.
While the framework is known as an HMVC (Hierarchical Model View Controllel) framework, not come with a defined mechanism for managing the data model. By default many developer use Doctrine which is bundled with the framework along with Monolog for logging and Swiftmailer for sending emails.
Less is more, but focus is essential
In the software world the term bloat means software gathering new features over years and even decades of development. This leads to a text editor that come with built in games or a music player that includes an e-commerce platform for software and media.
The end result is large software with a wealth of functionalities, many of which may be terribly out of date. Is it really necessary for a popular operating system to keep compatibility with a game from thirty years back? Not necessarily.
Software bloat leads to lose of focus, harder maintenance and the eventual decline in popularity. So with Symfony gaining new features with each minor version (according to Semantic Versioning), is the project suspect to bloat?
In addition to software, the Symfony site states that it is also a philosophy of "Embracing and promoting professionalism, best practices, standardization and interoperability of applications".
This may sound grand or pretentious at first, but it holds the key to why Symfony can remain relevant in the future as well. By embracing standards and interoperability between other members in the PHP ecosystem, Symfony itself becomes more valuable for the larger community.
With competing projects like Bolt CMS, Drupal, eZ Platform all sharing the same components for HTTP communications, Symfony turns from a benefactor to a partner in symbiosis. Thanks to wider usage of individual components they're more robust and have multiple parties with a vested interest in maintenance.
The project team needs to keep sharp focus on features that they choose to adopt. In line with the Unix philosophy they should keep "writing programs that do one thing and do it well". For new components this means fulfilling common needs that are relatively stable. The LDAP Component is a good example of a components that fills these attributes.
The framework itself also needs to keep focus on the essentials. Having a basic caching mechanism in place is a requirement for a framework, but for more advanced requirements a specialised solution like Stash is a valid approach.
Being boring is exciting
For me one of the most valuable things in Symfony is the release planning (and timely delivery) and a functioning deprecation process. Being able to throw obsolete things out of software with proper and timely warning is a sign of a mature environment. This was recently done with dropping Assetic from the standard distribution, for example.
This has moved the technology forward incredibly fast. The downside is doubt of adoption, heavy developer investment in technologies that become obsolete in a matter of months. Not to mention "horrible legacy" from only 12 months back.
Discouraging software bloat, avoiding feature arms race and continued investment in the release process will keep Symfony relevant for another decade and beyond.