At the recent Symfony Live conference I used the core team QA to address the audience to push for building new dedicated apps on top of general purpose frameworks like symfony and friends. More importantly those efforts should be released as early as possible in the development process as open source to ensure that others join instead of creating their own and then eventually releasing more and more redundant solutions. See the various symfony CMS solutions are an example of how wrong things can go. We now have several solutions whose architectural differences are either cosmetic or simply bad design decisions probably a result of trying to invent things in the small ecosystem of a company project team. So I was very happy to hear then that phpBB will adopt Symfony 2 for their next version. Hopefully this will become a role model for others.

At the conference we also talked about how to better merge the current CMS efforts for Symfony 2, but I fear that will proof to be tricky. From my experience the easiest approach is to put stuff out there early so that people can pool around a leader (or a hand full of leaders): there might be one or two other competitors that differentiate themselves via fundamentally different approaches (lets say a RDBMS vs. a document store CMS or using flat files or a database for configuration). With the ecosystem we have for CMS solutions for symfony 1.x we have several solutions that were open sourced by companies in the hopes of getting new customers, where collaboration with the community is more a nice side effect than the real focus. There the risk of turf wars is quite high since there would simply be too many potential leaders.

So I hope that there will be a fast mover that will proof to be a good leaders as well. Liip might even attempt to become just that building on top of the Jackalope project to provide a JCR based CMS for the PHP world. I assume phpBB will have a need for various social networking features which many currently popular CMS solutions also offer, so there might also be an opportunity for them to lead some of these aspects, but it might be too large a burden to deal with the Symfony community at large, while they are just joining themselves. Meaning they might also need to convince their developers that this is the way to go, which means they probably want to see more code and less talk.

I was enthusiast at Sf live about the future of CMS. I'm part of the Diem team and I've translated Sympal into french.

So, after the conference, I have sent a mail to Tom (apostrophe) and Jon (sympal) in order to see if we could colaborate for a CMS based on Sf 2.0

Jon was ok, but no answer since. Tom mail does not work ...

I'm quit sad now, I don't know how to make people work together. Any idea is welcome.

We have opened a Wave about CMS with Sf 2.0, give your Wave account if you want to participate.

And so you're also reinventing the wheel instead of joining an already existing FOSS effort? JCR based CMS ... FLOW3, TYPO3v5, PHPCR, TYPO3CR

But in general I agree with you, stick with the FOSS principals, release early, release often, don't reinvent the wheel...

PHPBB on Symfony2? This is great news.

Typo Lukas: you've got symphony in line 7, not Symfony!

@vjousse, Tome generally replies, his email address is not hard to find, try again or tweet to @apostrophenow. Unifying would be great...

Hi Lukas,

You make some good points but I have to disagree with you here.

We developed Apostrophe to scratch our own itch: we needed a CMS that our clients could use to add content to their sites in a variety of ways without inadvertently breaking the site design. So our CMS concentrates on the admin's user experience, extending metaphors already present in the page. It's about design even more than it's about software architecture.

We also wanted to make sure it supported Symfony coding practices we were already having good success with. Therefore slots and engines implemented as Symfony modules, not new abstractions, and a clear lineage back to ideas from sfSimpleCMS.

We open sourced Apostrophe because we saw a win-win situation: other developers are in the same boat (their clients are also frustrated with Drupal administration, and they need a good solution today).

More eyes on our code, more bug reports, more suggestions equals a better system for everyone in the Apostorphe community.

Right now this is working for us in a big way, and it's running in production on a number of client sites. Others on the apostrophenow google group are also happy with it (although they have valid criticisms that we are addressing), and they are building client sites that work. There's no business case for us to screech to a stop and start doing something radically different right now.

Right now we have a team of seven people doing great work with Apostrophe and no interest in stopping that. Evolving it to be better, eventually rewriting it extensively in the Symfony 2.0 timeframe, sure. But unless the marketplace tells us otherwise, we're going to keep doing good business, writing good code and sharing our work with those who like our approach.

Joomla, Wordpress and Drupal are all thought of as CMSes for PHP, but no one is telling them that they must merge. Why? People pick the project that works best for their needs. That's as it should be.

If you like Diem or Sympal's approach better, heck, go ahead and use 'em. This "there can be only one" approach leads to design by committee, and that is not always a good thing.

Ingo: We are working together with the Flow3 guys and are using the same interfaces. The main goal is the same (JCR for PHP), the approach totally different. We (Jackalope) want just to access the proven Apache Jackrabbit, Flow3 wants to write the whole thing in PHP.

But we're talking with each other and agreed on the same interfaces so the two projects may be interchangeable at the end for the users.

i would like to pinch in on google wave
my account : digitalbasegijs@googlewave.com

@Tom: I think you misunderstood me a bit, probably because I wasn't clear. First up I think its awesome that you picked a full stack framework as the foundation of your CMS. This was really the focus of my post. But I think where the many CMS in the symfony ecosystem failed is with unifying the efforts early on in the development process. Like you explained, you first developed it internally and only later open sourced it. Imagine if you would have open sourced earlier. Maybe all those developer hours that went into sympal, diem and friends would have gone into apostrophe!

We are competing in terms of mind share with the likes of Drupal and Joomla. I would be the first to tell them to adopt a full stack framework as their core to actually make development customizations less painful. But they already have a bazillion out of the box features that customers just love (they of course forget that making even small changes can easily become a world of hurt). But in order to get closer in terms of out of the box features, we need to merge efforts.

@Ingo: Aside from the fact that we are in fact collaborating with the Flow3 guys as Chregu mentioned, there is also a very boring reason for "partially" redundant efforts: licensing. The GPL is simply too limiting a licensing when it comes to PHP code in our opinion. We do however greatly appreciate the fact that the Flow3 guys adjusted their license for the interfaces.