Stephenson: hackweek9: Lightweight KDE Desktop project

You create a graphical mail application. Of course you need Calendaring, too. And contact management. And Todo. So, you develop these 4 applications. Maybe someone helps out, trows in a feed reader or such. You happily add features where needed but not too much, you want to keep it slim, hey!

Of course, you need to have access to the contacts in the mail application. The mail app can directly read the contacts that the contacts app has access to, too but to avoid clashes with the contact mini-app you use DBus so they talk to each other. And you want to be able to have the contacts in the Calendar so you have appointments with people. Again, IPC to the rescue. You build on and people ask if you can show the online status in chat in the mail app - so you don't have to mail them but talk to them by mail. That makes sense. Now performance becomes a bit of an issue, so you cache the contacts in the mail app, the calendar app and well, you need todo access in the calendar app so you cache the todo's there too. Oh and todo also needs to access contacts. But let's be clear: you're not doing anything weird, this stuff needs to be simple, understandable (for the newcomers) but also scale - that's why you need cache and some database stuff. After all, with today's email load of 6-8 GB of mail and hundreds of contacts, it has to have some serious performance.

By now, you have everything 3-4 times in memory and in 3-4 different databases and caches. So, as a good programmer, you decide to re-engineer this: you need a common storage for this data. That will allow you to do the same thing but a lot better.

So, you make a great plan, a proper new architecture and you get to work. Unfortunately, you depend on a group of volunteers. This work is difficult so only the most 'core' members can do it, and time moves on - people get busy with other things so you lose people. Meanwhile you have to maintain the old applications too, as the new architecture is still far from ready. So you device a way to slowly migrate things over, and hope people can either bite through the birthing pains or come and help you out. But they don't, they don't get why this was needed, claim that Claws does mail just fine, and you get little help. Meanwhile, you've missed every possible deadline, it is 2013, your mail client (now just a for-two-years neglected GUI) is getting old and has issues of its own and everybody yells at you that you suck for even TRYING to fix the architecture behind their apps.

Somehow, you ended up with Akonadi. sjees. And I hope you will have learned that, surprise, doping PIM properly is HARD. That's why KMail/Akonadi/KDEPIM has issues: they are trying to build a PROPERLY engineered solution which actually WORKS for what people in 2013 want to do and that is not easy. It requires a solution which is complicated, so it needs a lot of testing, bugfixing, looking for corner cases. And with just a handful of volunteers, that is not easy to do.

There are surely some 'basic' use cases out there where you can use an app here and an app there. It will work for you. Might need the occasional sacrificial chicken and handwaving and it won't work that great with your company infrastructure, but hey, it works for you.

If you want calendaring, contacts, todo and all that scale-able and with multiple accounts and identities and grouping and proper security and performance - say, the stuff a modern company will need for its 2000 employees, KDE PIM is the only game in town. Or, of course, Microsoft Outlook. Groupwise, maybe.

That is why Kolab, which has as its mission to finally fix the final pillar of Free Software on the Corporate Desktop (PIM), is now working on KDEPIM. They are testing and stabilizing it as their customers will need it. So a year or two from now, it'll be quite good for what you want to do. Until then, help is welcome. And Boudewijn's attitude is far better for getting it finally done than yours - uninformed ranting never got far.

Have a nice day.