I know I will get misquoted, I know this will spawn tons of "told you so" and maybe it will cause a panic. Then again it could also be ignored, just like my last attempt at starting a flamewar :-)

The topic at hand is the future, or lack of one, of PEAR. PHP5 in many ways was what PEAR has been waiting for. But PEAR was never able to shed its legacy baggage and to really because a first choice PHP5 repository. At the same time however PEAR's rate of adoption and scope has increased dramatically. So did we go wrong?

I do not think we went wrong. We did the best for our user base. It’s just that for anyone willing to move, there are greener pastures emerging: most notably eZ components and the Zend framework. I find the thought of a company being at the core of a component library particularly appealing, because it guarantees that through its lifetime there will be a certain level of continuity that is impossible to retain within a so large and therefore necessarily loosely structured web of subprojects that we have with PEAR. I am quite certain that the user experience with these projects will be much better than it ever was in PEAR. However as they commit themselves to their code on a much higher level than any maintainer they might also be more hesitant to add features compared to PEAR package maintainers.

What might make these greener pastures a bit weird though is the IP problem. As Wez points out: this is a big issue! However isn't this the end of open source in its original sense? I know it’s cool that I will be able to hack around in eZ's or likely Zend's code. But if I want this to get back into these projects I will have to sign over commercial usage rights to eZ or sign that I own the IP (and did a patent check?) to Zend (at least this is the way it sounds to me). Now I am not bashing either company for this at all. It’s simply a result of how our industry works. Like I said I am quite confident that the quality of code they will release to people will be very high. Also the number of people who are likely to be interested in heavily adapting is probably fairly low and most of them will probably not have an issue to allow eZ publish commercial use or nodding of to Zend that in fact they wrote the code themselves (the patent thing is a bit trickier of course). I just feel saddened that each of these projects will have a limited ability to look at other solutions within the open source eco system, which is one of the key advantages in open source in my eyes: cherry pick the best solutions out there! Then again these guys will get to do all the fun development of PEAR style components on company time, without the bad feeling if neglecting earning money like I always have doing PEAR stuff :-)

Anyways I welcome these new choices. Maybe through this crisis (if there is one) PEAR will also get sufficient inertia to reinvent itself or PEAR will just step aside one day. Somehow with seeing the 1.4 installer come to stability I think there is reason to be hopeful that there is a future for PEAR.

Update: There was a typo that made it sound like I expected Zend to require me to sign over IP to them. I changed the offending "they" to an "I" (making it bold in the process) and I hope things are clearer now.

You're actually implicitly agreeing to assign your contribution to the PHP project whenever you commit anyway. The difference with a CLA is that you're made much more aware of that fact. The CLA is, for all intents and purposes, the same as the Apache CLA.

The ZF license is going to be the same as the PHP license, but with the words PHP Group and PHP swapped out for Zend Technologies and the Zend Framework; in other words, you can use it for what you want for free, provided that you mention it somewhere. If you derive something from it, you can't call the derived thing "the Zend Framework".

Just because the initial work on the ZF is closed, and the commit process is more rigorous, doesn't mean that the project isn't still opensource.

I see this as another step in the evolution of PHP; our users are growing up, so our processes need to grow up accordingly.

With all that CLA nonsense, we will soon see a turning point in the history of PHP.

There will be PHP developers who already sold their souls to what they call "enterprise", that will sign the CLA.

On the other hand there will be many PHP developers, that say no thank you to the blackmail attempt by IBM. If the PHP group adds a CLA to the PHP development process, we will see a lot of people leaving the project.

It was often discussed to fork PHP because of this and that, but there was never enough motivation to do so. This might change the day, the PHP group enforces a CLA on the PHP development process.

And the PHP community will benefit from this in the end. Because the fork will be free of influence from companies like Zend, who have f.e. denied the PHP community for years a bytecode cache or an optimizing compiler, just because they wanted to sell this.

In the end we will see which of the two PHP's will be the better one. The open source one, or the "enterprise" one.

No matter what, the future of PHP will become very interesting.

Hmm,

me either sees some sense in agreements for such projects: People who signed such contracts will be more serious about development as they are sometimes in purely OS development, that is (imho) not taken serious enough sometimes. You have miriads of devs joining projects, some people are just carma collectors, some are just hanging around on mailing lits... etc etc.

That might be cool for people and fun, but anyway, extraordinary results come just from damn hard work. And if there is a big agreement before you start commitin, yeah .. i guess that will lead to more sophisticated code, less heated up discussuions and and a more relaxed point of view in case of such a heated discussion.
All in all thats good for such a framework at all.

What i wonder about: Will there be any standard definitions, so that its easily possible to extend ez/Pear with Zend Framework (or vice versa) easily ?

Anyway we have started to go for a own (PHP4) Framework, and i think its cool for us to see what happens: we have all options to wait one or two .. .(or more likely in our case 5) years and see whats happening.

So far .. if someone is concerned about contracts he has to sign: Hey thats the enterprise world ;)
Welcome to the REAL WORLD PHP ;)

TYPO3 5.0 / FLOW3 is one of the projects who chose to require a signed CLA from their contributors. It introduced was mostly by initiative from Karsten Dambekalns and myself, simply due to the fact that Free / Open Source Software licenses are a closed book to most of us.

All we want is providing our code under a liberate license which in return provides us (the TYPO3 community, backed by our non-profit association) with a minimum protection against misuse by evil companies. What happened in the past with TYPO3 was that companies tried to rebrand and sell our free software. Because it was GPLed, we could intervene. However, GPL is getting so complex (we hardly know if we are allowed our own code from other TYPO3 sub projects or if libraries like Aloha (AGPL) and ExtJS are compatible), we wanted to have the option to switch to another free software license in the future. A CLA is the only way we know of which makes this possible.

Our CLA in particular was taken from the Apache Foundation which we believe is a quite open organization.

We'd love to drop the CLA requirement tomorrow if we have a good solution for the license issue. On the other hand, the number of > 100 people who signed the CLA for contributing to FLOW3 and TYPO3 5.0 doesn't speak completely against it.

In general I also hate the fact that Apache has a CLA and IIRC this is one reason why PHP isn't part of the Apache Foundation these days. Now I am willing to be a bit more forgiving to Apache, because it as an entity is so important for OSS beyond just the source code they hold.

Now in order to be able to do license changes you can use a much more reduced CLA. I guess I never state this clearly enough but not all CLA's are created equal. In general the only issue I really have is with patent clauses. I guess I would also have a problem with CLA's that allow to strip me out of the contributors, but thats not something I have ever seen in practice.

Anyway one solution to your dilemma is of course to just move to the simplified BSD, that license already gives you total freedom to change the license. The GPL doesn't really protect you from rebranding either or at least only so far that improvements need to be licensed to their clients under the GPL as well (note these clients are under no obligation to share these changes with the community).