# "...and we're baaaack!!" Hi there. If you're here visiting from the CakePHP project, you've probably noticed that activity around the branch of code known as Cake3 (a.k.a. "sandbox", a.k.a. the newly re-architected framework for PHP 5.3) has been a little dormant. Truth be told, we've been working away at it rather diligently. So, why no new commits on the timeline? Well, when we announced it initially, it turned out that not everybody was on the same page. To cut short a long and rather dull story, let's just say there were some miscommunications. As a result, there was some confusion in the community, and we ended up with a lotta 'splainin to do ([Lucy!?](http://www.imdb.com/title/tt0043208/quotes)). After taking a few steps back to get a little perspective on the situation, I realized that ultimately, both the CakePHP project and this sub-project would be better served by spinning it off into its own project under a new name: [ Lithium](http://li3.rad-dev.org/). ## Cake is forking!? Panic!! Whoa, easy now, let's not jump to any hasty conclusions. The fact of the matter is that from the very beginning, this project was written from scratch to be its own entity. It always has been, and that's true whether or not it exists within the CakePHP ecosystem. The same developers who are focused on it now were focused on it when it was a sub-project of CakePHP, and several of them are continuing to contribute to CakePHP and stay active in the community, just as they were when it was called Cake3. One reaction that this idea has been occasionally met with is skepticism: more focus on this project means less focus on CakePHP. However, to take this position is to see Open Source as a zero-sum game: in order for one project to win, another has to lose. This simply isn't the way it works. More diversity generates more interest, and creates opportunities for everyone (note, however, that there are sane limits to this idea. PHP does not need anywhere near the number of frameworks it has, but that topic has already been hashed and re-hashed). Even in cases where there is competition (not to imply that that's the case here, quite the contrary in my view), we're all Open Source, and in the web framework space, we're all dealing with the same fundamental problem set. Maintaining an "us-vs.-them" mentality only causes you to lose out on opportunities for collaboration, and your project & community are the poorer for it. ## Inclusivity by design A lot of my thinking in this department has been shaped by my experiences this past year; specifically, attending various conferences and interacting with developers and community leaders from other framework projects (and most recently at the [ZendCon-hosted](http://it-republik.de/konferenzen/planer/zendcon09_timetable.html) [PHP framework "shootout"](http://it-republik.de/konferenzen/ext_scripts/v2/php/sessions-popup.php?module=zendconf09&id=12097), which ended up being quite a bit more friendly and agreeable than the organizers had hoped, heh). When it comes down to it, the list of things we agree on turns out to be quite a bit longer than the list of things where we differ. Given that, and given some of the recent technical advances in PHP (i.e. [ namespaces](http://www.php.net/manual/en/language.namespaces.rationale.php)), it so happens that it'll be really easy for us to make a whole lot of progress on making our respective projects play nicely together, in a way that allows us each to maintain our own over-arching philosophies, but without having to continually re-invent each others' wheels. Another inspiring example has been observing the leaders of the JavaScript framework communities, and in particular, [John Resig](http://ejohn.org/). John has gone to great lengths to promote inclusivity and collaboration in the JavaScript community as a whole, even releasing multi-project collaborations like the [Sizzle selector engine](http://sizzlejs.com/). ## So what do we do with this? I'm so glad you asked! Back at php|tek in May, I had the opportunity to meet with lead developers and community leaders from several major PHP projects, including [ Solar](http://solarphp.com/), [ PEAR](http://pear.php.net), [ Agavi](http://agavi.org/), [ Symfony](http://www.symfony-project.org/) and [Zend Framework](http://framework.zend.com). The result of that meeting was a set of naming and organizational standards that would allow developers to very easily integrate components from each framework or library in any other. This is a very big deal, and I'm proud to say that Lithium is the first framework to implement this naming standard. Not only that, but we'll be taking the extra step of including explicit support for utilizing other frameworks and libraries (including Solar, Zend, PEAR & others) directly in the core. For any libraries that aren't included, only a few simple lines of configuration are required. In fact, one of our [introductory example applications](http://rad-dev.org/lithium_examples/wiki) uses [ Doctrine](http://www.doctrine-project.org/) as the ORM, just to demonstrate the flexibility that Lithium allows. ## Onward and upward Overall, I'm excited by the future. Not only for new technologies, but the huge opportunity we have to refresh and reboot. Finally, I'd like to extend a special thanks to everyone who put in the tremendous effort required to bring the Lithium project to life: - [Garrett Woodworth](http://twitter.com/gwoo) - [Joël Perras](http://twitter.com/jperras) - [Alexander Morland](http://twitter.com/alkemann) - [David Persson](http://twitter.com/nperson) - [Jon Adams](http://twitter.com/pointlessjon) - [Matt Harris](http://twitter.com/kuja1213) - [Mariano Iglesias](http://twitter.com/mgiglesias) - [Andy Dawson](http://twitter.com/AD7six) - [John Anderson](http://twitter.com/raisinbread) - [Jeff Loiselle](http://twitter.com/phishy) - [Tim Koschützki](http://twitter.com/DarkAngelBGE) - [Felix Geisendörfer](http://twitter.com/felixge) ~ Nate ~