The KDEPIM / Akonadi situation

[Martin Steigerwald]

Hi!

Another community goal aside from fixing up the chat software situation 
within KDE could be to either fix Akonadi or replace it by something that 
works…

Plasma and KDE Frameworks got a huge ton better in the last releases. 
But other parts of the KDE ecosystem appear to be mostly abandoned – 
like Kopete or KDE Telepathy – or in case they receive continuous 
development like with KDEPIM/Akonadi that continuous development does 
not seem to have achieved a stable, reliable and well performing 
solution for users in the recent years. Quite the contrary, with KDEPIM 
/ Akonadi 20.04 it got worse.

Just look at kdepim-users mailing list, on bugs.kde.org or on the 
internet. Since years many users are quite unhappy with the situation. 
Quite some abandoned KDEPIM after a lot of frustration with it. And I 
considered myself to abandon it way more than once as well, currently 
considering to switch to something else again.

I was putting up with all the deficiencies, but recently it became quite 
unbearable for me as well as the situation for local maildir resources 
worsened considerably – Debian unstable / testing users are hit by this 
currently, I wonder why it wasn't reported before:

Frustrating to use KMail with Akonadi 5.14.1 (20.04)

https://mail.kde.org/pipermail/kdepim-users/2020-June/013315.html


Thing is, while this regression is new, unreliability and performance 
issues regarding Akonadi are *known* for years. And capable developers 
spent a lot of effort to fix them. Yet… it still does not work.

Some people even started over with the Kube project, but while the 
architecture of Sink that powers it appears to be more efficient and lean, 
Kube and Sink only provides a limited subset of the functionality users 
of KDEPIM use so far.


The pity in there is: KMail and other KDEPIM applications are actually 
quite good. But especially KMail suffers a lot cause it waits for Akonadi 
to complete a request more often than not. It is a "wait for Akonadi 
game".

The bug reports that describe why this is the case are open since years. 
I mentioned some of them in above post.


I really mean no accusation here for anybody. I know KDEPIM and Akonadi 
developers are working hard. They are doing their best, I am sure of 
that.

But while the situation intermittently improved some, it is still not 
really good. Also requiring users to be database administrators to make 
things work again in case of trouble… is simply a no go to me.


Currently I have no idea how to fix the situation. I lack the C++ skills 
for it and while I can learn C++, in the situations I tried to 
understand how Akonadi works and where I find what in the code… where I 
would even start looking about fixing a certain issues… I failed. I know 
some of how it works, but I never brought it all together. I may be able 
to learn all of this, but given that even seasoned KDEPIM developers 
have not been able to really stabilize Akonadi… I feel that the bar is 
quite high.

The bugs that cause the trouble are all reported on bugs.kde.org – many 
for years already. Again no offense meant. The KDEPIM developers do what 
they can.

At the same time more and more new cool features are developed for 
Akonadi and KDEPIM like KDE Itinerary or Etesync this. But the 
foundation still is not as solid as it would need to be for users to 
have a more pleasant experience with it than many users currently have.

It works for some, sure… but just look at the mailing list, the bug 
tracker and on the internet… many users struggle with it. Including 
myself… and I defended Akonadi before quite a bit before, despite all 
the trouble I had with it. I am not defending it now. It is still not 
working reliably, it still does not perform well for a considerable 
amount of users.


Anyone having any idea how to improve this situation?

Could it help to make fixing this up one of the next community goals? I 
know it is some time till the current 3-year period for goal achievement 
is completed.

What else could help?

Best,
-- 
Martin