Or rather what is left to do for the Symfony2 community? Obviously there are some missing features, bug fixes, performance enhancements and polish to apply to various parts of our code base. In terms of features, I think the main part that could use some more love is the HttpCache. But by and large, I think we cover everything that we need to cover and we do it quite well. When looking over the 3.0 UPGRADE file I am also not seeing of anything that hurts bad enough that would be a good reason to start working on the next major version. Given that, the question becomes where to direct our attention as a community?
Avid readers of my blog might have noticed a theme in recent blog posts. A while ago I noted that core developers of the early days have become a lot less active. Then I posted about the need to start working on higher level code to make Symfony2 more rapid development friendly. Following this post I blogged about what is missing to make Symfony2 truly great for building REST APIs. Now last evening at DrupalCamp Vienna I was asked what is left to do for the Symfony2 community and it didn't take me long to think of an answer: Bundles!
We have an insane amount of contributors to the core, helping on small to complex tasks. Yet, if you look over the most popular Bundles on knpbundles.com, most are maintained by and large by a single person and with very few contributors. Then again, there is continuous stream of new tickets (both bugs and feature requests). As the lead maintainer of FOSRestBundle, I have repeatedly tried to find additional helping hands but for the most part it is still only me working on the code. KnpMenuBundle and its underlying library has been stalled in development for over a year now. I guess Sonata does have a decently active community. So that is good news, then again Sonata has such a large scope these days, that it needs even more helping hands. This is most evident in the lack of work on the documentation.
But how to redirect the resources? Obviously people work on the things that they need. Then again, some people also like to work for fame as is evident by the excitement around the sensio connect badges and how much pride people associate to being listed in the contributors page. We do have a few Bundles listed in the documentation but this is more a semi random list of Bundles. Maybe one solution is to try and pick a dozen or so Bundles in the community and promote them a bit more within the community? For example by adding them to the docs and giving badges to contributors.
Something we should consider when thinking about the future of Symfony, is the framework is used or will be used to build web apps.
How we build web apps is changing and will change even more, thanks to the maturity of JS in the browser and the quality and power of JS frameworks like AngularJS, Ember, Backbone and friends.
I can speak from experience, we have a large Symfony2 app using many of the nice features from the framework. We have been working on the new version of the app, and most of the UI will be AngularJS based, so Symfony2 will only be used as a REST API server. So the way we use Symfony2 now has changed for us. And I think this trend will continue to grow as more people realize the benefits of using something like AngularJS and as web apps continue to grow in complexity and features.
Please do some sort of spelling checking before publishing; reads like a bike ride on a cobbled street.
I went through the text. I did not find any spelling issues that a spell checker would find. But there were a bunch of grammar and typos ("be" vs "me") issues that I fixed.
I can't say about the badges part, but the philosophy on the docs is to mention any bundles that are "widely accepted", and currently, I don't think we've mentioned enough. This means we're almost being a bit dishonest about how certain problems should be solved. I'll see if I can mention a few more and get a culture around that started :).
I agree that there's a problem with getting people to actively maintain and work on bundles. What if we had a bigger emphasis on releases like we do on the core itself? What if we set timelines for releases - e.g. KnpMenu 2.0 will be April 2013 and here are 5 proposed changes we'd like to get. That may be too much organization for small bundles, but it would also give clarity and urgency to what's needed (get it done before this date or it's not included!).
We don't really know how to "direct the resources". Someone needs to just do some experimenting - like adding a release roadmap feature to KnpBundles.com and factoring it into its score. Maybe that wouldn't work, so we'd try something else. I'm sure something would work, but the missing ingredient is time and motivation. I'm certainly guilty of that :).
Cheer and thanks for bringing these conversations to the surface - hope it goes somewhere!
I think creating unified contribution community where the code can be own/maintained/etc. by the community vs a person, company, or small group would help a great deal in this area. This is a strength of other large open source communities.
I have recently started a movement to do just that:
http://symfonycontrib.com/
How about a "help wanted" marker/section on the KNPBundles site? Combined with their scoring system, it'd be a handy way for people to find projects that are popular and need attention.
As Ryan said, a few bundles are promoted on symfony.com and the documentation: well defined scope of functionalities, good support and also because they fill a gap between the framework and the developer real needs. Other bundles less essential to get a "common" project done - let's say a website with publication, authentication etc... - are only available on github, packagist or knpbundles As Drupal is used to, I think it would be great for developers if symfony.com mention a wide range of bundles, and their documentation, development status, release cycle. I like KnpBundles or SymfonyContrib initiatives (can we use "Symfony" in symfonycontrib.com ?) but they miss IMO some points to be recognized as "by the community for the community" directories of bundles: - Officially recommended by the Symfony documentation - No ads, definitely and clearly maintained by the community Bundles could also be categorized to ease people getting interest with topics they like and want to contribute to. This is the Drupal way, and it helps involving developers in the modules they use, because it is a way to make part of the Drupal community, not only a (fragile) module one.
@Loïc
"can we use "Symfony" in symfonycontrib.com ?"
Yes, the trademark use has been approved by Fabien himself.
@pablo regarding API's using Symfony. This is the problem I'm looking at exactly myself. We're even wondering if PHP make sense anymore for API's in the back-end REST services. The problem with Symfony bundles becomes managing all the dependancies over time. I need to duct tape all these different packages and dependancies to try to get a nice REST service put together with Authentication, etc.
If you start to wander over to other languages all these things already exist (django rest framework or tastypie) and seem to be much better at scaling, full featured and in major use with larger companies.
Is PHP the right tool for everything? Likely not. Just consider what others are using. Even larger companies like Freshbooks are making their API backends in Python.