Answer about “Akonadi for e-mail needs to die” blog

Yesterday morning I read planetkde.org as usual before to hack on kdepim and I saw this blog.

I thought that it was a constructive blog, but not!

(As all your articles on your blog about kdepim. I don’t understand why you are not able to switch to another mailer before.)
Mr “Andreas K. Hüttel” is just an user which was frustrated by a bug about his IMAP server.

I can confirm that KMail is not free bug, Akonadi is not perfect too. We work a lot each days to fix the bugs. You can make the same blog about each application which doesn’t work as you want. You can criticize all these programs and wrote that developers lose their time to work on. I hope that you wrote some blog as it for Kernel Linux, Xorg, LibreOffice etc. for sure they are not perfect too.

KDEPIM team is small but I think that we make a good work. Perhaps you should read kde-commit to see all fixes that we did…

But Mr “Andreas K. Hüttel” I can tell you:

  • Nobody forced you to use KMail ! We are in open-source world, you are not happy by an application you can use another one!
  • I didn’t see a patch from you about KMail to try to fix it. So how can you told us that it was an error to migrate to Akonadi (just because it doesn’t work for you?). Did you study on which technology it’s based ?
  • When you wrote ” What is dead should better remain dead, and not suffer continuous revival efforts while users run away and the brand is damaged.” Who are you to tell us to stop to develop  KMail based on Akonadi ?
  • “Also, I’m a volunteer myself and invest a lot of time and effort into Linux. I’ve been seeing the resulting fallout. It likely scared off other prospective help.” Ok so I will wait to see your work about the fork of kdepim based on qt4. I am sure that you will able to make better than us (poor kdepim team). You know you can port it to qt5 and we will see if you will be able to fix all bugs not just your bugs. I hope that you will able to reproduce all of them.

Now Mr “Andreas K. Hüttel” with a blog as it you will discourage for sure some new user/developer, but also people  which helps us, they will think that they’re wasting their time. It’s unacceptable. 

Mr “Andreas K. Hüttel” you just have NOT ANY respect for all work done by the KDEPIM team, by the doc team, by the i18n team, by all user support guys, by the users which reported bugs.

Mr “Andreas K. Hüttel” if a day you are able to work on a project you will see that it’s not possible to reproduce all bugs because we don’t have all the time, we don’t have the same environment. Fixing a bug take time when we can’t reproduce when it’s a corner case. Some time we don’t have the good technology as a specific server IMAP etc. But perhaps it’s too hard for you to understand it.

Ok Mr “Andreas K. Hüttel” it’s sad that we were not able to fix your bug, but it’s more sad that you think that all kdepim team work is a lost of time.

As I wrote who are you to tell us that it’s a lost of time ?

Do you provide a technical solution ? NO

So for your information we will not stop to develop KMail because you think it’s a lost of time. We will continue, I will continue because I know that a lot of people uses it and they are happy with KMail based on Akonadi. I will continue to “lose my time” each day as I respect users which use KMail, it’s not your case.

I want to thank all people which participate, all guys was participating  to KMail improvement. We make KMail better for sure. Thanks guys. Thanks Doc Team, Thanks I18n Team, Thanks User Team Support, Thanks happy users, Thanks not happy users which understand our work.

To conclude we are in open-source you are not happy you can use another application, all developer is  able to choice on which technology he wants to develop, but it’s really unacceptable as you reduce kdepim team work (and other teams) to a lost of time because you are just a frustrated person.

Leave a comment ?

