In the last weeks, I've taken a step back from my involvement into the Joomla project and took a good look at what we achieved. And let me say: Joomla has quite a lot of great and talented developers and basically all the work that has been done by them was good and deserves to be noted.
But I also saw, that we have huge problems. I'm not telling a secret when I'm saying that our releases are not really at a fast pace and we also didn't keep all our promises all the time...
But what is the cause of this?
For some time I've been a member of the Release Team responsible to get 1.6 out of the door, so this is also in some way a critical review of my work. However the reasons for failure were manifold. As I wrote before, the developers of Joomla are great, but what is a real screw up is the management of the project.
Lets look at the different problems in the management:
Features:
There was at no time a really definite, final feature list for 1.6. After 1.5 was released the "core developers" were the only ones doing development work. Some of us started on working on the ACL, others worked on what they wanted to work on, but there was no list of features that we wanted to see in. Then we started the white paper process. That one was nice and all, but in the end we didn't stick to what we got out of that white-paper process. And while all of this was going on, I had some free time and brought up the idea of getting rid of the sections in 1.6 and so that major feature was brought on board.
It wasn't until January 2009 (one year after 1.5 was released) that the Leadership Team created a combined list of features that everybody agreed upon and where everybody thought that we had somebody looking after that. After they failed to deliver those features in the time that they set themselves, they introduced the Release Team and we then tried for months to get them to explain to us, what those different bullet points were supposed to mean.
So after we finally got that info, that list was revised by us together in March/April 2009 and again in September 2009. After that, some entries to that list of bullet points were re-interpreted. It took over a year to really make that list of features that we agreed upon public and at that time it was again outdated, as you can see in some threads on the official mailing lists.
This is not to say that we should be making lists of features and not allow anything else in when they are ready. But this definitely means that if we put a feature on the (then hopefully pretty short) list of features for a version, that we need a reliable, dedicated developer who is going to bring that feature to an end, unless someone else does it first, and that developer will not work on other features that are not on the list unless his promised feature is ready to go.
In no case should we get into the situation again, that we promise a major feature, especially one that gets a lot of attention, and then don't deliver it.
Release Team:
The Release Team was partially a good idea, the actual implementation however was a big f**k up. First of all, you can't work as a Release Team if none of the members of that team are part of the Leadership Team. We had several times the problem that the Release Team decided in one way, announced that and half a day later was overruled by the Leadership Team. Or there were decisions made in the Leadership Team that involved the release and nobody heard the Release Team. Communicating those decisions from LT to RT didn't really go that well either...
Second of all, there is the problem of the members of the Release Team. I'm speaking only for my own person here, but in hindsight I was the wrong person in that position. I am a developer and I hope that I'm a good developer, but I'm a lousy community guy. I'm not good in motivating people, keeping in touch with them and all that stuff that a release team/manager should actually be doing.
I think that we desperately need someone that fills a role that would normally be described as a release manager and that that person should (with the help of a small group of people) manage the next release. That person however should not even be allowed to write a single line of code. That person should only be there to get people to do their promised work and to keep us on track with the development. On the other hand, decisions made by that release manager have to be final. That release manager also needs to be part of the Production Leadership Team to remove the communication issues that we had and have in the current release.
But who should do this? To be honest and without trying to insult someone, but I don't think that anybody from our current PLT is fit to do the job. I also don't know anybody that would fit into that position.
Accountability:
Although it might have been obvious from my text so far, I wanted to bring this up again in a separate paragraph: The main issue is the accountability.
Who is really responsible for something? Would you know who is actually the one to blame that Andy Miller didn't get the heads up concerning the template stuff? Or who is responsible for comments not going in?
I'd say that even for those involved in the development its not that obvious who did what or is responsible and I'd even say that no one in the PLT actually knows who is responsible or more importantly takes responsibility for something.
The issue involved in that is, that you get situations where even for major features you have person A saying "Oh, person B is responsible for that." the next one is saying "it's person C" and person C is pointing back at A and then you say "Could you three please get that straight", you wait a few days and then forget about it and in the end it is not done. Clear responsibility and accountability is extremely important in this.
Conclusion:
I don't think that we should start development of a future version of Joomla without having solved these issues beforehand, because otherwise it will fail similar to 1.5 and 1.6.
I personally don't see a lot of people switching to 1.6 very soon. The gain for the enduser is minimal and especially the developers will need quite some time to adapt. Maybe it is better to go directly for 1.7...
In general we don't have such big problems in the actual development work and I think we also have quite a lot of skilled and motivated developers available to do it, but we have huge, project crushing issues in the management area.
This brings me to my last conclusion:
We should not only think about 1.7, but also 1.8. For example, I could envision 1.7 to be about a new search, a new media manager, comments and some more clean up work and a few smaller improvements to the framework. Then in 1.8, we could have a com_content replacement with tagging and multi-category capabilities as well as versioning and maybe a solution for multi-lingual websites.
The mentioned features for 1.7 could very well be done in 6 months, while I think we will need a year or even longer for the features that I mentioned for 1.8. So we should start thinking about and also actually start coding those features for 1.8, long before 1.7 is released.
The question is:
What will the PLT do? Will they change or are they and thus the project stuck to the "old way"?
This has been a guest blog post by Hannes Papenberg. He joined the Joomla! project in early September 2005 and the participated in the Google Summer of Code project in 2006 before joining the Joomla! Development Working Group and Release Team
