KMail is one of the most important applications inside KDE, I think hardly can argue anybody about it. Everybody is using email, and even if some think that a webmail solution can be just as good, most of us still do what we did 10-15 years ago: download mail to our computer/phone/tablet and carry that around.
And for that we need a mail application.
It is not news that KMail got just too big and not flexible enough in the KDE 3.x days. Somehow it was ported to KDE 4, but this was a crude port, without much improvements in its design. A new generic PIM backend was growing up meantime, and with some corporate support from KDAB, a new generation of KMail, KOrganizer and other PIM application started to take shape.
From those I can tell about KMail, as I was more involved into it. As we wanted to have a mobile, touchscreen version as well, the work of porting KMail to Akonadi was done together with breaking KMail into smaller pieces, more or less standalone libraries to reuse as much code as possible. Time, manpower and other reasons limited what we could do, so this was a part success. We created and improves some generic usage libraries (KIMAP, KMime), some internal libraries that are nice, some that are not that nice, and in the end we had something that could have been a good foundation for KMail 2 series.
I started to use KMail2 at that time, and in the beginning it was a fustrating experience. I can't count how many times I deleted and created again the accounts, the Akonadi database. But after a while I realized that I don't have to do anymore. KMail2 was still not released to the public, but got better and better. Unfortunately only slowly, as even less people worked on it, and only in their free time. It had bugs, some more annoying, some less annoying, but was usable enough to not force me to go back to KMail1.
Then the PIM community took a deep breath - just like the KDE community did with KDE 4.0 - and finally released KMail2 officially.
Funny or not, around this time I started to have problems with it. A migration of my second computer failed horribly. A cleanup of the Akonadi database and changing from the mixed maildir to maildir format was also painful. I blamed the developers a lot (including myself :) ). Then things started to move on and KMail got a new maintainer, who is very active (hi Laurent!). And we organized a developer sprint to stabilize KMail.
The sprint took place last weekend in KDAB's Berlin office and was sponsored by the company. Everybody who knows the KDAB office, knows about the famous foosball table. Do I have to said that in the weekend we played only once? Yes, people were coding intensively, Volker had to raise the priority of the "FOOD" topic often.
Issues were listed on the whiteboard. And everybody picked up what he was interested to do. Work was done on the migrator, the mixed maildir agent, the maildir resource, on the akonadi server, performance bottlenecks were identified and a new filtering resource was created, fixing the most hated KDE bug (should be closed as soon as Tobias Koenig is happy with his work).
My choice in the sprint was mostly maildir related work, I tried to make it more reliable, more standard compliant and somewhat faster than before. And the biggest win is that I fixed most issues that bothered me with KMail's maildir handling. Yes, I was selfish.
The sprint did not end in Berlin, for me it continued on the flight back home (that thanks to the weather and Lufthansa was almost a day longer than expected). And somewhat still continues as of now, although daily work reduces the time I can allocate to KDE.
I can say that I'm happy again with KMail and Akonadi starts to gets less and less in the way of me and the users. The biggest success will be when users will not know that there is a nice server helping them, called Akonadi.
For those eager to try out the changes, unfortunately most of them are in the master branch only (the upcoming KDE 4.8). We will try to port as much as possible into the KDE 4.7 bugfix releases, but as some changes required library additions, this won't be always possible.