I've been happy to see that there has been so much positive feedback regarding the Zend Framework. I'd like to thank everyone who have shared their thoughts and suggestions with me either via email or blog postings.
I'm aware that things are a bit fuzzy at this point (vapourware?), although Wez's recent blog posting has definitely made things a bit more real for many.
My intention is to share some of the work as early as possible so that people can start to play around with it. Main reason why we're holding back right now, is because at this point I don't believe we have enough implemented to make a good first impression. We have made some good progress when it comes to modules such as implementations for application-level search (ala Lucene), database access (active record), input filtering and logging but we definitely need to remain focused on the development in order to get it together.
As some know, our ultimate goal for the framework is what we call "Extreme Simplicity". Some might have heard me use that term in some of the talks regarding PHP, and I'd like to bring this concept over to the framework. I believe this is what the PHP spirit is all about and the idea behind it is that it's possible to create very simple & easy-to-use languages&frameworks which still remain powerful and flexible, e.g. PHP, SimpleXML or ext/soap. Sure it's tough, because you have to choose the 80% feature set that you want to implement and not the 100%, and giving up functionality isn't always easy, but by creating what I call a use-at-will architecture you can do that but still let people use other mechanism if they need to (for example, power users of PHP write C extensions, e.g. Yahoo!). Another example of use-at-will is DB access. I believe a large amount of framework users would prefer to use PDO or native DB access, and not ActiveRecord. But people who are looking at creating rapid applications and don't need to go down to the native driver level, would have a much easier time. Both would work which I think is also what people expect.
In any case, the progress we've made is still short from being called a framework. We are currently working on some of the key MVC glue which would really define the framework for what it is. We have gotten some great ideas, especially from 100days who are working with us on the framework. The main challenge is to create a model-controller that is both simple to use and powerful. I definitely wouldn't want to go into what I consider a complicated route such as Java struts. Striking the right balance is hard and it often means implementing just the features, which make it "good enough". In fact, that's harder than doing something which does everything.
I know there have been some questions regarding licensing although Wez' blog entries have cleared most of that up. I definitely think that in order for PHP to continue to be a market leader and kick some of our competitor's butts (you know who you are), it is important to offer the capability for companies to build their solutions on top of something they know won't get them into legal trouble. Today, most companies who are actually doing commercial work around PHP, are building everything from scratch exactly for this reason, which at the end of the day is a big waste of good talented cycles. Software vendors (e.g. SugarCRM) have to be careful because they are building their commercial business around their PHP based application. If you don't have a license to the code you're selling, it can get you in a lot of trouble, therefore Sugar had to build everything from scratch.
So by us putting a CLA in place which is almost identical to the Apache CLA and by having a license which is pretty much a replica of the PHP license, we are enabling non-crippling widespread commercial & non-commercial use and allow users to feel very comfortable with the integrity of the code on which they are building their solutions. In regards to Lukas's post, I'd like to point out that by signing a CLA one doesn't assign their IP to another entity, but rather grant a license, and in addition, make a declaration that the contribution is truly yours and not taken from a third-party. So at the end of the day, contributors are still 100% free to do what they want with theirown code, but just giving us permission to use it in the framework.
I've also seen some comments regarding PEAR, and have had discussions with some of the main PEAR guys and contributors over the past week. I'm glad that the folks that I talked to sees things similar to me. There's a good portion of our community, for who the issue of IP is not significant to their day to day business, who are likely to make usage of PEAR components in conjunction with the Zend Framework. And there's no real reason for it not to be so. There are some great packages in PEAR and the Zend Framework is not aiming at being as rich in functionality as PEAR. Rather, we are trying to take what we think is the important foundation for next-gen Web applications and building that in a very straightforward and simple way, making it easy to build powerful apps on top of it.
Anyway, the main focus right now is to get something ready which we can actually show (re: Vaporware). We are working as hard as we can to get something out quickly. Creating a simple and uniform framework is definitely not an easy task, which is why having a small focused group is so important.
I am planning to give a Webcast with php|architect within a bit over a month where we'll talk more about the framework and hopefully also have some stuff to show. If there's enough to show before that, I'll definitely do so.
Back to work. Thanks again for all the feedback and emails. Keep it coming.
