I'm leaving the Zend Framework project.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

I'm leaving the Zend Framework project.

Kevin McArthur-2
[ http://www.unrest.ca/im-leaving-the-zend-framework ]

In my 2008 book Pro PHP <http://www.apress.com/9781590598191> I wrote of
the criteria one must have in choosing an MVC framework. In it I wrote:

/"The existence of community around an MVC framework is critical. You
should look at what/ /amount of participation is welcomed, and how long
it takes members of the community to //respond to a bug and produce a
patch."/

In 2006 when I became enamoured with the Zend Framework, it was because
of the community. Under the leadership of Bill Karwin and Jayson Minard,
the early ZF project was an open-source utopia. Community developers
were respected and Zend's corporate motivations took a back seat to
tested and true when-its-ready engineering. It truly was open-source
collaboration at its finest.

We had great component leaders, people who knew their subject matter and
who were passionate about development. We did great things and produced
great code -- but then something changed with the project, and many of
those community members that made Zend Framework so successful started
leaving or worse, simply not contributing -- some of us even tried to
fork components with limited success.

Decisions to move to formal versioning were made before it was ready and
later, decisions moved ZF to enforce formal coding processes under the
guise of increasing code quality [or at least the perception of code
quality]. These decisions came at a grave cost.

The stable version requirement meant innovation in core ZF stopped,
postponed instead for a 2.0 version which was to be the saviour of the
architecture. A version 2.0 architecture that, it is clear to me now,
will repeat the mistakes of the past and not deliver useful component
re-usability or return ZF to an innovation architecture as a community
project.

On formal code requirements, my contributions over the years have
largely been as the result of client work. That is, when I improve a
piece of ZF code for my clients, I've contributed it to the project.
However, I can't justify to those clients that they spend time revising
ZF's test suite, writing docs, or playing the politics required to get
the patch accepted. Which means, in the early days, I contributed a lot,
but today I am able to contribute essentially no code, despite the fact
I do regularly improve the ZF library.

I feel Zend Framework is no longer innovating. It has become burdened by
so much process and technical debt that many contributors find they can
do nothing more than become disaffected with the entire process. I
imagine today I feel much like Jurriën Stutterheim did when he penned
his exit letter in May 2010/"Discontinuing my contributions to Zend
Framework"/ saying:

"/What it boils down to is that I've lost a lot of my interest in
helping to develop ZF. The active involvement, of both the Zend team and
the community contributors, that made ZF development so much fun seems
to be mostly gone./"

I agreed publicly with his statements at the time and worked for
community reform -- and we have seen some effort, in the creation of a
community-review team, and in the very recent return of the weekly
summaries. There's a new IRC meeting process being tried out, but it is
now clear to me that it is a complete and total farce, with a general
consensus of: /this isnt getting anywhere, lets charge ahead anyway./

Which brings me to why I am leaving the project today. The ZF 2.0
community engineering process is trying yet again to get off the ground.
What Jurrien spoke of in May 2010 about the engineering of ZF2 holds
true today -- over a year later. Progress towards community architecture
development is still as absent as ever. The process is expected to
happen in the silos of Zend and contributor RFC's, but no real
collaboration is occurring. Conceptual ideas are met not with intrigue,
but with pointers to formal processes that require the all concepts to
be fully pre-formulated and defended as if thesis, [with even the
ludicrous request for benchmarks before a concept has even been defined.]

I tried to push the rope towards discussion of a truly modular
architecture for ZF2 -- but its now clear to me that I have failed, and
the current process requirements and leadership from Zend will make the
kind of community-driven engineering I envision simply impossible to
achieve. The ideas are too conceptual to push through a formal proposal
process, and I'm but one exceptionally busy developer and cannot be
expected to have all the answers. My vision for the framework was one of
collaborative architecture, but what I've found instead is a conflicted
leadership more interested in time constraints and process than in
creating innovative engineering solutions.

So with this message, I defer. I leave it up to those at Zend to make
the next version of /*their* /Zend Framework product. Maybe it will be
awesome, maybe it wont, but one thing is clear, it no longer meets my
definition or requirement for choosing a community MVC framework.

I will continue to support Zend Framework 1.x in my client work, and
evangelise its purpose and history, but given the current trajectory,
its unlikely I'll advocate the ZF 2.0 transition -- instead I will
prefer more progressive frameworks with a strong and elegant design for
ground-up modular architecture and an active and engaged contributor
community.

I do not come by this decision easily nor quickly, and I have met and
worked with many truly amazing developers throughout my time with the
Zend Framework project. I know that there are still those of you out
there fighting for reform and I do truly wish you success and the ZF
community well. I hope that the contributors, some of the most
technically brilliant and exceptionally talented folks
<http://framework.zend.com/community/contributors> in the PHP community,
continue to have a say in Zend Framework's path and development.

For now though, I'm going to refocus my spare-time efforts on my CIRA
leadership campaign <https://www.kevinforcira.ca>, security research,
and making contributions to open-data.

Its been fun,

--

Kevin McArthur

Reply | Threaded
Open this post in threaded view
|

Re: I'm leaving the Zend Framework project.

padraicb
Hi Kevin,

While I'm sorry you feel the need to stop participating in the development of ZF2, I'd ask that you reconsider and contemplate the recent revival of community spirit as a positive development which, while it's feeling it's way back into the rhythm of community development, is already proving very successful in my mind at getting people more aware and capable of helping ZF2 as it progresses. This is a revival in its infancy. It's not particularly well organised but we are making good strides in growing that organisation and pulling level with Zend's built up concepts of what ZF2 will be (you can't influence what you don't know afterall).

> In my 2008 book Pro PHP <http://www.apress.com/9781590598191> I wrote of
> the criteria one must have in choosing an MVC framework. In it I wrote:
>
> /"The existence of community around an MVC framework is critical. You
> should look at what/ /amount of participation is welcomed, and how long it takes
> members of the community to //respond to a bug and produce a patch."/

I am keenly aware of what you're stating above, which is why I've been pushing and poking the idea of getting maintainance under control. The first test of that has been last week's Bug Hunt, and I will continue over the coming weeks to bring that control up to a decent level. We want participation. We want patches and fixes. We need them, and that's the message that should come through loud and clear over the next few Bug Hunts. This very topic has sucked up most of the ZF dedicated time over the past month. I consider that fundamentally important and I'm well aware that Zend can use all the man hours possible from the community on this and other areas.


> In 2006 when I became enamoured with the Zend Framework, it was because of the
> community. Under the leadership of Bill Karwin and Jayson Minard, the early ZF
> project was an open-source utopia. Community developers were respected and
> Zend's corporate motivations took a back seat to tested and true
> when-its-ready engineering. It truly was open-source collaboration at its
> finest.
>
> We had great component leaders, people who knew their subject matter and who
> were passionate about development. We did great things and produced great code
> -- but then something changed with the project, and many of those community
> members that made Zend Framework so successful started leaving or worse, simply
> not contributing -- some of us even tried to fork components with limited
> success.

I joined Zend Framework back in 2006 as a contributor, the original contributors were already abandoning their early contributions at that time. You seem to lay the blame for this at Zend's doorstep but the truth us a lot simpler. Those contributors simply did what many contributors inevitably do. They moved on to other projects and interests. This is not unusual, or strange, or even unexpected. It is just another day in the life of your average open source project. We're both fortunate and cursed to be dealing with a framework. It's a rapidly developing field across many programming languages, and in PHP it's that much harder because there are literally dozens of frameworks with various approaches. The conditions are not exactly perfect for retaining all contributors over the course of many years.


> Decisions to move to formal versioning were made before it was ready and later,
> decisions moved ZF to enforce formal coding processes under the guise of
> increasing code quality [or at least the perception of code quality]. These
> decisions came at a grave cost.

Formal coding processes are the absolute bedrock of any modern software. This holds true in every programming language. Since the early 2000s, PHP has dragged itself out of the gutter of terrible programming practices. Any half-serious library in 2011 will carry a full suite of unit tests, offer a decent set of documentation, and ruthlessly pursue imperfections to Hell and back. The result has been an obvious and clear pick up in quality. Projects from Doctrine to Zend Framework to awesome teeny tiny libraries scattered across Github have helped revolutionise how we build web applications. We've adopted practices such as Agile methodologies which leverage off those processes to rapidly and efficiently develop applications in a way that has proven time and time again to work well.

If these processes make contributions harder, more difficult, and increase the learning curve for new contributors, then so be it. This is stuff professional programmers need to know, live and breath (along with second and third programming languages if they can). Does this give the mere perception of code quality? To a degree, yes, it does. I've remarked on many occasions that PHP developers are overly fond of cheating in their unit tests to make their Code Coverage look good - even though the unit tests are to the point of being utterly useless bullshit. Yet, just recently, when figuring out a bug, I came across a set of unit tests in the Zend Framework written by a younger programmer than I which ticked every box I look for. We can't force everyone to honestly apply good coding processes, but when they do - the maintenance and technical debt is significantly reduced. That is just frickin' good software development. It takes far more patience,
 discipline and, yes, effort, but this is consistent with how things work in PHP. Was Symfony 2 developed free of coding processes? I doubt it, their unit tests are teeming with mock objects and just as big a departure from Symfony 1 as more recent ZF components are from the early days. The same applies to Lithium and most other recently inspired frameworks.


> The stable version requirement meant innovation in core ZF stopped, postponed
> instead for a 2.0 version which was to be the saviour of the architecture. A
> version 2.0 architecture that, it is clear to me now, will repeat the mistakes
> of the past and not deliver useful component re-usability or return ZF to an
> innovation architecture as a community project.

Yet despite the stable version requirement, which is afterall intended to eliminate as much as possible the need for backwards compatibility breaks which make users' lives far harder, we still saw innovation. Zend_View Enhanced, Zend_Application, Zend_Feed_Reader/Writer, and other core components (emphasising my own and Dolf's since those are most familiar to me - others have done just as well!) have heavily influenced the original vision of Zend Framework 1.0. The fact is, the original approach to ZF1 was severely flawed. It emphasised simple solutions to complex problems in certain areas that just did not work. We've innovated out of that where we can and when we can all within the limitations of maintaining backwards compatibility. I haven't seen users complaining or dropping Zend Framework as one of the main go-to frameworks in all that time. We've changed, for the better, very successfully. And how much of that was prompted by the community? I'd say
 quite a big chunk! As for component reusability, this is so high on the agenda that it ranks as one of the most discussed/debated/argued topics on the ML over the past month. The volume of emails on that topic is unbelievably out of proportion with any other feature. We will have Module reusability or, as I'm sure Zend are more than aware, the Zend Framework 2.0 might as well never bother seeing a release. We've seen that debate reveal the requirements, we've seen numerous approaches suggested, and each and every one has reusability at its very core.

> On formal code requirements, my contributions over the years have largely been
> as the result of client work. That is, when I improve a piece of ZF code for my
> clients, I've contributed it to the project. However, I can't justify to
> those clients that they spend time revising ZF's test suite, writing docs,
> or playing the politics required to get the patch accepted. Which means, in the
> early days, I contributed a lot, but today I am able to contribute essentially
> no code, despite the fact I do regularly improve the ZF library.

There are politics in Zend Framework as is inevitable when any group of 2+ people are capable of communicating with each other. But where has this prevented contributions, improvements or patches? The record of accepting proposals is overwhelmingly in the positive and the CR Team was created to speed that up, alas, right at the tail end of ZF 1.x when so few proposals for ZF 1 are realistic or possible to accept as we switched attention to a highly unstable ZF 2.0. Patches, to the degree that they make improvements or add fixes, can be committed to SVN by anyone who has signed a CLA and has the support of the component maintainer (or who takes over the role of maintainer should one be absent). What are these politics blocking contributions?

> I feel Zend Framework is no longer innovating. It has become burdened by so much
> process and technical debt that many contributors find they can do nothing more
> than become disaffected with the entire process. I imagine today I feel much
> like Jurriën Stutterheim did when he penned his exit letter in May
> 2010/"Discontinuing my contributions to Zend Framework"/ saying:
>
> "/What it boils down to is that I've lost a lot of my interest in
> helping to develop ZF. The active involvement, of both the Zend team and the
> community contributors, that made ZF development so much fun seems to be mostly
> gone./"
>
> I agreed publicly with his statements at the time and worked for community
> reform -- and we have seen some effort, in the creation of a community-review
> team, and in the very recent return of the weekly summaries. There's a new
> IRC meeting process being tried out, but it is now clear to me that it is a
> complete and total farce, with a general consensus of: /this isnt getting
> anywhere, lets charge ahead anyway./

I wrote all about this when I penned my Mr Grumpy rant ;). There comes a time when you can either accept the status-quo or fight like a devil to restore something you feel has disappeared. I've committed to fighting my corner when and where I can. I haven't even blogged about my rant because I'm eager to see how this pans out. I don't see the Zend Framework 2.0 as a lost cause to be abandoned, but the next version of a very popular framework I've staked my work on. The MVC? It's barely a prototype. Zend\DI? It's the growing trend in PHP and it's proven exceptionally popular among users and, heck, it's barely a couple of steps up from what Zend_Application already does! How's THAT for innovation? There is a huge hole waiting to be plugged by the community in shaping how ZF 2.0 will emerge. Zend will obviously have their specific direction and the community will always have the opportunity, if they are willing to actually go and exercise it, to influence
 and push that as they need to. You view recent developments as a farce. I view them as initial positive steps taken very rapidly, and believe me I will be the first to bring back Mr Grumpy should they fall off the rails in the future. This isn't a time to abandon a project which is barely two weeks into mending fences with the community and getting them back on board because of what was happening before that change of mood. The "charge ahead anyway" attitude actually has a pretty good purpose - the community has sat on its ass for almost a full year. It's time to forge ahead, get out source code, and start to work on finding out, for real, what does and does not work. We can only continue discussing ideas so long before something tangible must emerge to be tested, critiqued and forked like Hell on Github.

> Which brings me to why I am leaving the project today. The ZF 2.0 community
> engineering process is trying yet again to get off the ground. What Jurrien
> spoke of in May 2010 about the engineering of ZF2 holds true today -- over a
> year later. Progress towards community architecture development is still as
> absent as ever. The process is expected to happen in the silos of Zend and
> contributor RFC's, but no real collaboration is occurring. Conceptual ideas
> are met not with intrigue, but with pointers to formal processes that require
> the all concepts to be fully pre-formulated and defended as if thesis, [with
> even the ludicrous request for benchmarks before a concept has even been
> defined.]

Community needz codes ;). Look, we're all aware a certain amount of work has happened with the community left uninformed and probably losing faith in the development approach. That's pretty much what I and a *lot* of folk I spoke to on IRC were feeling. I wrote that Mr Grumpy rant because I became convinced that Zend were on the edge of completely losing the existing community while blissfully unaware of how close to the cliff edge they'd strayed. But look at the results of one person's single rant - I was not expecting such a response and I'm humbled by the enthusiastic return of the community. We know a lot more about ZF2's direction today than we did just a few short weeks ago. We have a mailing list which is flooded beyond my capability to follow sometimes. We have regular dev meetings on IRC where the community get to collaborate with Zend on making decisions. We have an MVC prototype that all suggestions indicate will turn up very soon. We have a
 gigantic ongoing debate about reusable Modules - which is a sometimes confusing and contentious topic needing a lot of patience since many of us, myself included, are borderline clueless as to the single best approach to take. That will end up being decided by a frequently modified prototype - mark my words.

That is definitely community collaboration at work. I'm sure it frustrates the heck out of Matthew and Ralph having to suddenly handle the email volume ;). Sorry Matthew/Ralph! We've invented the whole RFC idea unexpectedly on the fly to try and steer all that energy towards a community consensus. It's an imperfect and untried approach but it's the best we can come up with to try and make sense of the ML debate while keeping the most relevant points in one or two online references independent of the ML maze. This DOES NOT require a pre-formulated and defended idea - the RFC is a Request For Comment. Not a proposal. As the community converges it will be edited, modified and pushed along until enough people seem to start liking what it says. Nowhere does it say you MUST create an RFC - you can debate all year long on the ML if you wish, but the community will eventually need something to vote on, to exercise all that decision making it has rediscovered it
 has the power to actually use. That is, again, an opportunity for the community to make an actual decision which Zend can accept.

As for my benchmark request, it was merely in response to your suggestion that DI may not perform well. It was never intended to be offensive or a nuisance but a simple observation that without benchmarks, we just do not know anything about how different options perform in reality. It is really hard to estimate performance from an architectural change - that's why we need prototypes of a rough nature to eventually see how that goes. I apologise if my patronising tone offended you - I'm a verbose arrogant ass when I switch on Blog Mode ;). Alas, it's really just my formal writing style misplaced in an informal ML. That explains my need to make silly jokes and overuse smilies to offset it :P.


> I tried to push the rope towards discussion of a truly modular architecture for
> ZF2 -- but its now clear to me that I have failed, and the current process
> requirements and leadership from Zend will make the kind of community-driven
> engineering I envision simply impossible to achieve. The ideas are too
> conceptual to push through a formal proposal process, and I'm but one
> exceptionally busy developer and cannot be expected to have all the answers. My
> vision for the framework was one of collaborative architecture, but what
> I've found instead is a conflicted leadership more interested in time
> constraints and process than in creating innovative engineering solutions.


And I will point out that I also strongly pushed the idea of a RFC. I'm not employed by Zend. Rob Allen created the initial RFC to try and capture some signal from the noisy ML. He also is not employed by Zend. You may not agree, but the entire Module debate has raced way out of Zend's need to ultimately control by now. We have, however, started to lean towards a solution which is reliant on Zend\Tool and Zend\Di. Thats the impression I get, but again, I see using the DIC as a necessity to bind it more closely to the MVC layer as consistently as possible so I'm biased in that direction anyway. Modules have become nothing but community driven.


> So with this message, I defer. I leave it up to those at Zend to make the next
> version of /*their* /Zend Framework product. Maybe it will be awesome, maybe it
> wont, but one thing is clear, it no longer meets my definition or requirement
> for choosing a community MVC framework.
>
> I will continue to support Zend Framework 1.x in my client work, and evangelise
> its purpose and history, but given the current trajectory, its unlikely I'll
> advocate the ZF 2.0 transition -- instead I will prefer more progressive
> frameworks with a strong and elegant design for ground-up modular architecture
> and an active and engaged contributor community.


I truly wish you all the best in your future endeavors. We may butt heads on the ML from time to time, but one outspoken developer to another, your viewpoint has always helped ground some of the debates we've had over the years. I really do hope you'll reconsider when you can think about it. There remains a lot of decisions about ZF 2.0 that the community will influence and with nary a prototype or finalised concept for Modules and other areas, there really is a lot of scope for us all to still influence ZF 2.0's outcome. We're trying to revitalise community involvement and that unfortunately means the community ML is "murder" as I implied at the last dev meeting on IRC :P. At least until we settle back into an agreed direction and start taking out our frustration on source code instead.

Paddy



 
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team



----- Original Message -----

> From: Kevin McArthur <[hidden email]>
> To: "[hidden email]" <[hidden email]>
> Cc:
> Sent: Wednesday, August 31, 2011 9:46 PM
> Subject: [zf-contributors] I'm leaving the Zend Framework project.
>
> [ http://www.unrest.ca/im-leaving-the-zend-framework ]
>
> In my 2008 book Pro PHP <http://www.apress.com/9781590598191> I wrote of
> the criteria one must have in choosing an MVC framework. In it I wrote:
>
> /"The existence of community around an MVC framework is critical. You
> should look at what/ /amount of participation is welcomed, and how long it takes
> members of the community to //respond to a bug and produce a patch."/
>
> In 2006 when I became enamoured with the Zend Framework, it was because of the
> community. Under the leadership of Bill Karwin and Jayson Minard, the early ZF
> project was an open-source utopia. Community developers were respected and
> Zend's corporate motivations took a back seat to tested and true
> when-its-ready engineering. It truly was open-source collaboration at its
> finest.
>
> We had great component leaders, people who knew their subject matter and who
> were passionate about development. We did great things and produced great code
> -- but then something changed with the project, and many of those community
> members that made Zend Framework so successful started leaving or worse, simply
> not contributing -- some of us even tried to fork components with limited
> success.
>
> Decisions to move to formal versioning were made before it was ready and later,
> decisions moved ZF to enforce formal coding processes under the guise of
> increasing code quality [or at least the perception of code quality]. These
> decisions came at a grave cost.
>
> The stable version requirement meant innovation in core ZF stopped, postponed
> instead for a 2.0 version which was to be the saviour of the architecture. A
> version 2.0 architecture that, it is clear to me now, will repeat the mistakes
> of the past and not deliver useful component re-usability or return ZF to an
> innovation architecture as a community project.
>
> On formal code requirements, my contributions over the years have largely been
> as the result of client work. That is, when I improve a piece of ZF code for my
> clients, I've contributed it to the project. However, I can't justify to
> those clients that they spend time revising ZF's test suite, writing docs,
> or playing the politics required to get the patch accepted. Which means, in the
> early days, I contributed a lot, but today I am able to contribute essentially
> no code, despite the fact I do regularly improve the ZF library.
>
> I feel Zend Framework is no longer innovating. It has become burdened by so much
> process and technical debt that many contributors find they can do nothing more
> than become disaffected with the entire process. I imagine today I feel much
> like Jurriën Stutterheim did when he penned his exit letter in May
> 2010/"Discontinuing my contributions to Zend Framework"/ saying:
>
> "/What it boils down to is that I've lost a lot of my interest in
> helping to develop ZF. The active involvement, of both the Zend team and the
> community contributors, that made ZF development so much fun seems to be mostly
> gone./"
>
> I agreed publicly with his statements at the time and worked for community
> reform -- and we have seen some effort, in the creation of a community-review
> team, and in the very recent return of the weekly summaries. There's a new
> IRC meeting process being tried out, but it is now clear to me that it is a
> complete and total farce, with a general consensus of: /this isnt getting
> anywhere, lets charge ahead anyway./
>
> Which brings me to why I am leaving the project today. The ZF 2.0 community
> engineering process is trying yet again to get off the ground. What Jurrien
> spoke of in May 2010 about the engineering of ZF2 holds true today -- over a
> year later. Progress towards community architecture development is still as
> absent as ever. The process is expected to happen in the silos of Zend and
> contributor RFC's, but no real collaboration is occurring. Conceptual ideas
> are met not with intrigue, but with pointers to formal processes that require
> the all concepts to be fully pre-formulated and defended as if thesis, [with
> even the ludicrous request for benchmarks before a concept has even been
> defined.]
>
> I tried to push the rope towards discussion of a truly modular architecture for
> ZF2 -- but its now clear to me that I have failed, and the current process
> requirements and leadership from Zend will make the kind of community-driven
> engineering I envision simply impossible to achieve. The ideas are too
> conceptual to push through a formal proposal process, and I'm but one
> exceptionally busy developer and cannot be expected to have all the answers. My
> vision for the framework was one of collaborative architecture, but what
> I've found instead is a conflicted leadership more interested in time
> constraints and process than in creating innovative engineering solutions.
>
> So with this message, I defer. I leave it up to those at Zend to make the next
> version of /*their* /Zend Framework product. Maybe it will be awesome, maybe it
> wont, but one thing is clear, it no longer meets my definition or requirement
> for choosing a community MVC framework.
>
> I will continue to support Zend Framework 1.x in my client work, and evangelise
> its purpose and history, but given the current trajectory, its unlikely I'll
> advocate the ZF 2.0 transition -- instead I will prefer more progressive
> frameworks with a strong and elegant design for ground-up modular architecture
> and an active and engaged contributor community.
>
> I do not come by this decision easily nor quickly, and I have met and worked
> with many truly amazing developers throughout my time with the Zend Framework
> project. I know that there are still those of you out there fighting for reform
> and I do truly wish you success and the ZF community well. I hope that the
> contributors, some of the most technically brilliant and exceptionally talented
> folks <http://framework.zend.com/community/contributors> in the PHP
> community, continue to have a say in Zend Framework's path and development.
>
> For now though, I'm going to refocus my spare-time efforts on my CIRA
> leadership campaign <https://www.kevinforcira.ca>, security research, and
> making contributions to open-data.
>
> Its been fun,
>
> --
>
> Kevin McArthur
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: I'm leaving the Zend Framework project.

Kevin McArthur-2
Hey paddy,

I get what you're saying about recent progress. I too was willing to
give it one more shot (and I posted my own mr grumpy type threads on
this subject just a few weeks ago).. but I can't keep swimming up stream
here.

Today was the final straw for me in a long long line of issues, and its
been coming to a head for a very long time now.

I've got an *idea* for how ZF2 architecture should work. I've tried to
communicate it, but the message isnt getting through. I'll take some
blame for that, but not all of it. We bark loudly, go back n forth, and
then its 'lets move on... [to the zend solution]'... which isn't a
resolution for me. It says, go ahead community talk, but we're doing it
this way anyway. I don't feel I was heard, and I've tried to play the
process game to the best of my ability -- so something has to give. In
this case, its obviously got to be me.

I've received a lot of email privately today in response to my
resignation from the project, and a lot of it has been 'youve said most
of the reasons i stopped contributing'. I'm not alone here, but there's
really no good motivation for people to pen publicly. I decided to
because it might be one last chance for you guys to get your house in
order. Theres lots of good people here that could still reform this
project -- but I'm not making progress myself, and for that reason I've
got to go.

Best of luck to all you guys, and I do truly mean that.

--

Kevin


On 11-08-31 04:09 PM, Pádraic Brady wrote:

> Hi Kevin,
>
> While I'm sorry you feel the need to stop participating in the development of ZF2, I'd ask that you reconsider and contemplate the recent revival of community spirit as a positive development which, while it's feeling it's way back into the rhythm of community development, is already proving very successful in my mind at getting people more aware and capable of helping ZF2 as it progresses. This is a revival in its infancy. It's not particularly well organised but we are making good strides in growing that organisation and pulling level with Zend's built up concepts of what ZF2 will be (you can't influence what you don't know afterall).
>
>> In my 2008 book Pro PHP<http://www.apress.com/9781590598191>  I wrote of
>> the criteria one must have in choosing an MVC framework. In it I wrote:
>>
>> /"The existence of community around an MVC framework is critical. You
>> should look at what/ /amount of participation is welcomed, and how long it takes
>> members of the community to //respond to a bug and produce a patch."/
> I am keenly aware of what you're stating above, which is why I've been pushing and poking the idea of getting maintainance under control. The first test of that has been last week's Bug Hunt, and I will continue over the coming weeks to bring that control up to a decent level. We want participation. We want patches and fixes. We need them, and that's the message that should come through loud and clear over the next few Bug Hunts. This very topic has sucked up most of the ZF dedicated time over the past month. I consider that fundamentally important and I'm well aware that Zend can use all the man hours possible from the community on this and other areas.
>
>
>> In 2006 when I became enamoured with the Zend Framework, it was because of the
>> community. Under the leadership of Bill Karwin and Jayson Minard, the early ZF
>> project was an open-source utopia. Community developers were respected and
>> Zend's corporate motivations took a back seat to tested and true
>> when-its-ready engineering. It truly was open-source collaboration at its
>> finest.
>>
>> We had great component leaders, people who knew their subject matter and who
>> were passionate about development. We did great things and produced great code
>> -- but then something changed with the project, and many of those community
>> members that made Zend Framework so successful started leaving or worse, simply
>> not contributing -- some of us even tried to fork components with limited
>> success.
> I joined Zend Framework back in 2006 as a contributor, the original contributors were already abandoning their early contributions at that time. You seem to lay the blame for this at Zend's doorstep but the truth us a lot simpler. Those contributors simply did what many contributors inevitably do. They moved on to other projects and interests. This is not unusual, or strange, or even unexpected. It is just another day in the life of your average open source project. We're both fortunate and cursed to be dealing with a framework. It's a rapidly developing field across many programming languages, and in PHP it's that much harder because there are literally dozens of frameworks with various approaches. The conditions are not exactly perfect for retaining all contributors over the course of many years.
>
>
>> Decisions to move to formal versioning were made before it was ready and later,
>> decisions moved ZF to enforce formal coding processes under the guise of
>> increasing code quality [or at least the perception of code quality]. These
>> decisions came at a grave cost.
> Formal coding processes are the absolute bedrock of any modern software. This holds true in every programming language. Since the early 2000s, PHP has dragged itself out of the gutter of terrible programming practices. Any half-serious library in 2011 will carry a full suite of unit tests, offer a decent set of documentation, and ruthlessly pursue imperfections to Hell and back. The result has been an obvious and clear pick up in quality. Projects from Doctrine to Zend Framework to awesome teeny tiny libraries scattered across Github have helped revolutionise how we build web applications. We've adopted practices such as Agile methodologies which leverage off those processes to rapidly and efficiently develop applications in a way that has proven time and time again to work well.
>
> If these processes make contributions harder, more difficult, and increase the learning curve for new contributors, then so be it. This is stuff professional programmers need to know, live and breath (along with second and third programming languages if they can). Does this give the mere perception of code quality? To a degree, yes, it does. I've remarked on many occasions that PHP developers are overly fond of cheating in their unit tests to make their Code Coverage look good - even though the unit tests are to the point of being utterly useless bullshit. Yet, just recently, when figuring out a bug, I came across a set of unit tests in the Zend Framework written by a younger programmer than I which ticked every box I look for. We can't force everyone to honestly apply good coding processes, but when they do - the maintenance and technical debt is significantly reduced. That is just frickin' good software development. It takes far more patience,
>   discipline and, yes, effort, but this is consistent with how things work in PHP. Was Symfony 2 developed free of coding processes? I doubt it, their unit tests are teeming with mock objects and just as big a departure from Symfony 1 as more recent ZF components are from the early days. The same applies to Lithium and most other recently inspired frameworks.
>
>
>> The stable version requirement meant innovation in core ZF stopped, postponed
>> instead for a 2.0 version which was to be the saviour of the architecture. A
>> version 2.0 architecture that, it is clear to me now, will repeat the mistakes
>> of the past and not deliver useful component re-usability or return ZF to an
>> innovation architecture as a community project.
> Yet despite the stable version requirement, which is afterall intended to eliminate as much as possible the need for backwards compatibility breaks which make users' lives far harder, we still saw innovation. Zend_View Enhanced, Zend_Application, Zend_Feed_Reader/Writer, and other core components (emphasising my own and Dolf's since those are most familiar to me - others have done just as well!) have heavily influenced the original vision of Zend Framework 1.0. The fact is, the original approach to ZF1 was severely flawed. It emphasised simple solutions to complex problems in certain areas that just did not work. We've innovated out of that where we can and when we can all within the limitations of maintaining backwards compatibility. I haven't seen users complaining or dropping Zend Framework as one of the main go-to frameworks in all that time. We've changed, for the better, very successfully. And how much of that was prompted by the community? I'd say
>   quite a big chunk! As for component reusability, this is so high on the agenda that it ranks as one of the most discussed/debated/argued topics on the ML over the past month. The volume of emails on that topic is unbelievably out of proportion with any other feature. We will have Module reusability or, as I'm sure Zend are more than aware, the Zend Framework 2.0 might as well never bother seeing a release. We've seen that debate reveal the requirements, we've seen numerous approaches suggested, and each and every one has reusability at its very core.
>
>> On formal code requirements, my contributions over the years have largely been
>> as the result of client work. That is, when I improve a piece of ZF code for my
>> clients, I've contributed it to the project. However, I can't justify to
>> those clients that they spend time revising ZF's test suite, writing docs,
>> or playing the politics required to get the patch accepted. Which means, in the
>> early days, I contributed a lot, but today I am able to contribute essentially
>> no code, despite the fact I do regularly improve the ZF library.
> There are politics in Zend Framework as is inevitable when any group of 2+ people are capable of communicating with each other. But where has this prevented contributions, improvements or patches? The record of accepting proposals is overwhelmingly in the positive and the CR Team was created to speed that up, alas, right at the tail end of ZF 1.x when so few proposals for ZF 1 are realistic or possible to accept as we switched attention to a highly unstable ZF 2.0. Patches, to the degree that they make improvements or add fixes, can be committed to SVN by anyone who has signed a CLA and has the support of the component maintainer (or who takes over the role of maintainer should one be absent). What are these politics blocking contributions?
>
>> I feel Zend Framework is no longer innovating. It has become burdened by so much
>> process and technical debt that many contributors find they can do nothing more
>> than become disaffected with the entire process. I imagine today I feel much
>> like Jurriën Stutterheim did when he penned his exit letter in May
>> 2010/"Discontinuing my contributions to Zend Framework"/ saying:
>>
>> "/What it boils down to is that I've lost a lot of my interest in
>> helping to develop ZF. The active involvement, of both the Zend team and the
>> community contributors, that made ZF development so much fun seems to be mostly
>> gone./"
>>
>> I agreed publicly with his statements at the time and worked for community
>> reform -- and we have seen some effort, in the creation of a community-review
>> team, and in the very recent return of the weekly summaries. There's a new
>> IRC meeting process being tried out, but it is now clear to me that it is a
>> complete and total farce, with a general consensus of: /this isnt getting
>> anywhere, lets charge ahead anyway./
> I wrote all about this when I penned my Mr Grumpy rant ;). There comes a time when you can either accept the status-quo or fight like a devil to restore something you feel has disappeared. I've committed to fighting my corner when and where I can. I haven't even blogged about my rant because I'm eager to see how this pans out. I don't see the Zend Framework 2.0 as a lost cause to be abandoned, but the next version of a very popular framework I've staked my work on. The MVC? It's barely a prototype. Zend\DI? It's the growing trend in PHP and it's proven exceptionally popular among users and, heck, it's barely a couple of steps up from what Zend_Application already does! How's THAT for innovation? There is a huge hole waiting to be plugged by the community in shaping how ZF 2.0 will emerge. Zend will obviously have their specific direction and the community will always have the opportunity, if they are willing to actually go and exercise it, to influence
>   and push that as they need to. You view recent developments as a farce. I view them as initial positive steps taken very rapidly, and believe me I will be the first to bring back Mr Grumpy should they fall off the rails in the future. This isn't a time to abandon a project which is barely two weeks into mending fences with the community and getting them back on board because of what was happening before that change of mood. The "charge ahead anyway" attitude actually has a pretty good purpose - the community has sat on its ass for almost a full year. It's time to forge ahead, get out source code, and start to work on finding out, for real, what does and does not work. We can only continue discussing ideas so long before something tangible must emerge to be tested, critiqued and forked like Hell on Github.
>
>> Which brings me to why I am leaving the project today. The ZF 2.0 community
>> engineering process is trying yet again to get off the ground. What Jurrien
>> spoke of in May 2010 about the engineering of ZF2 holds true today -- over a
>> year later. Progress towards community architecture development is still as
>> absent as ever. The process is expected to happen in the silos of Zend and
>> contributor RFC's, but no real collaboration is occurring. Conceptual ideas
>> are met not with intrigue, but with pointers to formal processes that require
>> the all concepts to be fully pre-formulated and defended as if thesis, [with
>> even the ludicrous request for benchmarks before a concept has even been
>> defined.]
> Community needz codes ;). Look, we're all aware a certain amount of work has happened with the community left uninformed and probably losing faith in the development approach. That's pretty much what I and a *lot* of folk I spoke to on IRC were feeling. I wrote that Mr Grumpy rant because I became convinced that Zend were on the edge of completely losing the existing community while blissfully unaware of how close to the cliff edge they'd strayed. But look at the results of one person's single rant - I was not expecting such a response and I'm humbled by the enthusiastic return of the community. We know a lot more about ZF2's direction today than we did just a few short weeks ago. We have a mailing list which is flooded beyond my capability to follow sometimes. We have regular dev meetings on IRC where the community get to collaborate with Zend on making decisions. We have an MVC prototype that all suggestions indicate will turn up very soon. We have a
>   gigantic ongoing debate about reusable Modules - which is a sometimes confusing and contentious topic needing a lot of patience since many of us, myself included, are borderline clueless as to the single best approach to take. That will end up being decided by a frequently modified prototype - mark my words.
>
> That is definitely community collaboration at work. I'm sure it frustrates the heck out of Matthew and Ralph having to suddenly handle the email volume ;). Sorry Matthew/Ralph! We've invented the whole RFC idea unexpectedly on the fly to try and steer all that energy towards a community consensus. It's an imperfect and untried approach but it's the best we can come up with to try and make sense of the ML debate while keeping the most relevant points in one or two online references independent of the ML maze. This DOES NOT require a pre-formulated and defended idea - the RFC is a Request For Comment. Not a proposal. As the community converges it will be edited, modified and pushed along until enough people seem to start liking what it says. Nowhere does it say you MUST create an RFC - you can debate all year long on the ML if you wish, but the community will eventually need something to vote on, to exercise all that decision making it has rediscovered it
>   has the power to actually use. That is, again, an opportunity for the community to make an actual decision which Zend can accept.
>
> As for my benchmark request, it was merely in response to your suggestion that DI may not perform well. It was never intended to be offensive or a nuisance but a simple observation that without benchmarks, we just do not know anything about how different options perform in reality. It is really hard to estimate performance from an architectural change - that's why we need prototypes of a rough nature to eventually see how that goes. I apologise if my patronising tone offended you - I'm a verbose arrogant ass when I switch on Blog Mode ;). Alas, it's really just my formal writing style misplaced in an informal ML. That explains my need to make silly jokes and overuse smilies to offset it :P.
>
>
>> I tried to push the rope towards discussion of a truly modular architecture for
>> ZF2 -- but its now clear to me that I have failed, and the current process
>> requirements and leadership from Zend will make the kind of community-driven
>> engineering I envision simply impossible to achieve. The ideas are too
>> conceptual to push through a formal proposal process, and I'm but one
>> exceptionally busy developer and cannot be expected to have all the answers. My
>> vision for the framework was one of collaborative architecture, but what
>> I've found instead is a conflicted leadership more interested in time
>> constraints and process than in creating innovative engineering solutions.
>
> And I will point out that I also strongly pushed the idea of a RFC. I'm not employed by Zend. Rob Allen created the initial RFC to try and capture some signal from the noisy ML. He also is not employed by Zend. You may not agree, but the entire Module debate has raced way out of Zend's need to ultimately control by now. We have, however, started to lean towards a solution which is reliant on Zend\Tool and Zend\Di. Thats the impression I get, but again, I see using the DIC as a necessity to bind it more closely to the MVC layer as consistently as possible so I'm biased in that direction anyway. Modules have become nothing but community driven.
>
>
>> So with this message, I defer. I leave it up to those at Zend to make the next
>> version of /*their* /Zend Framework product. Maybe it will be awesome, maybe it
>> wont, but one thing is clear, it no longer meets my definition or requirement
>> for choosing a community MVC framework.
>>
>> I will continue to support Zend Framework 1.x in my client work, and evangelise
>> its purpose and history, but given the current trajectory, its unlikely I'll
>> advocate the ZF 2.0 transition -- instead I will prefer more progressive
>> frameworks with a strong and elegant design for ground-up modular architecture
>> and an active and engaged contributor community.
>
> I truly wish you all the best in your future endeavors. We may butt heads on the ML from time to time, but one outspoken developer to another, your viewpoint has always helped ground some of the debates we've had over the years. I really do hope you'll reconsider when you can think about it. There remains a lot of decisions about ZF 2.0 that the community will influence and with nary a prototype or finalised concept for Modules and other areas, there really is a lot of scope for us all to still influence ZF 2.0's outcome. We're trying to revitalise community involvement and that unfortunately means the community ML is "murder" as I implied at the last dev meeting on IRC :P. At least until we settle back into an agreed direction and start taking out our frustration on source code instead.
>
> Paddy
>
>
>
>  
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
>
>
> ----- Original Message -----
>> From: Kevin McArthur<[hidden email]>
>> To: "[hidden email]"<[hidden email]>
>> Cc:
>> Sent: Wednesday, August 31, 2011 9:46 PM
>> Subject: [zf-contributors] I'm leaving the Zend Framework project.
>>
>> [ http://www.unrest.ca/im-leaving-the-zend-framework ]
>>
>> In my 2008 book Pro PHP<http://www.apress.com/9781590598191>  I wrote of
>> the criteria one must have in choosing an MVC framework. In it I wrote:
>>
>> /"The existence of community around an MVC framework is critical. You
>> should look at what/ /amount of participation is welcomed, and how long it takes
>> members of the community to //respond to a bug and produce a patch."/
>>
>> In 2006 when I became enamoured with the Zend Framework, it was because of the
>> community. Under the leadership of Bill Karwin and Jayson Minard, the early ZF
>> project was an open-source utopia. Community developers were respected and
>> Zend's corporate motivations took a back seat to tested and true
>> when-its-ready engineering. It truly was open-source collaboration at its
>> finest.
>>
>> We had great component leaders, people who knew their subject matter and who
>> were passionate about development. We did great things and produced great code
>> -- but then something changed with the project, and many of those community
>> members that made Zend Framework so successful started leaving or worse, simply
>> not contributing -- some of us even tried to fork components with limited
>> success.
>>
>> Decisions to move to formal versioning were made before it was ready and later,
>> decisions moved ZF to enforce formal coding processes under the guise of
>> increasing code quality [or at least the perception of code quality]. These
>> decisions came at a grave cost.
>>
>> The stable version requirement meant innovation in core ZF stopped, postponed
>> instead for a 2.0 version which was to be the saviour of the architecture. A
>> version 2.0 architecture that, it is clear to me now, will repeat the mistakes
>> of the past and not deliver useful component re-usability or return ZF to an
>> innovation architecture as a community project.
>>
>> On formal code requirements, my contributions over the years have largely been
>> as the result of client work. That is, when I improve a piece of ZF code for my
>> clients, I've contributed it to the project. However, I can't justify to
>> those clients that they spend time revising ZF's test suite, writing docs,
>> or playing the politics required to get the patch accepted. Which means, in the
>> early days, I contributed a lot, but today I am able to contribute essentially
>> no code, despite the fact I do regularly improve the ZF library.
>>
>> I feel Zend Framework is no longer innovating. It has become burdened by so much
>> process and technical debt that many contributors find they can do nothing more
>> than become disaffected with the entire process. I imagine today I feel much
>> like Jurriën Stutterheim did when he penned his exit letter in May
>> 2010/"Discontinuing my contributions to Zend Framework"/ saying:
>>
>> "/What it boils down to is that I've lost a lot of my interest in
>> helping to develop ZF. The active involvement, of both the Zend team and the
>> community contributors, that made ZF development so much fun seems to be mostly
>> gone./"
>>
>> I agreed publicly with his statements at the time and worked for community
>> reform -- and we have seen some effort, in the creation of a community-review
>> team, and in the very recent return of the weekly summaries. There's a new
>> IRC meeting process being tried out, but it is now clear to me that it is a
>> complete and total farce, with a general consensus of: /this isnt getting
>> anywhere, lets charge ahead anyway./
>>
>> Which brings me to why I am leaving the project today. The ZF 2.0 community
>> engineering process is trying yet again to get off the ground. What Jurrien
>> spoke of in May 2010 about the engineering of ZF2 holds true today -- over a
>> year later. Progress towards community architecture development is still as
>> absent as ever. The process is expected to happen in the silos of Zend and
>> contributor RFC's, but no real collaboration is occurring. Conceptual ideas
>> are met not with intrigue, but with pointers to formal processes that require
>> the all concepts to be fully pre-formulated and defended as if thesis, [with
>> even the ludicrous request for benchmarks before a concept has even been
>> defined.]
>>
>> I tried to push the rope towards discussion of a truly modular architecture for
>> ZF2 -- but its now clear to me that I have failed, and the current process
>> requirements and leadership from Zend will make the kind of community-driven
>> engineering I envision simply impossible to achieve. The ideas are too
>> conceptual to push through a formal proposal process, and I'm but one
>> exceptionally busy developer and cannot be expected to have all the answers. My
>> vision for the framework was one of collaborative architecture, but what
>> I've found instead is a conflicted leadership more interested in time
>> constraints and process than in creating innovative engineering solutions.
>>
>> So with this message, I defer. I leave it up to those at Zend to make the next
>> version of /*their* /Zend Framework product. Maybe it will be awesome, maybe it
>> wont, but one thing is clear, it no longer meets my definition or requirement
>> for choosing a community MVC framework.
>>
>> I will continue to support Zend Framework 1.x in my client work, and evangelise
>> its purpose and history, but given the current trajectory, its unlikely I'll
>> advocate the ZF 2.0 transition -- instead I will prefer more progressive
>> frameworks with a strong and elegant design for ground-up modular architecture
>> and an active and engaged contributor community.
>>
>> I do not come by this decision easily nor quickly, and I have met and worked
>> with many truly amazing developers throughout my time with the Zend Framework
>> project. I know that there are still those of you out there fighting for reform
>> and I do truly wish you success and the ZF community well. I hope that the
>> contributors, some of the most technically brilliant and exceptionally talented
>> folks<http://framework.zend.com/community/contributors>  in the PHP
>> community, continue to have a say in Zend Framework's path and development.
>>
>> For now though, I'm going to refocus my spare-time efforts on my CIRA
>> leadership campaign<https://www.kevinforcira.ca>, security research, and
>> making contributions to open-data.
>>
>> Its been fun,
>>
>> --
>>
>> Kevin McArthur
>>
Reply | Threaded
Open this post in threaded view
|

Re: I'm leaving the Zend Framework project.

jboffel
Hi folks,

I ain't comment on all points, I using Zend Framework in differents ways and
differents projects since 2007.
I decided becoming contributor not so long time ago because I did some work
useful for me that I thought could be usefull for others. Even if my work
is, I know, is not going to be as much popular as other every day used
components.

My comment will go on that opinion :
------
There are politics in Zend Framework as is inevitable when any group of 2+
people are capable of communicating with each other. But where has this
prevented contributions, improvements or patches? The record of accepting
proposals is overwhelmingly in the positive and the CR Team was created to
speed that up, alas, right at the tail end of ZF 1.x when so few proposals
for ZF 1 are realistic or possible to accept as we switched attention to a
highly unstable ZF 2.0. Patches, to the degree that they make improvements
or add fixes, can be committed to SVN by anyone who has signed a CLA and has
the support of the component maintainer (or who takes over the role of
maintainer should one be absent). What are these politics blocking
contributions?
------

I'd say, it's making sense, if and only if, any component has a "real"
leader. I mean someone available, ready to understand and analyse paths,
requests and proposals of other members.

The problem is that some components is no man's land place. I contributed
few patchs and new proposals connected to the Zend_Soap area.

I pushed many times to have review or consideration for them directly on IRC
or by mail, I got private mails of people really using my work and
contributing to my work (than I released on the dev wiki when big enough or
directly on issue tracker).

But for now, nothing move, nobody took back leadership on Zend_Soap for
maybe more than 1 year, each time someone give to me a contact suppose to
work on Zend_Soap or to know what is Zend_Soap, this contact send e-mail 1
month later saying he leaves the Zend company for some personal reasons.

Honestly I'm really tired of pushing more and more and I'm thinking on give
up.

It reached a situation that makes impossible to release my work for ZF 1.x
as ZF 2.x is supposed to be achieve in next future. However I still don't
know if someone is really in leadership of the Zend_Soap component for ZF
2.x....
So you're in situation like you want to release something for ZF 1.x, you
have a negative answer because Zend Framework team ask us to wait for ZF
2.x, but it is so far that you lost any motivation to make your proposal
beeing part of the Zend Framework.
And anyway, probably you'll not use ZF 2.x yourself before a while.

It will lead me to two points, first, why we should let ZF 1.x proposals
die? Even ZF 2.x is comming, I'm sure many people will stay long time with
ZF 1.x because it's good for them and they don't need more sofisticated
framework. Worst, for many companies they ain't move fast to PHP 3.x
(required by ZF 2.x).
Until ZF 2.x is ready for production system, ZF 1.x will still have to be
used! I think, when I see how things are going slowly, ZF 2.x is far from
being released for production system. So for me ZF 1.x should still have
full support until ZF 2.x is available in production system.

Second point will be on how to have fast contributions from community, at my
sense, you have 2 solutions, you make easier for people to push themself
their patchs and or contributions to the SVN (possible after sign CLA,
validate the purpose on issue tracker and/or dev wiki and unit tests coming
with the commit) with an "on the fly" review system from people of community
and ultimately from Zend company, before to merge to the main branch, that
makes the system really reactive.

Or you put a real leader available on each components.

Jeannie BOFFEL


2011/9/1 Kevin McArthur <[hidden email]>

> Hey paddy,
>
> I get what you're saying about recent progress. I too was willing to give
> it one more shot (and I posted my own mr grumpy type threads on this subject
> just a few weeks ago).. but I can't keep swimming up stream here.
>
> Today was the final straw for me in a long long line of issues, and its
> been coming to a head for a very long time now.
>
> I've got an *idea* for how ZF2 architecture should work. I've tried to
> communicate it, but the message isnt getting through. I'll take some blame
> for that, but not all of it. We bark loudly, go back n forth, and then its
> 'lets move on... [to the zend solution]'... which isn't a resolution for me.
> It says, go ahead community talk, but we're doing it this way anyway. I
> don't feel I was heard, and I've tried to play the process game to the best
> of my ability -- so something has to give. In this case, its obviously got
> to be me.
>
> I've received a lot of email privately today in response to my resignation
> from the project, and a lot of it has been 'youve said most of the reasons i
> stopped contributing'. I'm not alone here, but there's really no good
> motivation for people to pen publicly. I decided to because it might be one
> last chance for you guys to get your house in order. Theres lots of good
> people here that could still reform this project -- but I'm not making
> progress myself, and for that reason I've got to go.
>
> Best of luck to all you guys, and I do truly mean that.
>
> --
>
> Kevin
>
>
>
> On 11-08-31 04:09 PM, Pádraic Brady wrote:
>
>> Hi Kevin,
>>
>> While I'm sorry you feel the need to stop participating in the development
>> of ZF2, I'd ask that you reconsider and contemplate the recent revival of
>> community spirit as a positive development which, while it's feeling it's
>> way back into the rhythm of community development, is already proving very
>> successful in my mind at getting people more aware and capable of helping
>> ZF2 as it progresses. This is a revival in its infancy. It's not
>> particularly well organised but we are making good strides in growing that
>> organisation and pulling level with Zend's built up concepts of what ZF2
>> will be (you can't influence what you don't know afterall).
>>
>>  In my 2008 book Pro PHP<http://www.apress.com/**9781590598191<http://www.apress.com/9781590598191>>
>>>  I wrote of
>>> the criteria one must have in choosing an MVC framework. In it I wrote:
>>>
>>> /"The existence of community around an MVC framework is critical. You
>>> should look at what/ /amount of participation is welcomed, and how long
>>> it takes
>>> members of the community to //respond to a bug and produce a patch."/
>>>
>> I am keenly aware of what you're stating above, which is why I've been
>> pushing and poking the idea of getting maintainance under control. The first
>> test of that has been last week's Bug Hunt, and I will continue over the
>> coming weeks to bring that control up to a decent level. We want
>> participation. We want patches and fixes. We need them, and that's the
>> message that should come through loud and clear over the next few Bug Hunts.
>> This very topic has sucked up most of the ZF dedicated time over the past
>> month. I consider that fundamentally important and I'm well aware that Zend
>> can use all the man hours possible from the community on this and other
>> areas.
>>
>>
>>  In 2006 when I became enamoured with the Zend Framework, it was because
>>> of the
>>> community. Under the leadership of Bill Karwin and Jayson Minard, the
>>> early ZF
>>> project was an open-source utopia. Community developers were respected
>>> and
>>> Zend's corporate motivations took a back seat to tested and true
>>> when-its-ready engineering. It truly was open-source collaboration at its
>>> finest.
>>>
>>> We had great component leaders, people who knew their subject matter and
>>> who
>>> were passionate about development. We did great things and produced great
>>> code
>>> -- but then something changed with the project, and many of those
>>> community
>>> members that made Zend Framework so successful started leaving or worse,
>>> simply
>>> not contributing -- some of us even tried to fork components with limited
>>> success.
>>>
>> I joined Zend Framework back in 2006 as a contributor, the original
>> contributors were already abandoning their early contributions at that time.
>> You seem to lay the blame for this at Zend's doorstep but the truth us a lot
>> simpler. Those contributors simply did what many contributors inevitably do.
>> They moved on to other projects and interests. This is not unusual, or
>> strange, or even unexpected. It is just another day in the life of your
>> average open source project. We're both fortunate and cursed to be dealing
>> with a framework. It's a rapidly developing field across many programming
>> languages, and in PHP it's that much harder because there are literally
>> dozens of frameworks with various approaches. The conditions are not exactly
>> perfect for retaining all contributors over the course of many years.
>>
>>
>>  Decisions to move to formal versioning were made before it was ready and
>>> later,
>>> decisions moved ZF to enforce formal coding processes under the guise of
>>> increasing code quality [or at least the perception of code quality].
>>> These
>>> decisions came at a grave cost.
>>>
>> Formal coding processes are the absolute bedrock of any modern software.
>> This holds true in every programming language. Since the early 2000s, PHP
>> has dragged itself out of the gutter of terrible programming practices. Any
>> half-serious library in 2011 will carry a full suite of unit tests, offer a
>> decent set of documentation, and ruthlessly pursue imperfections to Hell and
>> back. The result has been an obvious and clear pick up in quality. Projects
>> from Doctrine to Zend Framework to awesome teeny tiny libraries scattered
>> across Github have helped revolutionise how we build web applications. We've
>> adopted practices such as Agile methodologies which leverage off those
>> processes to rapidly and efficiently develop applications in a way that has
>> proven time and time again to work well.
>>
>> If these processes make contributions harder, more difficult, and increase
>> the learning curve for new contributors, then so be it. This is stuff
>> professional programmers need to know, live and breath (along with second
>> and third programming languages if they can). Does this give the mere
>> perception of code quality? To a degree, yes, it does. I've remarked on many
>> occasions that PHP developers are overly fond of cheating in their unit
>> tests to make their Code Coverage look good - even though the unit tests are
>> to the point of being utterly useless bullshit. Yet, just recently, when
>> figuring out a bug, I came across a set of unit tests in the Zend Framework
>> written by a younger programmer than I which ticked every box I look for. We
>> can't force everyone to honestly apply good coding processes, but when they
>> do - the maintenance and technical debt is significantly reduced. That is
>> just frickin' good software development. It takes far more patience,
>>  discipline and, yes, effort, but this is consistent with how things work
>> in PHP. Was Symfony 2 developed free of coding processes? I doubt it, their
>> unit tests are teeming with mock objects and just as big a departure from
>> Symfony 1 as more recent ZF components are from the early days. The same
>> applies to Lithium and most other recently inspired frameworks.
>>
>>
>>  The stable version requirement meant innovation in core ZF stopped,
>>> postponed
>>> instead for a 2.0 version which was to be the saviour of the
>>> architecture. A
>>> version 2.0 architecture that, it is clear to me now, will repeat the
>>> mistakes
>>> of the past and not deliver useful component re-usability or return ZF to
>>> an
>>> innovation architecture as a community project.
>>>
>> Yet despite the stable version requirement, which is afterall intended to
>> eliminate as much as possible the need for backwards compatibility breaks
>> which make users' lives far harder, we still saw innovation. Zend_View
>> Enhanced, Zend_Application, Zend_Feed_Reader/Writer, and other core
>> components (emphasising my own and Dolf's since those are most familiar to
>> me - others have done just as well!) have heavily influenced the original
>> vision of Zend Framework 1.0. The fact is, the original approach to ZF1 was
>> severely flawed. It emphasised simple solutions to complex problems in
>> certain areas that just did not work. We've innovated out of that where we
>> can and when we can all within the limitations of maintaining backwards
>> compatibility. I haven't seen users complaining or dropping Zend Framework
>> as one of the main go-to frameworks in all that time. We've changed, for the
>> better, very successfully. And how much of that was prompted by the
>> community? I'd say
>>  quite a big chunk! As for component reusability, this is so high on the
>> agenda that it ranks as one of the most discussed/debated/argued topics on
>> the ML over the past month. The volume of emails on that topic is
>> unbelievably out of proportion with any other feature. We will have Module
>> reusability or, as I'm sure Zend are more than aware, the Zend Framework 2.0
>> might as well never bother seeing a release. We've seen that debate reveal
>> the requirements, we've seen numerous approaches suggested, and each and
>> every one has reusability at its very core.
>>
>>  On formal code requirements, my contributions over the years have largely
>>> been
>>> as the result of client work. That is, when I improve a piece of ZF code
>>> for my
>>> clients, I've contributed it to the project. However, I can't justify to
>>> those clients that they spend time revising ZF's test suite, writing
>>> docs,
>>> or playing the politics required to get the patch accepted. Which means,
>>> in the
>>> early days, I contributed a lot, but today I am able to contribute
>>> essentially
>>> no code, despite the fact I do regularly improve the ZF library.
>>>
>> There are politics in Zend Framework as is inevitable when any group of 2+
>> people are capable of communicating with each other. But where has this
>> prevented contributions, improvements or patches? The record of accepting
>> proposals is overwhelmingly in the positive and the CR Team was created to
>> speed that up, alas, right at the tail end of ZF 1.x when so few proposals
>> for ZF 1 are realistic or possible to accept as we switched attention to a
>> highly unstable ZF 2.0. Patches, to the degree that they make improvements
>> or add fixes, can be committed to SVN by anyone who has signed a CLA and has
>> the support of the component maintainer (or who takes over the role of
>> maintainer should one be absent). What are these politics blocking
>> contributions?
>>
>>  I feel Zend Framework is no longer innovating. It has become burdened by
>>> so much
>>> process and technical debt that many contributors find they can do
>>> nothing more
>>> than become disaffected with the entire process. I imagine today I feel
>>> much
>>> like Jurriën Stutterheim did when he penned his exit letter in May
>>> 2010/"Discontinuing my contributions to Zend Framework"/ saying:
>>>
>>> "/What it boils down to is that I've lost a lot of my interest in
>>> helping to develop ZF. The active involvement, of both the Zend team and
>>> the
>>> community contributors, that made ZF development so much fun seems to be
>>> mostly
>>> gone./"
>>>
>>> I agreed publicly with his statements at the time and worked for
>>> community
>>> reform -- and we have seen some effort, in the creation of a
>>> community-review
>>> team, and in the very recent return of the weekly summaries. There's a
>>> new
>>> IRC meeting process being tried out, but it is now clear to me that it is
>>> a
>>> complete and total farce, with a general consensus of: /this isnt getting
>>> anywhere, lets charge ahead anyway./
>>>
>> I wrote all about this when I penned my Mr Grumpy rant ;). There comes a
>> time when you can either accept the status-quo or fight like a devil to
>> restore something you feel has disappeared. I've committed to fighting my
>> corner when and where I can. I haven't even blogged about my rant because
>> I'm eager to see how this pans out. I don't see the Zend Framework 2.0 as a
>> lost cause to be abandoned, but the next version of a very popular framework
>> I've staked my work on. The MVC? It's barely a prototype. Zend\DI? It's the
>> growing trend in PHP and it's proven exceptionally popular among users and,
>> heck, it's barely a couple of steps up from what Zend_Application already
>> does! How's THAT for innovation? There is a huge hole waiting to be plugged
>> by the community in shaping how ZF 2.0 will emerge. Zend will obviously have
>> their specific direction and the community will always have the opportunity,
>> if they are willing to actually go and exercise it, to influence
>>  and push that as they need to. You view recent developments as a farce. I
>> view them as initial positive steps taken very rapidly, and believe me I
>> will be the first to bring back Mr Grumpy should they fall off the rails in
>> the future. This isn't a time to abandon a project which is barely two weeks
>> into mending fences with the community and getting them back on board
>> because of what was happening before that change of mood. The "charge ahead
>> anyway" attitude actually has a pretty good purpose - the community has sat
>> on its ass for almost a full year. It's time to forge ahead, get out source
>> code, and start to work on finding out, for real, what does and does not
>> work. We can only continue discussing ideas so long before something
>> tangible must emerge to be tested, critiqued and forked like Hell on Github.
>>
>>  Which brings me to why I am leaving the project today. The ZF 2.0
>>> community
>>> engineering process is trying yet again to get off the ground. What
>>> Jurrien
>>> spoke of in May 2010 about the engineering of ZF2 holds true today --
>>> over a
>>> year later. Progress towards community architecture development is still
>>> as
>>> absent as ever. The process is expected to happen in the silos of Zend
>>> and
>>> contributor RFC's, but no real collaboration is occurring. Conceptual
>>> ideas
>>> are met not with intrigue, but with pointers to formal processes that
>>> require
>>> the all concepts to be fully pre-formulated and defended as if thesis,
>>> [with
>>> even the ludicrous request for benchmarks before a concept has even been
>>> defined.]
>>>
>> Community needz codes ;). Look, we're all aware a certain amount of work
>> has happened with the community left uninformed and probably losing faith in
>> the development approach. That's pretty much what I and a *lot* of folk I
>> spoke to on IRC were feeling. I wrote that Mr Grumpy rant because I became
>> convinced that Zend were on the edge of completely losing the existing
>> community while blissfully unaware of how close to the cliff edge they'd
>> strayed. But look at the results of one person's single rant - I was not
>> expecting such a response and I'm humbled by the enthusiastic return of the
>> community. We know a lot more about ZF2's direction today than we did just a
>> few short weeks ago. We have a mailing list which is flooded beyond my
>> capability to follow sometimes. We have regular dev meetings on IRC where
>> the community get to collaborate with Zend on making decisions. We have an
>> MVC prototype that all suggestions indicate will turn up very soon. We have
>> a
>>  gigantic ongoing debate about reusable Modules - which is a sometimes
>> confusing and contentious topic needing a lot of patience since many of us,
>> myself included, are borderline clueless as to the single best approach to
>> take. That will end up being decided by a frequently modified prototype -
>> mark my words.
>>
>> That is definitely community collaboration at work. I'm sure it frustrates
>> the heck out of Matthew and Ralph having to suddenly handle the email volume
>> ;). Sorry Matthew/Ralph! We've invented the whole RFC idea unexpectedly on
>> the fly to try and steer all that energy towards a community consensus. It's
>> an imperfect and untried approach but it's the best we can come up with to
>> try and make sense of the ML debate while keeping the most relevant points
>> in one or two online references independent of the ML maze. This DOES NOT
>> require a pre-formulated and defended idea - the RFC is a Request For
>> Comment. Not a proposal. As the community converges it will be edited,
>> modified and pushed along until enough people seem to start liking what it
>> says. Nowhere does it say you MUST create an RFC - you can debate all year
>> long on the ML if you wish, but the community will eventually need something
>> to vote on, to exercise all that decision making it has rediscovered it
>>  has the power to actually use. That is, again, an opportunity for the
>> community to make an actual decision which Zend can accept.
>>
>> As for my benchmark request, it was merely in response to your suggestion
>> that DI may not perform well. It was never intended to be offensive or a
>> nuisance but a simple observation that without benchmarks, we just do not
>> know anything about how different options perform in reality. It is really
>> hard to estimate performance from an architectural change - that's why we
>> need prototypes of a rough nature to eventually see how that goes. I
>> apologise if my patronising tone offended you - I'm a verbose arrogant ass
>> when I switch on Blog Mode ;). Alas, it's really just my formal writing
>> style misplaced in an informal ML. That explains my need to make silly jokes
>> and overuse smilies to offset it :P.
>>
>>
>>  I tried to push the rope towards discussion of a truly modular
>>> architecture for
>>> ZF2 -- but its now clear to me that I have failed, and the current
>>> process
>>> requirements and leadership from Zend will make the kind of
>>> community-driven
>>> engineering I envision simply impossible to achieve. The ideas are too
>>> conceptual to push through a formal proposal process, and I'm but one
>>> exceptionally busy developer and cannot be expected to have all the
>>> answers. My
>>> vision for the framework was one of collaborative architecture, but what
>>> I've found instead is a conflicted leadership more interested in time
>>> constraints and process than in creating innovative engineering
>>> solutions.
>>>
>>
>> And I will point out that I also strongly pushed the idea of a RFC. I'm
>> not employed by Zend. Rob Allen created the initial RFC to try and capture
>> some signal from the noisy ML. He also is not employed by Zend. You may not
>> agree, but the entire Module debate has raced way out of Zend's need to
>> ultimately control by now. We have, however, started to lean towards a
>> solution which is reliant on Zend\Tool and Zend\Di. Thats the impression I
>> get, but again, I see using the DIC as a necessity to bind it more closely
>> to the MVC layer as consistently as possible so I'm biased in that direction
>> anyway. Modules have become nothing but community driven.
>>
>>
>>  So with this message, I defer. I leave it up to those at Zend to make the
>>> next
>>> version of /*their* /Zend Framework product. Maybe it will be awesome,
>>> maybe it
>>> wont, but one thing is clear, it no longer meets my definition or
>>> requirement
>>> for choosing a community MVC framework.
>>>
>>> I will continue to support Zend Framework 1.x in my client work, and
>>> evangelise
>>> its purpose and history, but given the current trajectory, its unlikely
>>> I'll
>>> advocate the ZF 2.0 transition -- instead I will prefer more progressive
>>> frameworks with a strong and elegant design for ground-up modular
>>> architecture
>>> and an active and engaged contributor community.
>>>
>>
>> I truly wish you all the best in your future endeavors. We may butt heads
>> on the ML from time to time, but one outspoken developer to another, your
>> viewpoint has always helped ground some of the debates we've had over the
>> years. I really do hope you'll reconsider when you can think about it. There
>> remains a lot of decisions about ZF 2.0 that the community will influence
>> and with nary a prototype or finalised concept for Modules and other areas,
>> there really is a lot of scope for us all to still influence ZF 2.0's
>> outcome. We're trying to revitalise community involvement and that
>> unfortunately means the community ML is "murder" as I implied at the last
>> dev meeting on IRC :P. At least until we settle back into an agreed
>> direction and start taking out our frustration on source code instead.
>>
>> Paddy
>>
>>
>>
>>  Pádraic Brady
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.**com <http://www.survivethedeepend.com>
>> Zend Framework Community Review Team
>>
>>
>>
>> ----- Original Message -----
>>
>>> From: Kevin McArthur<[hidden email]>
>>> To: "[hidden email].**com <[hidden email]>"<
>>> zf-contributors@lists.**zend.com <[hidden email]>>
>>> Cc:
>>> Sent: Wednesday, August 31, 2011 9:46 PM
>>> Subject: [zf-contributors] I'm leaving the Zend Framework project.
>>>
>>> [ http://www.unrest.ca/im-**leaving-the-zend-framework<http://www.unrest.ca/im-leaving-the-zend-framework>]
>>>
>>> In my 2008 book Pro PHP<http://www.apress.com/**9781590598191<http://www.apress.com/9781590598191>>
>>>  I wrote of
>>> the criteria one must have in choosing an MVC framework. In it I wrote:
>>>
>>> /"The existence of community around an MVC framework is critical. You
>>> should look at what/ /amount of participation is welcomed, and how long
>>> it takes
>>> members of the community to //respond to a bug and produce a patch."/
>>>
>>> In 2006 when I became enamoured with the Zend Framework, it was because
>>> of the
>>> community. Under the leadership of Bill Karwin and Jayson Minard, the
>>> early ZF
>>> project was an open-source utopia. Community developers were respected
>>> and
>>> Zend's corporate motivations took a back seat to tested and true
>>> when-its-ready engineering. It truly was open-source collaboration at its
>>> finest.
>>>
>>> We had great component leaders, people who knew their subject matter and
>>> who
>>> were passionate about development. We did great things and produced great
>>> code
>>> -- but then something changed with the project, and many of those
>>> community
>>> members that made Zend Framework so successful started leaving or worse,
>>> simply
>>> not contributing -- some of us even tried to fork components with limited
>>> success.
>>>
>>> Decisions to move to formal versioning were made before it was ready and
>>> later,
>>> decisions moved ZF to enforce formal coding processes under the guise of
>>> increasing code quality [or at least the perception of code quality].
>>> These
>>> decisions came at a grave cost.
>>>
>>> The stable version requirement meant innovation in core ZF stopped,
>>> postponed
>>> instead for a 2.0 version which was to be the saviour of the
>>> architecture. A
>>> version 2.0 architecture that, it is clear to me now, will repeat the
>>> mistakes
>>> of the past and not deliver useful component re-usability or return ZF to
>>> an
>>> innovation architecture as a community project.
>>>
>>> On formal code requirements, my contributions over the years have largely
>>> been
>>> as the result of client work. That is, when I improve a piece of ZF code
>>> for my
>>> clients, I've contributed it to the project. However, I can't justify to
>>> those clients that they spend time revising ZF's test suite, writing
>>> docs,
>>> or playing the politics required to get the patch accepted. Which means,
>>> in the
>>> early days, I contributed a lot, but today I am able to contribute
>>> essentially
>>> no code, despite the fact I do regularly improve the ZF library.
>>>
>>> I feel Zend Framework is no longer innovating. It has become burdened by
>>> so much
>>> process and technical debt that many contributors find they can do
>>> nothing more
>>> than become disaffected with the entire process. I imagine today I feel
>>> much
>>> like Jurriën Stutterheim did when he penned his exit letter in May
>>> 2010/"Discontinuing my contributions to Zend Framework"/ saying:
>>>
>>> "/What it boils down to is that I've lost a lot of my interest in
>>> helping to develop ZF. The active involvement, of both the Zend team and
>>> the
>>> community contributors, that made ZF development so much fun seems to be
>>> mostly
>>> gone./"
>>>
>>> I agreed publicly with his statements at the time and worked for
>>> community
>>> reform -- and we have seen some effort, in the creation of a
>>> community-review
>>> team, and in the very recent return of the weekly summaries. There's a
>>> new
>>> IRC meeting process being tried out, but it is now clear to me that it is
>>> a
>>> complete and total farce, with a general consensus of: /this isnt getting
>>> anywhere, lets charge ahead anyway./
>>>
>>> Which brings me to why I am leaving the project today. The ZF 2.0
>>> community
>>> engineering process is trying yet again to get off the ground. What
>>> Jurrien
>>> spoke of in May 2010 about the engineering of ZF2 holds true today --
>>> over a
>>> year later. Progress towards community architecture development is still
>>> as
>>> absent as ever. The process is expected to happen in the silos of Zend
>>> and
>>> contributor RFC's, but no real collaboration is occurring. Conceptual
>>> ideas
>>> are met not with intrigue, but with pointers to formal processes that
>>> require
>>> the all concepts to be fully pre-formulated and defended as if thesis,
>>> [with
>>> even the ludicrous request for benchmarks before a concept has even been
>>> defined.]
>>>
>>> I tried to push the rope towards discussion of a truly modular
>>> architecture for
>>> ZF2 -- but its now clear to me that I have failed, and the current
>>> process
>>> requirements and leadership from Zend will make the kind of
>>> community-driven
>>> engineering I envision simply impossible to achieve. The ideas are too
>>> conceptual to push through a formal proposal process, and I'm but one
>>> exceptionally busy developer and cannot be expected to have all the
>>> answers. My
>>> vision for the framework was one of collaborative architecture, but what
>>> I've found instead is a conflicted leadership more interested in time
>>> constraints and process than in creating innovative engineering
>>> solutions.
>>>
>>> So with this message, I defer. I leave it up to those at Zend to make the
>>> next
>>> version of /*their* /Zend Framework product. Maybe it will be awesome,
>>> maybe it
>>> wont, but one thing is clear, it no longer meets my definition or
>>> requirement
>>> for choosing a community MVC framework.
>>>
>>> I will continue to support Zend Framework 1.x in my client work, and
>>> evangelise
>>> its purpose and history, but given the current trajectory, its unlikely
>>> I'll
>>> advocate the ZF 2.0 transition -- instead I will prefer more progressive
>>> frameworks with a strong and elegant design for ground-up modular
>>> architecture
>>> and an active and engaged contributor community.
>>>
>>> I do not come by this decision easily nor quickly, and I have met and
>>> worked
>>> with many truly amazing developers throughout my time with the Zend
>>> Framework
>>> project. I know that there are still those of you out there fighting for
>>> reform
>>> and I do truly wish you success and the ZF community well. I hope that
>>> the
>>> contributors, some of the most technically brilliant and exceptionally
>>> talented
>>> folks<http://framework.zend.**com/community/contributors<http://framework.zend.com/community/contributors>>
>>>  in the PHP
>>> community, continue to have a say in Zend Framework's path and
>>> development.
>>>
>>> For now though, I'm going to refocus my spare-time efforts on my CIRA
>>> leadership campaign<https://www.**kevinforcira.ca<https://www.kevinforcira.ca>>,
>>> security research, and
>>> making contributions to open-data.
>>>
>>> Its been fun,
>>>
>>> --
>>>
>>> Kevin McArthur
>>>
>>>