71 Comments.

  1. Once KDE software is mature, it’s really good. Currently KDE5 is still having bugs cleared and design cemented in. Kmail for me works fairly good. At rare times it can fail but usually fixes after a restart of the akonadi server or system. Knotes has been a little more temperamental due to vast rewrites/changes and still is far from proper.

  2. Being frustrated over a single bug or not, that blog again sheds light on the practice “release early” is really bad for PIM-related applications.

    I don’t care when KMines has a bug and I can’t finish the game (I didn’t run into it). But when KMail converts BCCs to CCs that’s frustrating (I did run into it).

    I also don’t like the idea of making habit of rewriting everything instead of continuous development (KMail vs. Trojita, Kube). However, I accept that when you say this is the way to go, I just feel sad that the scarce developer resources are further forged.

  3. Fragmented of course, I’d like to say.

  4. I fully agree. Sadly this shortsighted mentality of him seems to become more and more omnipresent in these times where choice of software is abundant. Clearly his mind needs to develop the ability for respect and as a software developer in the open source community I am ashamed of that immature and non constructive ‘contribution’ being posted on Planet KDE. I can understand users who have not the ability to analyze bugs by themselves, who have to rely on the developer team of the software they use which as it happens in this case is rather small and become frustrated because they have not the ability to help themselves. But as a software developer you should at least investigate further which is especially the case for software you use yourself if some bug prevents you from using it and not turn your back on it and go away.

    I truly hope that insight will eventually set in and some kind of apology will follow from him which I would expect in case he did not really mean what he wrote and knows better than that.

  5. Thanks for your work guys.
    I did not uderstand the anger of this man about kamail- akonadi.
    It works fine in my computer and am really happy with all improvements of kmail.
    You have all support of people who enjoy your work.
    Thanks again.

  6. Dear Laurent Montel, thank you for all your efforts aimed at improving KDEPIM. It is certainly getting better and better!

    The reasoning provided by Andreas K.H. is based on the conditional: “something should not exist if I’m not able to use it”. The fearsome consequences of this premise are obvious enough to make a strong opposition against it.

  7. I just want to say thank you for your hard work. I rely upon kmail since one year or so (after I migrated to Plasma 5) and for me it worked very well, except some minor bugs, which were a problem of the distributors. Hopefully the akonadi-ews ressource will mature a bit and find its way into the distributions. Then I can stop using Outlook at work 😛

    Keep up the good work!

  8. The main issue here is that Akonadi is TOTALLY UNFIXABLE with it’s crashes deadlocks and shit. Face it. Broken by design as it was said in the post you are answering to. It’s just not the right way to do it.

    • So we wait your solution. We wait your patchs thanks a lot 🙂

    • What exactly is unfixable? Such nebulous accusations are stupid. I think you don’t even know how akonadi works. Have you looked into the source code? When you run into a problem, then file a bug report for that specific problem. I don’t get your offensive statement.

      • >Have you looked into the source code?
        Sure.

        >When you run into a problem, then file a bug report for that specific problem.
        I did.

        Believe me or not it does not help. It won’t be helped. Design flaws are design flaws.

        • what are the design flaws?

          • It’s my turn to ask. What exactly was broken now that we need the Akonadi to fix it?

          • It is used since KDE 4 times. And the main reason for developing akonadi was that many applications needed the same basic pim functionality and every application needed to implement this functionality for themselves every time. So they developed akonadi to provide this functionality for these applications, so that not every program need to implement it by themselves. Akonadi serves as a interface.

          • @blaze: Akonadi is ONE point of account access and settings for the whole desktop and all its applications. This is much better than using the same account for each application/plasmoid.

            And YES, I like it to search my contacts through Krunner, or to view my daily appointments via a desktop plasmoid without starting KMail. Because I want to use a modern desktop.

          • @smurfy:

            that worked before Akonadi, too. As long as you were using KDE PIM, it just used the libraries to access that data. And it would only make sense if non-KDEPIM would also work with akonadi, because otherwise you are at the same point as you were before the akonadi variants.

            As a minor sidenote: it’s actually some plasmoids (e.g. calendar) that currently no longer work due to the migration, the bug has been open for ages and now finally will be fixed in Plasma 5.7 and KDEPIM 16.08

          • Concept behind Akonadi is sound but it’s badly executed.
            Akonadi cache – you know, something that is usually kept hot (in memory), perhaps only to be serialized to disk occasionally – is designed around SQL relational database.
            Akonadi does not keep any confuguration data there – just PIM cache.
            Because of this, it’s slow, complex and resource hungry. Does that sound like technical argument to you.
            We (various distro developers, Andreas H. Kuettel is one of us) were criticizing the idea from the very behinnig. KDEPIM devs ignored common sense and were pushing SQL servers to desktop environment along with Nepomuk people in KDE4 timeframe. Nepomuk people came to their senses eventually, KDEPIM poeple haven’t.
            I have great respect for Laurent for doing great work with KDEPIM over the years. i just don’t get why he personally felt so defensive. Perhaps he went a bit too trigger happy and how he’s regretting it a bit.

          • @Christian: How was this possible before Akonadi without starting KMail every time?

          • @smurfy: Because the information is there. Before the akonadi nonsense, Kmail used mbox/maildir/imap, the calendars used ics files and contacts used vcard/others files.

            This is _still true_ with Akonadi. For email it’s just a metadata storage that provides searches and other stuff. For contacts it basically merges vcard files.

            So in the end, Akonadi is just an unnecessary resource-hog additional layer that forces you into using a full relational DB server for not reason at all.

  9. Respect? Personally, my respect for KDEPIM team can only be expressed as a negative value at the moment.

    • Is it the same for all the other KDE contributors who work in activities related to PIM, including translation and documentation?

    • You seem to lack the ability to perceive the value of what is give to you for free and all the effort spent to achieve it by contributors and the team in the past. You do not really make it clear what your respect should mean in this perspective.

  10. The blog post wasn’t nice nor respectful. But I can understand where it comes from. We would like to use KMail, but are unable to.
    That does not diminishes your fantastic work on the codebase and time you devote to it!

  11. While I understand your frustration after seeing a blog post like the one of dilfridge, your answer is in my option quite shameful.

    Let’s start with the general tone: you say that he has / shows no respect, but you not only always put his name in hyphens and ridicule it (whilst he explicitly didn’t do any name calling and removed comments doing so), but you also assume that he does not work on any projects and does not provide technical solutions. Both are wrong, as he is an official downstream packager who provides his users a technical solution to the problem.

    Then to the reaction: It’s something I’ve seen a lot recently around KDE projects: when someone dares to criticize things based on personal experience, that person is not taken serious at best, ridiculed, criticized or even threatened at worst. Is that really the image you want to have in public? That the best KDE can do to “bad press” is among of ridiculing, threatening to stop or even delete (!) work done (not in this answer here), name calling and saying “no, everything is not as bad, you are wrong”.
    Have a look at IRC, have a look at the bugtracker, have a look at distribution packaging lists. So many users leaving, so many distributions still providing old version of KDE PIM because the new ones are not in a state they would like to hand out to their users. I don’t think that closing ones eyes or reacting in this way is going to make anything better.

    Of course it hurts to see criticism on a project one works on in the spare time, especially from people who did not contribute to that specific project. However, this kind of public reply looks highly unprofessional and certainly makes KDEPIM look less favorable in professional environments than it already is, so I recommend to maybe get in touch with the user in private and see what can be fixed instead of a public mudslinging on that level.

    • Just a remark from openSUSE to kdepim5: https://lists.opensuse.org/opensuse-factory/2016-01/msg00288.html

      At least they had no problems with it. Tumbleweed ships kdepim5 since January, I think. So, I think, it is rather a problem of the distributions, than of kdepim devs.

      And where did you get the rumour, that many people are leaving? Where are the sources?

      • tumbleweed is, as the name even suggests, the rolling repo. I wouldn’t see that as what distributions count as stable.

        I named the sources, I recommend that you just read the post again. Of course you can, as well, just close your eyes to it (and also ignore the various comments on both blog posts that go in that direction)

        • The point is, that it is working on Tumbleweed. You mentioned IRC, bugtracker etc. You could also mention the internet itself as source. Some unsatisfied users, who are always the load group in such discussions, are not an indicator for how many people are using the software, or how many people migrated to other software. Personal opinion is no general rule or benchmark.

  12. I’m happily using, without problems, kmail2 with 6 imap accounts from 5 different mail providers. I feel kmail2 more stable than kmail1. So kudos to PIM team

    • Here there are 4 different email providers and 7 accounts. Kmail2 is by far the best app for email that I have found (including t-bird, claws, alpine, evolution, geary). Happy user for a long, long time.

      Akonadi just runs with no problems. Don’t even notice it.

      If you don’t like the application, don’t use it. The Hüttel post serves no purpose, except perhaps for some-apparently-angry person to have an audience.

      Thank you KDEPIM team. Great product and obvious good work.

  13. What is this post really? Is this really how you should respond? With even more rage? I’m afraid you seem even more frustrated than that person.

    He talking like that was sure bad, but it doesn’t mean you can give an answer like that from the behalf of a free software team, please be more calm and respectful, and a bit more mature by stoping all those DIY and you’re not forced to use comments, if you choose to develope a piece of software, it brings responsibility to you, no matter your software is free or not, please don’t ruin people’s view on free software by such posts.

    And please don’t take it personally, I’m just someone who happens to skim through both posts.

  14. I’m running kcontact5 with akonadi-server5. I would say I’m a power user. I have a huge load of mails over different accounts. The current release is far from stable.

    The problem is that it is really hard to debug akonadi. I never found a good guide. From time to time I try to reach someone in #akonadi for a debug session but most of the time there is nobody who can help.

    Akonadi runs into a deadlock every few days and the only way to fix it is to clear the cache as nobody can help me debugging it.

    I’m willing to help but don’t expect that I will read thousands of loc to fix this mess myself. Start providing better guides how to provide logs so you can understand and fix the issue.

    • I was in charge of an enterprise installation and consider that also a power user case, and unfortunately I have to agree. Mails going missing, reproducible crashes on replying to E-Mails (yes, reported), status of mails going missing, synchronization of contacts and calendars being partially broken with a report open for more than a year, it’s quite a long list.

      So yes, for enterprise use we deemed akonadi/PIM not suitable at all.

    • There are a few indications in the community.kde.org and userbase.kde.org wikis, in particular some environment variables you can check for example to debug IMAP issues.

  15. You mean someone was wrong on the Internet by having a different opinion that you ? How can it be !

  16. You can’t ask for respect as a team when you don’t respect your users by not fixing critical bugs for years. And yes, I migrated from Akonadi to a sane solution arround 5 months after I HAD to use it (because Kubuntu decided to upgrade to alpha-quality KDE4 version)

    While everybody can understand you are a small team mostly working on your free time with little resources, the horrible decision to start using a poorly-designed-full-of-bugs-resource-hogging data system was yours (the kdepim team). So when you receive some criticism like in the referenced post or like you’ve been receiving from plenty of your annoyed users since Akonadi was forced into them, maybe there’s really a problem that is making people stop using kdepim or even kde altogether.

  17. Andreas’ blog reflects the frustration of a lot of users that cannot get THE kde mail client to work because it requires lots of work to get work properly – the smoothness factor of getting set up properly is very low. It should just work – but many times it doesn’t.
    My guess is that the complexity of creating Akonadi has resulted in not creating easy feedback/debug mechanisms when things don’t work. When it’s combined with the slowness of getting latest KDE packages to the users you get a dead-slow feedback loop.

  18. Mr Laurent,
    I use Kmail and Akregator daily and extensively. I do find few bugs (To-dos vanished twice in Korganizer), but KNotes have improved greatly. I miss KJots – Basket is not also developed now. Otherwise KDEPIM is great. Please keep up your work for users like us. My best wishes. Good luck!

  19. Partially agreed. I love a load of the technology in akonadi and the backend it provides, and I’ve been roughly six months of using KDE / kmail on my day-to-day working machine. Wrote about it here: http://dm.zimmer428.net/2013/04/kde-kubuntu-and-a-bit-of-rant/

    Basically, I have to indeed thank the kdepim/kmail/akonadi team for the work they do. It’s pretty great from a technical point of view but in my opinion it’s so far not ready for “real” end users. I’m now currently using *cough* evolution on a GNOME box, and though this lacks a bunch of features kmail provides (and some of them dearly are missed), it generally seems much more stable and ready for day-to-day use in most of the relevant aspects. Looking at my history of using KDE and communicating with KDE people, my impression is that, in there, generally a load of end-user questions / requests end up somewhere on a pile of open issues that aren’t that much important while everyone’s busy, say, migrating from KDE4 to KDE5. No blaming or finger-pointing, and (as a developer myself) I know how tough these things are, but from my point of view as an end user, KDE (unfortunately!!!) leaves a load to be desired talking about stability, robustness, ease-of-use.

  20. I’ve had my fair share of issues with KMail/Akonadi as well. The largest issue with this is that it’s really hard to debug (in my opinion), and I eventually gave up in the end because things were not just hard to debug, but hard to reproduce as well.

    I see what is intended with it and I think the direction is right, but the reality is that it isn’t stable (enough) for my production use.

    But hands down, ranting against the project because it does not fit your needs? It didn’t fit my stability requirements either, and due to me obviously being unable to debug it, I switched to another solution.

    That said, I’m not angry because of that on the Akonadi/PIM Team, the good part about it is: OSS gives me the opportunity to use something else. They’re trying to provide us with a great solution (which is very complex), and with time the project may be stable enough to fit my personal needs. Or maybe my future solution will be Sink/Kube, or maybe it will be something else.

  21. Really sad to see a response like this, more so because I know you’ve worked really hard for years with KDE and the PIM. This kind of response and infighting is what causes people to leave a community, and only reinforces the opinion that both the developer and general Linux community as a whole are toxic, unfriendly and aggressive.

    We need to be realistic on both fronts. Yes your resources are limited, you have a handful of developers vs hundreds in Microsoft for example. Yes there are bugs, in the past some of which have been so bad to cause non-recoverable data loss on an IMAP server (remember Alan’s posts?). How do you move past this in an open-source world? With grace and honestly, without immediately attacking any opinion that doesn’t reflect well on the software, because this isn’t about you, or any other developer, it’s about the software. One of the first rules of development is never to take things personally.

    So.. how can we move forward, because posts like this do not make we want to be around the Linux world despite it being our future.

  22. Ernesto Manríquez

    The best part of KDE is Akonadi, full stop. When you get used to get reliable mail updates with full text searching, fast mail searching directly from your desktop without having to open your mail client, your calendar events and contacts in your desktop, and all of that running under 1.0 GB of RAM and with an acceptable speed in a netbook, you simply get used to that, and can’t leave it.

    However, that’s also the reason why I’m still skipping Plasma. All the capabilities mentioned there aren’t fully there in Plasma 5.6. If Plasma 5.7 carries over all those beautiful Plasmoids I enjoyed in KDE 4.x, can max out the speed, and also can enable the akonadi-exchange resource (bringing full Outlook.com support, among other things, that’s a BIG one), then I’ll be there in 5.7.

  23. Ernesto Manríquez

    The best part of KDE is Akonadi, full stop. When you get used to get reliable mail updates with full text searching, fast mail searching directly from your desktop without having to open your mail client, your calendar events and contacts in your desktop, and all of that running under 1.0 GB of RAM and with an acceptable speed in a netbook, you simply get used to that, and can’t leave it.
    However, that’s also the reason why I’m still skipping Plasma. All the capabilities mentioned here aren’t fully there in Plasma 5.6. If Plasma 5.7 carries over all those beautiful Plasmoids I enjoyed in KDE 4.x, can max out the speed, and also can enable the akonadi-exchange resource (bringing full Outlook.com support, among other things, that’s a BIG one), then I’ll be there in 5.7.

  24. KMAIL and Akonadi have been great for me for years. There have been cases when I’ve needed to restart Akonadi with ‘akonadictl restart’, but that happens every few months.

    I love Akonadi and how it integrates across KDE, its one of its best features. I believe, however, that the releases need to be more carefully coordinated amongst all the different libraries. But the question comes down to is who’s responsible for this? The KDE Teams or the Distribution Team?

    Mark Shuttleworth made a good point about OpenStack a few weeks ago about Leadership in the project. Just like how Linus is leading the Kernel, Shuttleworth is leading Canonical, I think perhaps KDE needs this type of character as well.

    I love KDE, its been my main Desktop since 2000. I’ve loved watching it innovate and mature and can’t wait to see how it continues to unfold! Hopefully we can get a coordinated working model for all distributions to follow.

    Great Job to the whole KDE Team!

  25. I always get a chuckle and think to myself anytime a dev says “well I’ve not see a patch from you” or similar statements what a poor attitude. It isn’t like kmail2 hasn’t been known to be buggy especially in certain areas, for years.

    Here’s the thing. Saying to me where’s the beef (patch or code) I would first learn how to write code in the qt/kde/frameworks/plasma/this/that/and the other thing and I haven’t even got to the point of looking at the kmail2/adkonadi/whateverelse source code.

    But that’s OK, I will still continue using KDE as I have since its early, early days and religate kmail to the dust bin.

  26. I appreciate the work the various KDE devs put into their pet projects, but wow, I’m apalled by the attitude of this blog post. In my experience, the community is usually great, with nice, helpful devs even when faced with grumpy users venting frustration. But this? No, this was the wrong way to handle it. Bad attitude, “if you don’t like it don’t use it” and “I don’t see you patching it” remarks, a general contempt for someone as a user because they aren’t fixing it themselves, and a general dismissal of criticism because it’s not from a developer. You should be ashamed for ever posting this, it’s like a “best of” for all the criticisms against FOSS communities, all compiled into one blog post.

    To conclude we are in open-source you are not happy you can use another application, all developer is able to choice on which technology he wants to develop, but it’s really unacceptable as you reduce kdepim team work (and other teams) to a lost of time because you are just a frustrated person.

    Unfortunately, I had to do just that — use another application — because Akonadi + Kmail has been nothing but trouble for me. It’s a shame, because it’s been my favourite email client for a very long time, but I finally gave up on it. The idea is great, but the end result has been anything but, thanks to Akonadi. It’s not Kmail’s fault, but it still reflects poorly on it as an application, since it’s the application I use that relies on Akonadi, so it all gets lumped under “crap I deal with just to use kmail”. Not a full list, because I’ve been having trouble for years and I’m just writing this from memory, but some of the problems that come to mind:

    * Akonadi’s internal sql database has never worked correctly for me, forcing me to set up and maintain a separate mysql database just for it.

    * Akonadi for me uses something like 350MB of RAM. Not counting the external database I had to set up, or Kmail itself. You could argue that it isn’t that much on modern systems, but “I use as much RAM to use kmail as I do to use my browser” isn’t a flattering comparison, and I have better uses of that memory.

    * Neither Akonadi nor the sql database are shut down when I close kmail, even though nothing else I use requires it. So I have to stop both manually to free resources.

    * Attempts to migrate the Akonadi database have been a nightmare. I tried going back to the internal db again but it still didn’t work, so I decided to try the sqlite backend. That mostly worked, but migration from one database to another seems to not be possible. It looks like it switches over successfully but Kmail completely breaks until the database is switched back.

    * Ever since Akonadi became a Kmail dependency, I’ve had problems with IMAP server disconnects and constant repeated prompts for wallet password to login again. Closing kmail to stop this is the reasonable expectation, but of course it doesn’t work because Akonadi tries to keep those connections for as long as it’s active. Again, Akonadi problem but it hurts the impression of Kmail itself.

    * Not kmail-related, but the calendar reminder daemon also uses Akonadi for birthday/anniversary notifications and completely breaks at random. It just starts displaying reminds for every birthday in the database, every five minutes, and never stops. The only fix is to wipe the akonadi birthday store, create a new one, and add all the birthdays back to the new one. Which works for a few months and then it happens again. This eventually frustrated me enough that I stopped using it completely.

    There’s more, but it doesn’t matter; these alone were frustrating enough that I gave up and phased out all apps that rely on Akonadi for anything. Kopete? Gone. Kmail? Gone. KOrganizer + its reminder dameon? Gone. I even renamed the binary so nothing can run it without my knowing. If I need it for some reason — I still use Kmail occasionally, but rarely — I start akonadi manually and then close it after I’m done.

    I appreciate that you’re doing what you think is best, trying to create the software you want to use, but that doesn’t guarantee anyone else will find the end result usable. In my case, I’ve had to stop using applications that I otherwise like very much because Akonadi became too much of a burden, finally outweighing the benefits of those applications. I dealt with the problems for years thinking it was just a rough time and things would improve, but they never did. I finally ran out of patience, and had to give up on some otherwise great applications as a result. 🙁

    • ” I even renamed the binary so nothing can run it without my knowing.”
      Oh this is a very good idea. I still fire it up by mistake occasionally, frequently when inadvertently clicking the korganizer widget in the systray instead, this could be a great cure. Thanks!

    • Ernesto Manríquez

      BTW, you reminded me about the KOrganizer reminder daemon.

      Can you kill it with fire? Akonadi should have (AFAIK, it does have) the ability to trigger reminders and channel them through the notification system.

  27. These arguments (especially the comments) tend to revolve around technical issues because most of the planet bloggers and readers are nerds, but the whole drama is actually about a social issue. Look at how Andreas Hüttel starts his blog entry: “Akonadi for e-mail needs to die!” Why does it need to “die”? Why choose the most aggressive and disrespectful expression? It may be a valid opinion that something else should replace Akonadi IMAP, but surely it doesn’t need to be killed first!? His tone made the Akonadi developers immediately defensive, and it was likely the discussion would go downhill quickly. And it did, with Laurent’s rage-filled reply. It is difficult to see the discussion progressing in any meaningful way from now on.

    With a little more respect between people, maybe public discussion of sensitive issues could be possible in KDE. Sadly, this opportunity seems to be lost in the case of Akonadi. I wish people would understand that it’s not just about technical aspects.

    The technical discussion tends to go in circles because it’s actually hard to quantify whether a piece of software is “buggy”, as there is usually no statistics on how large proportion of users is affected by serious bugs. All we have is anecdotes: one user complains about continuous issues, another claims it works like a charm. For me, KMail has an annoying habit of sometimes taking forever to fetch mails from my server, but I’ve no idea how common this issue is. But in any case, the technical discussion is futile if people fail to respect each other.

  28. Never worked for me, Kill it or make Akonadi an option please 🙁

    • Always worked for me. You should take the time to properly configure it. Alternatively if you are not skilled enough and cannot find somebody who is able to help you, you can look for other options.

      • Do you realize that if a program is so complicated that people could be “not skilled enough to properly configure it”, it is probably not ready for release?

        We are not talking about an IDE or any kind of technical program that only highly-skilled developers will be using, we’re talking about a mail client. The competition, be it FOSS or proprietary, has had one-click, hassle-free configuration for years now.

        Just look at Marand’s post above… Why would a mail client require a user to install and maintain a SQL database as part of the configuration?

        And sure, we can always use other options. But feedback is what feeds progress. The post which triggered the present blog post, and half of the comments here, are feedback that akonadi has been driving users away from kmail for 5 years.

        The *only* response I could read to this feedback, in the blog post and the other comments, including yours, is “noone is forcing you to use our software”.
        Besides it being a pretty useless thing to say to someone who already abandoned your software, I do not feel that it is an appropriate response to this kind of feedback. You should not take your users for granted.

        • I agree with most statements in a more specialized form:

          Ready for release:
          – commercial software: yes, no question, do not ever release it in such a state that would hurt business
          – foss: work in progress/rolling release projects, community driven, mostly not financially backed, resources are more limited. If kmail would be complicated, it could be something to think about before release but is it actually that complicated? I found it no more difficult to configure than thunderbird.

          One-click: kmail menu tools->account wizard. Although I cannot say much about to which extent it can be compared to other software’s one-click solutions but it is there at least.

          Manual mysql database:
          It is not necessary to manually install the mysql database and it is not supposed to be shut down. It is a storage backend. Just let it run since it is required for other tasks beyond kmail.

          Feedback: Always welcome, just not in the form of hostile, arrogant or insulting manner- Be civil, polite and respectful.

          Software use: correct. Just do not perceive the advice to use other software as something negative. It is the freedom of choice. There is not a drive or urge like with commercial software that strives for users.

          I know too well that people without technical background, knowledge, software development skills or expertise cannot achieve much without help in certain situations.

          Besides all this, I would like to know what exactly the problems with akonadi are in general (no specific problems) to have a look at it, to see if it can be helped or not. Is it a design issue, architectual issue, usability? Some hints to look in the right direction on what can be done.

          • Ready for release:
            – commercial software: yes, no question, do not ever release it in such a state that would hurt business
            – foss: work in progress/rolling release projects, community driven, mostly not financially backed, resources are more limited.

            In my opinion, this separation is artificial and only serves to feed the vision of FOSS as amateurish, unreliable software.

            Some FOSS communities have managed to get rid of this image, and to be viewed as viable competition against commercial software.

            If some project doesn’t have enough manpower or money, it can choose to release less often, or to lower its ambitions in terms of features… But imo what is released should be release-ready, and it includes having enough documentation to troubleshoot common problems. Call it craftsman’s pride, if you will.

            Feedback: Always welcome, just not in the form of hostile, arrogant or insulting manner- Be civil, polite and respectful.
            Please excuse me if my post was not civil, polite or respectful, that was absolutely not my intent. Heated discussions are a waste of energy compared to respectful discussions. 🙂

            And in any case, noone needs reasons or excuses to refuse to be yelled at. 😉

            Software use: correct. Just do not perceive the advice to use other software as something negative. It is the freedom of choice. There is not a drive or urge like with commercial software that strives for users.
            It is definitely a valid answer, and the best answer in some cases (sometimes users insist on using what is genuinely the wrong tool for their needs). But if it is the only answer to any user having a problem with the software, imo there is something wrong. If you don’t develop software for your users, then why?

            I know too well that people without technical background, knowledge, software development skills or expertise cannot achieve much without help in certain situations.
            I understand that. In a perfect world, google would never be needed to find information about a specific problem, but this world is not ours. However, I believe that any piece of software requiring more than some google-fu to get working or troubleshoot (besides specific knowledge related to the program operation, of course) is too complex.

            And I also believe that users visiting a developer blog all have the required google skills. 🙂

            Besides all this, I would like to know what exactly the problems with akonadi are in general (no specific problems) to have a look at it, to see if it can be helped or not. Is it a design issue, architectual issue, usability? Some hints to look in the right direction on what can be done.
            The problems which drove me away were related to “not enough memory” on a netbook and “too frequent disk I/O” on a desktop workstation on a NFS. Both were bringing my device (and the NFS server on one occurrence) to its knees whenever akonadi started.

            Granted, they weren’t technically bugs, and it was also an awful lot of versions ago (and at that time iirc, it wasn’t even clear whether kdepim was still in development).

            But users can only ever describe specific problems (otherwise they tend to be unneededly general, like “the problem is the software, kill it with fire”…).
            Framing a more general underlying problem is a (non-easy) job for the vision team.

          • “Besides all this, I would like to know what exactly the problems with akonadi are in general (no specific problems) to have a look at it, to see if it can be helped or not. Is it a design issue, architectual issue, usability? Some hints to look in the right direction on what can be done.”

            the main problem i see (and what was written in the first blogpost) is: it was an experiment and it turned out to be far too complex. it simply cannot be maintained as the beast it is now and therefore there will always be too many people having problems with it.

            keeping this in mind the original post was more like a: please, stop fiddling around with akonadi, try to think the whole thing again and build something which works better (robust, simple, …) and is way more maintainable.

          • Manual mysql database:
            It is not necessary to manually install the mysql database and it is not supposed to be shut down. It is a storage backend. Just let it run since it is required for other tasks beyond kmail.

            Since this was referring to what I wrote above, I thought I should clarify. I tried to “just let it run” with its own database. It’s not like I decided “Hey, I want to set up and maintain a mysql database today” (I like postgresql :P). It worked fine for a while, seemed to have no problems, and at the time I thought the Akonadi complaints were being overhyped. Then I started up the system one day and akonadi started complaining that its own mysql server process was terminating…

            Tried to solve it, had no luck. So, that left me with the choice of “maintain own sql database” or “give up on akonadi and everything that uses it”. At the time I wasn’t completely sick of dealing with akonadi so, rather than nuking it from orbit, I set up my own mysql database, configured akonadi, and left it like that for …wow, I think it’s been a few years now. Time flies. I did it because I liked the kdepim apps enough to deal with the extra nonsense. I’ve been a heavy Linux user since the 90s, and most of it’s been with KDE, so I didn’t want to just give up on it.

            This wasn’t an isolated incident, either. Over the years I’ve repeatedly had to fire up akonadiconsole and work out problems, remove this or that (the anniversaries/birthdays database has been especially troublesome), etc. I’m stubborn, though, so I kept doing it because I liked the applications using Akonadi even though I hated dealing with Akonadi’s endless stream of problems.

            Anyhow, the point is, the internal “just let it do its own thing” setup ended up broken beyond repair, or I wouldn’t have gone through all the extra BS. This isn’t a developer or admin tool, it’s end-user software that’s supposed to be accessible to the average Joe. If I’d been an average user, I would have given up when Akonadi broke like that, and probably complained loudly abut KDE and/or Linux along the way. I’m not, though, so I didn’t. Not until this insulting blogpost made me decide to speak up.

            As for just leaving Akonadi running, that’d be fine if it didn’t use so much RAM all the time on my system. I don’t know when it started being such a pig, or why, but I noticed I was booting up with ~900MB of RAM in use, which seemed weird, so I checked and it turns out that Akonadi+mysql was the culprit. I boot up to something like 400MB in use now. I have no idea when this started being a problem, but it used to start out much lighter. I could probably troubleshoot some more, maybe wipe out the entire database and reinstall KDE and this or that and it would solve some of the problems, but I hit my limit for it. I finally decided I have better things to do than babysit Akonadi whenever it inevitably screws up again.

            For the people it works fine for, great, I wasn’t trying to convince people to quit using it. I just didn’t like the tone of this blogpost and the “if you don’t like it gtfo” attitude, so I decided to criticise that, and then also explain some of why people get frustrated and say grumpy things about Akonadi and kmail as well. It’s frustrating because KDE is usually better than this. It sets high expectations, IMO, and Akonadi consistently fails to meet them. So people rant about it. But that doesn’t make attacking the person for being critical right.

      • I have been using Linux and KDE from 2000. All my computers run Linux including HTPC with mythtv.
        Every new release, I desperately try to make KDEPIM work as it used to be until Akonadi showed up. Every time I have to go back to Thunderbird to get a useable email setup.

        Just yesterday before posting the comment System Activity showing mysqld taking up 960mb of the memory and not to mention other Akonadi related processes.
        If I click on an email it takes ages to show the actual email, No useable address auto completion, did I mention the constant hanging of Akonadi

      • ” You should take the time to properly configure it. Alternatively if you are not skilled enough and cannot find somebody who is able to help you, you can look for other options.”
        so the necessity that i always have to enter “akonadictl restart” after i lost my wifi-connection is because i’m not skilled enough? or that the search simply isn’t working. or that i delete mails that keep popping up again after something like 30seconds.

        i really like kmail and all the other kdepim software, but most of the akonadifeatures are simply not working. if i have to do a manual restart everytime i want to read mail, then where is a difference to webmail?
        and apart from all the akondadi works/works not: where are the other programs, benefiting from having mails stored centrally?

  29. Personally I liked the idea of Akonadi very much when it first came up. Having a centralized store for all PIM related things sounds great and enables people to focus on implementing a specific protocol (like IMAP, EWS, whatever) and leave the storage and access to a tested and reliable backend.

    Turns out that this isn’t the case all the time. I used the PIM Suite rarely but still encounter several issues with Akonadi hanging and having trouble retrieving mail.
    Still I hope I can contribute to the discussion a bit.

    First of all, the general tone of the reply.
    I didn’t like it, and found it more immature than the original post. Except for the header Andreas at least tried to be respectful. He even honored your work and clearly stated that it was a problem with his *personal* setup. He also noted that KMail/Akonadi works fine for many people.
    Additionally in his previous post, he wrote about exactly the problem he had, and asking for help there. Most of the comments simply told him to move away from KMail.
    So I can understand his frustration, and I admit he maybe got carried away a bit.
    Still asking your *users* to simply move dump your product or fix the bugs themselves is quite ridiculous. I mean it is pure coincidence that he is a developer as well. But is this something you would tell some non IT people who simply want to use your software? If the answer here is yes, please stop *publishing* software, and only code for fun at home. (Also last time I checked, neither the software nor the homepage stated that is is still in development and not ready for production)

    Ok, on to the hopefully a bit more helpful part.
    As I noticed people complaining about Akonadi a couple of years now, I asked myself, why is that the case? Why does it seem like the software doesn’t work as expected for some of the users. As a developer who would investigate such a thing I first start checking the tests written for the software.

    So I checked a couple of the tests, and like to give some hopefully helpful hints on how you could improve here (Disclaimer, I didn’t do any QT coding and have no experience writing tests in the QT or KDE environment)

    As a purely random example, I’d like to take the testModification() test from akonadi-calendar:

    So here we go, some initial setup first:

    QFETCH(Akonadi::Item, item);
    QFETCH(QString, oldSummary);
    QFETCH(QString, newSummary);
    QVERIFY(item.hasPayload());
    Incidence::Ptr originalPayload = Incidence::Ptr(item.payload()->clone());

    item.payload()->setSummary(newSummary);
    mPendingSignals[ModificationSignal] = 1;
    QCOMPARE(mHistory->d->redoCount(), 0);
    QCOMPARE(mHistory->d->undoCount(), 0);

    Then comes the part where the change is sent (I guess)

    const int changeId = mChanger->modifyIncidence(item, originalPayload);
    QVERIFY(changeId > 0);
    mKnownChangeIds << changeId;
    waitForSignals();

    Next it is verified that the change has been made and the history has been updated


    QVERIFY(checkSummary(item, newSummary));
    QCOMPARE(mHistory->d->redoCount(), 0);
    QCOMPARE(mHistory->d->undoCount(), 1);

    Then undo and redo is tested

    mPendingSignals[UndoSignal] = 1;
    mHistory->undo();
    waitForSignals();
    QVERIFY(checkSummary(item, oldSummary));
    QCOMPARE(mHistory->d->redoCount(), 1);
    QCOMPARE(mHistory->d->undoCount(), 0);

    mPendingSignals[RedoSignal] = 1;
    mHistory->redo();
    waitForSignals();
    QVERIFY(checkSummary(item, newSummary));
    QCOMPARE(mHistory->d->redoCount(), 0);
    QCOMPARE(mHistory->d->undoCount(), 1);

    Then there is a test for clearing the history and checking that it is not modified when the history is disabled. I skip that part as the issues I want to pint out can be found in the above snippets.

    So let me explain, why I think this is a bad test:
    * It tests only the summary of a calendar item. I assume a calendar item can have more fields than a summary. They are not tested and may not work with undo/redo
    * It tests only the expected work flow. This is the main point I want to make. No edge cases are tested. What happens if there are zero undo steps and undo is called (because of some UI issue for example)? The same goes for redo. Also are more than one undo/redo step working correctly.

    So from a really zoomed out standpoint, Akonadi/KMail may work fine for people that share exactly your work flow. But may be broken for other people and it doesn’t seem like your tests are catching that behavior.
    I highly recommend the team to take an hour and watch this talk on youtube on how to write better tests: https://www.youtube.com/watch?v=u5senBJUkPc and use that to hopefully write a stable and solid akonadi-next.

  30. The worst possible answer you can give, congratulations.

  31. not really but your answer is.

  32. I am sorry to say this, but I have email going back decades and I would not want it anywhere near KMail.

    I know that all non-trivial software has bugs, but track record of Kmail has not been great for most of the last decade. Serious bugs on something critical to my livelihood makes me afraid and I think groupware is not a good place to be “experimenting.” So I kind of agree with Andreas K. Hüttel

    Thus, I do not install any of the kdepim packages. I actively hunt down and remove them on Ubuntu distros.

  33. Michael Thaler

    KMail was my preferred email client before Akonadi was introduced. It was certainly not perfect, but it worked well.

    Akonadi introduced a lot of complexity and I was never able to really get it working.

    For me, Akonadi and Nepomuk are good examples how to not develop software. For me, both just caused a lot of trouble and never really worked as expected. There is nothing wrong with developing Akonadi or Nepomuk, but it should have been done in a separate branch. Both were released way too early and caused way too much trouble.

    In my opinion, the main problem is the lack of resource. There are probably not enough people working on Akonadi / Nepomuk and such a central piece of software like a PIM suite should really be stable / relatively bug free / easy to set up- Nobody wants to lose his emails or debug databases just to get email working.

  34. Nassos Kourentas

    Keep up the good, hard work and please do ignore negative criticism that does not lead to an constructive outcome (the latter is a pure waste of time and effort)!

    KDEPIM community is and should remain as much active and focused as possible! It’s vital for the entire ecosystem!

    Thanks to all contributors for the masterpiece you keep on offering!

    • but still it’s grown to be a too complex beast for the team to manage and when people step up and raise awareness of the simple fact, that everything became to complex they get blamed.

      it’s working software if you have standard-setup a, but definitely no masterpiece, as i expect from masterpieces to work at least in some edge cases and to fail gracefully if not and not completely as it does with akonadi

      and again, the criticism is mainly focussed on akonadi, and not on kmail or other programs, although they might have problems too.

  35. Andreas Scherer

    I have not read the planetkde article, but I can support several of the negative comments here. On a completely fresh installation of Kubuntu 16.04, I had already two major hickups with KdePIM, one with Akonadi, one with MySQL.

    Yesterday, Kmail crashed on a third leg: MYSQL, Akonadi, and Kontact are up and running, but Kmail won’t start (with no obvious error message). “dbus-launch kmail” works temporarily, but one incoming email was incorrectly processed and lost on shutdown.

    Time permitting, I’ll try to move my maildir to mutt or Thunderbird. 😈

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>