Zend Framework (post is too long so make sure to grab coffee)

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.

Reporting for PHP

Jason Weathersby, BIRT evanglist, just posted a blog entry giving some background for the need of reporting in the PHP world, and briefly mentions our plans for bringing the BIRT reporting system to PHP users.

The BIRT project is being led by Actuate, one of the leading Business Intelligence and Reporting companies, who have openly embraced open-source in the past year, and decided to create an open-source project in their field of endevour. The project includes both a run-time and a WYSIWYG drag&drop environment for easily building reports.

The main reason why I'm so excited about bringing this to PHP, is that like Jason stated, I've seen first hand that the majority of PHP applications have some kind of reporting needs, but a lot of time is spent on building reports and their queries from scratch. A few weeks ago I posted a COM/Excel PHP class on my blog. This class was used in order to create internal reports for our support system. We, like most PHP shops, didn't have a reporting tool at hand so we started with one general report, which became 5, then the reports became more complicated, we needed graphs, we needed more complex queries, and without knowing, we had a dedicated developer on these reports for a couple of months. I believe having reporting tools accessible to the PHP developer, will make a lot of lives easier, and will allow companies not to waste time on reinventing the wheel.

The only problem I see in adoption, assuming the technology is successfully brought to PHP in a simple PHP-spirited way, is in general the low awareness regarding reporting in the PHP space. However, this lack of awareness also exists in other communities, and I believe the availability of tools and best practices would increase awareness.

If you have any thoughts, questions, or feedback please drop me an email.

Ning launched!

I was excited to discover that Ning has finally gone live.
It's a playground for building and hosting social applications, and Ning users are provided access to PHP 5 in order to create their apps.
I think the idea behind Ning is great and hopefully won't we only see a new breed of cool composite apps, but its success would most probably also expose PHP to new communities.

As Ning allows applications to "mutate" by giving users to copy and change other's applications, it will be interesting to see, a few months down the road, what kind of applications emerge.