The Epik of Konqi's Krazy Army
I recommend this read to those interested in KDE, invested in free desktop environments, passionate about free software development, or who just wish to know more about and better understand my path.
It's a story at the same time technical, cultural, economical, ecological, social and psychological, mixing both personal and global perspectives. The technical aspects include KDE, the GNU/Linux desktop in general, and other elements of the free software world. A basic knowledge of KDE will help with the details, but the storyline can easily be followed by anyone familiar with the development of desktop environments or even to any veteran free software developer.
All of that in a more or less tasteful mixture of biography, comedy, documentary, poetry, dictionary and satireality.
Enough enigma−enjoy/endure!
Preamble
"KDE" originally stood for "Kool Desktop Environment". But a software project is more than its products. It's also its community of users and developers.
This story is about a Windows user who became one of these. It has been in the making for a long time. In a sense, it's the genesis of Kune ni povos. As well as the end of at least one epopee.
The Solitary Chimney
Turkeys, donkeys, monkeys and chimneys all exhaled air. But the air from chimneys didn't smell the same. Chimney air was dirty. Yet, new chimneys were many. The seasons were getting funky, and - increasingly - badly windy. Humanity was in a hurry. It was urgent to act before the skies got so stinky that Terra and Gaia would get angry.
The chimneys weren't all equal. One big house had the biggest chimney. It had been named the White House, but a century later, its chimney was pretty dirty−actually, not so pretty.
There was nearly unanimity that a treaty was necessary for chimney equality. Each land embarked an emissary on a multi-year journey. After a stopover in Rio de Janeiro, they would go until Kyoto to agree all could no longer build any chimney without fee.
In the White House lived the chief of his country, who had some difficulty. His neighbors wanted big chimneys too, so he couldn't sign the treaty. Ironically, he was not so happy with his mega-chimney. He preferred cigars, and found proximity to his smokyiley assistant Ms. Lewinsky, with her psychology degree still shiny, extremely tasty.
The lighter sparked controversy. The First Lady would excuse his adultery, but when public scrutiny reached its apogee, he had a moment of folly. Afraid to make the inquiry excessively lengthy, he refrained from a guilty plea at his testimony. Sadly, his perjury would only prolong his calvary for what seemed like an eternity.
The cigar-loving chief wanted to negotiate rules more friendly to any county which was already smelly. But with all the time and energy he had lost due to dishonesty, soon it was time for him to go back to privacy. To choose the next chief, there would be a survey.
Polling in these ancient times was rudimentary. Every grownup drew a cross on a piece of tree for the candidate they hoped would be the most worthy titulary. Their land of legendary opportunity had gone from oversea colony to sovereignty, overthrowing His Majesty. Its territory, which spanned the Mississippi's entirety, had risked its unity to end slavery. More recently, it had decisively triumphed over gravity to carry their highly starry flag to a celestial body, and successfully returned from that revolutionary odyssey with a dusty treasury for mankind to study. To many, their synergy−which they called democracy−was the envy.
But it was aging, as were some people in charge of the survey. Some had lost the ability to see and count their fingers correctly. Worse, the people were given a simple choice, but options they found tricky. The vice chief was one nominee. Originary from Tennessee, he shared the disgraced chief's ideology. Nobody wanted to turn the vice chief into another viced chief with very shaky integrity. As for the other nominee, he was from the chimney industry. The Tennessean ended the rivalry with more crosses, but too barely for the old people in charge of the survey to properly tally.
Despite the vice chief's plurality, it was ultimately his adversary who had a party and declared victory. The lucky sonny was a cowboy like his daddy. He said he was no Yankee. Definitely, he was no monkey; he knew the industry's vulnerability. The chimney was key - if any factory didn't have plenty electricity, his wealthy buddy's customary generosity could yield bankruptcy. Yet outside sunny Death Valley, generating energy fully cleanly with a chimney's intensity wouldn't be immediately easy. Many above sixty wouldn't fancy the necessary decree. And what utility would it be, when his only battery was military?
His greatest worry was the next survey, which would come quickly. His grocery would be pretty costly on his piggy money should recovery of his pre-treaty popularity require to carry penny candy, Kentucky poultry and Old Milwaukee to every family. Surely, plenty already had a heavy belly.
The new chief said becoming chimney-unfriendly would be as risky as letting the GDP do bungee:
The land of liberty would see no gloomy chimney fee under his authority. Without apology or further ceremony, he unambiguously ripped up his copy. What problem could there be? Should Ra, Helios, Sol or any deity unleash particularly incendiary fury on the entirety of biodiversity, the penitentiary was already at capacity. He had Discovery and more shuttles to steer clear from planetary misery and flee, free of injury.
Thus a sorryNot to say buggy presidency cost the Kyoto Protocol its relevancy. The price of a faulty survey methodology combined to debauchery would be hefty.
Once upon a time, nobody could foresee the United States of America would ever suffer greater stupidity and travesty.
This artistic work does not claim full accuracy. As part of an essay about activism, it uses polarization for effect.
The Republican party is not Pure Evil. In fact, even George's W. Bush's father, President George H.W. Bush, promised as early as 1992 “an action plan on climate change.”
Kelka utopii
It All Starts With a Hobby
…and a good dose of anti-hegemony
2 decades ago, I started learning Ido online. Ido - you know - the Esperanto which even geeks don't know. Or, as it was called, "the international auxiliary language".
If today's websites about Ido are not impressive, the situation certainly wasn't any better in 2002. But Ido was intrinsically easy, in particular for someone who knew French and English as I did. Moreover, I was an utopian, unwilling to admit defeat to a language as complicated and difficult as English.
And my interest was more than technical; in 2002, the USA had just closed its eyes on the world's greatest crisis, in the name of its (supposed) self-interest. I perceived that alone as an insult justifying repudiation of not just the country, but of its culture. Being mostly based in the USA, English became lingua non grata. English as the symbol of egoism, Ido as the opposing flagship of collaboration.
All of that was enough encouragement to persevere and develop a great knowledge of Ido, its history, its community, and of resources about Ido - as well as their weaknesses.
Fully Free
…and anti-monopoly
The domination of English was about to be solved. It was time for the next challenge. What better option as next target than the United States' greatest company? The choice had to be Microsoft, accessorily creator of the world's greatest personal fortune at the time, Bill Gates, the symbol of wealth inequality.
So the year after learning Ido, I discovered software freedom. I switched to good old Mozilla Firebird and started exploring more free software, and the free software world, at the time quite centered on SourceForge. I found SourceForge fantastic at the time. Not only did it offer to download tens of thousands of products for free, but it made them all discoverable under a single roof. SourceForge made project descriptions uniform and eased comparison by listing several properties for each, including their license, programming language and development status.
In 2002, there were already lots of open source CMS-s. But many weren't fully free, and many were focused on whatever one feature their developer needed. So in October 2002, a couple developers started a huge project: building a fully free and full-featured CMS. The result would be Tiki−the ultimate, universal CMS.
The Opportunity for IdoWiki
Like many projects, in its first year, Tiki had huge momentum. So much so, that in 2003, Tiki was chosen as SourceForge's July Project of the Month. At that time, no website about Ido was powered by a CMS. It was clear for me that Tiki could power a completely new and integrated Ido website to replace the scattered collection of websites each maintained by their lone webmaster (in the best case).
Maturity Reached Quickly
Tiki's version jumped to 1 at the end of October 2002. More major releases would follow quickly in early 2003. Soon after, I grew mature enough to become an adult - at least in Canada. On 2003-08-01, the first Tiki version to take more than 2 months of development was released, and I became 18 years old. Surely, this coincidence was a sign.
According to SourceForge, Tiki's status was "5 - Production/Stable". IdoWiki had found a mature engine, and a mature driver. It was time to power on the thing and get the future universal website for the future universal language rolling.
Not so Wiki
In August 2003, I had never managed any server, I didn't know anyone who had, and the only OS I mastered was Windows. But I was lucky - SourceForge indicated Tiki was "OS Independent". So before I would need a server, I could install Tiki locally, get familiar with it, confirm that it was the right choice, and start setting up IdoWiki. And so I downloaded a CMS for the first time.
In August 2003, I installed Tiki 1.7 on my own PC's Windows install. I worked around a small bug, but it worked. Until I hit another one. It turned out Tiki wasn't quite OS Independent, but merely designed to run on several OSes. No developer had actually tested my Tiki version on Windows.
In August 2003, I had never written one line of code in PHP... nor in any programming language other than *Basic or JavaScript. For the highly amateur developer I was, overcoming these small Windows bugs was quite challenging. I spent a lot of time in the bug tracker, looking at many unrelated issues, diligently commenting those I could help with.
In 2003, Tiki's first project manager was interviewed by SourceForge.The Tiki project wanted to be spared from that disease. TikiWiki would be the first software made the wiki way. And indeed, it would take less than one month for a project administrator to notice my activity and add me to a list of already hundreds of users fully empowered to develop Tiki.
A little Smarty and PHP
There was another thing SourceForge indicated which was (more) misleading. The Development Status field was determined not by SourceForge, but by each project. So in 2002, before Tiki was even 2 months old, and months before it was dogfooded for Tiki's own website, a project administrator moved the Development Status from "4 - Beta" to "5 - Production/Stable". It's only in 2004 that "4 - Beta" would be brought back as status.
There was no shortage of bugs in Tiki. Eventually, it became annoying to always have to wait for real developers. So I bit the bullet and read the PHP manual. I learned PHP and SQL.
Beyond Tiki
I also struggled more than other Tiki developers because I worked on Windows. My utopian side found it unacceptable to waste time due to a proprietary product. Moreover, when my mentor put me in charge of releasing Tiki 1.7.3, I failed to do it by myself because the release scripts didn't support my OS. And as I was getting less satisfied with Windows, a couple of my friends used Mandrake (a defunct GNU/Linux distribution). So, having so much fun with free software, I bit a way bigger bullet, installed Mandrake 9.1, and everything that came with it, including KDE. And in a matter of weeks, I switched to GNU/Linux as my main OS.
By May 2004, it had become obvious that Tiki's founders had left, momentum had started decreasing, and I had realized very well the amount of work left was colossal. I had already put so much time into Tiki that I had become quite skilled, meaning I could tackle a large share of the problems. Making my involvement that much more addictive, and even more of a time sink. It had taken quite a toll on my studies, and it had become clear that controlling that addiction would be very difficult.
So I decided to leave the Tiki project. I wanted to completely stop contributing, because I knew it would be a challenge to set some limit to keep a minimal contribution. At that point, I could have used my newly regained free time to go back to my original project of building IdoWiki. But I knew hitting Tiki issues while trying to build a website with it would be challenging, and my interest in Ido had diminished. My work on Tiki had forced me to read and write a lot more English with colleagues from all around the world, somewhat acknowledging its de facto auxiliary language status.
Plus, I wasn't quite back to my starting point; I was now a user of GNU/Linux. And I was about to discover that I had the greatest contender to occupy whatever free time a slow-to-heal utopian could manage to find. But there was a clear improvement: I had learned I had to put a clear limit to my involvement if I chose to contribute to a huge project.
Bringing Me to KDE
Germany's Impurity
The absolute "purity" I felt I didn't get from my desktop environment, I got from my distribution. I loved Debian not just due to its governance, but due to its transparency and independence. I was impressed by the Debian social contract:
1. Debian will remain 100% free.
2. We will give back to the free software community.
3. We will not hide problems.
4. Our priorities are our users and free software.
Slippery IRC
I was so inspired and hooked to Debian that I couldn't refrain from helping. And there was no shortage of opportunities to help. I struggled with quite a few issues at the start, and used Debian's IRC channel to ask for help. I appreciated the high level of expertise of its volunteers, but also noticed many helpers did not have the most welcoming attitude. I can't remember if I chose to give back to the community by sticking there or if I simply didn't leave waiting for answers which would never come, but I ended up helping others when I could. In doing so, I learned about so many issues, learned about Debian and GNU/Linux in general, and my software development skills exploded. I reported issues, watched and triaged thousands of tickets.
Many times, I was tempted to dive in specific problems. I considered in particular reviving the moribund KPackage to make something even better than Debian's Synaptic Package Manager. But I was aware enough of the risks to keep my involvement mostly high-level.
Most of my contribution was training and integration, by documenting, managing the suites, issues, reviewing communications and advising colleagues. In 2006, I had become one of the IRC channel veterans which I perceived as godlike just a couple years before. I had equalled their Debian expertise, and even their IRC bot mastery! The only thing I still missed to attain their supra-humanity was their infamous arrogance, surely coming from their age. But I was hoping to never get quite that jaded, ensuring our work wouldn't stay too repetitive; I started doing more and more to not only provide immediate support, but to improve the IRC bot's factoids, other Debian resources, and finally Debian itself, so that no support would be necessary in the first place. I became the strongest link between end-users and developers. I founded Debian's KDE IRC channel on OFTC, and moved KDE support there.
Very Friendly, Simply Picky
If you think using a GNU/Linux desktop today is hard, you weren't administrating one in 2004. At the time, it was a serious challenge. This had a major effect on the user community.
The community was very small, but it was "selective". Few people could improvise themselves as GNU/Linux administrators. Most people who ventured into that world knew someone from there. There were LUG-s, and they hosted installfests. The people who stuck weren't representative of the general population. They were often friends of existing members. They were not necessarily the socially smartest, but they sure were more intellectual than the average, and quite interesting for me to work with. Many of the greatest quotes I read came from that community. As UNIX popular wisdom wants…
Even if Xavier never got heavily involved in development, his adoption was significant. Not only did I gain someone with whom I could chat about news and challenges, but I gained a partner. When I entered university in 2005, Xavier and I both bought a high quality ASUS laptop. Although it was a laptop, we chose barebones, so we could pick the most FOSS-friendly parts.
Nevertheless, using our laptop at the university−as we had intended−was quite a challenge. We had chosen a truly open wireless card (Ralink's RT2500), but one which was little popular. Consequently, the drivers were sub-par. Each connection to the university's wireless network was a small−often unique−challenge. In retrospect, this seems unbelievable, but over the years I must have spent person-weeks just accessing the university's network. The university used a Cisco network and didn't support the only Linux client, vpnc. In fact, if it wasn't for a "certain" friend, I couldn't have made it; he was the one who managed to crack the network so we could connect with vpnc.
Determination as Key
By getting help and overcoming difficulties, then in turn helping others and intensely playing the role of community liaison, I quickly became an actual developer. In fact, by the end of 2006, I had become one of the developers most knowledgeable about Debian. In less than 3 years, I had gone from a minor who hadn't written one line of actual code to a top contributor of one of the world's most important software projects. All of that without even asking for privileges. There was no way the young adult I remained could have such an impact without being truly hooked.
Reality
In my first year or 2 on GNU/Linux, I used to keep a local list of the main issues I saw with GNU/Linux, hoping I could at some point evaluate how fast these were being solved. As I started reporting more and more of these, I lost the interest and stopped maintaining the list. But the issues didn't stop. With my level of involvement in Debian, I had no choice but to use a rolling release (testing in my case). And KDE being a second-class citizen in Debian, using Debian testing with KDE meant new issues would come non-stop.
The Quest for Stability
All of this work was super exciting, except for one thing: 100% of the time I invested was on a volunteer basis. 
My trivial decision not to leave IRC had caused me to slip. Digitally, I had the surreal chance to land on top of Mount Everest. Unfortunately, academically, my grades had dropped quite a few steps.
A Kool, FOSS-friendly PC
But although that desktop is still going strong 8 years later, my account of the install suffices to confirm it wouldn't put an end to even low-level bugs. A couple years later, as my free time and involvement had gotten much lower, I took an extra step hoping to stabilize my OS by dropping testing and sticking to Debian stable.
Yet, in 2018, despite stable, top-quality hardware with mature drivers, more than a decade of experience administrating the OS, and having contributed to solving well over a thousand of the issues I experienced in Debian, KDE and other projects, I was still wasting too much time dealing with bugs and using an OS whose stability was nothing to boast about. My free time being even rarer, I decided to reconsider a basic choice. As KDE on Debian remained rare, perhaps I would attract less bugs using a different desktop environment or distribution?
A Quest for Popularity, Setting Trajectory Towards Heresy
A Disco Dingo Which Turns Out Finicky
And so−too reluctant to try GNOME once again−after 15 years on Debian KDE, I chose the element I had been loyal to for the longest−KDE−and reluctantly gave in to Debian's worst heresy. I pushed Debian aside and installed Kubuntu 19.04. Not without skepticism, which quickly turned out to be founded when I realized one of the applications I used the most−KOrganizer−was nearly unusable. And weeks later, the situation hadn't improved. I was still unable to create a calendar event with proper start and end times.
No Vacation for Loyalty
Having treated so many issue reports, I hate irrelevant reports being filed against outdated versions. So when I stopped using Debian testing, I effectively stopped reporting issues to KDE.
In July 2019, it had been nearly 5 years since I had last reported an issue to KDE. Thankfully, I was finally running a current version of KDE, and I had a month of "vakation", which allowed me to investigate my problem. It turned out "the issue" was the result of a change in Qt exposing 2 long-standing KDE bugs. I was about to do some catch-up on my years of KDE inactivity.
So in July 2019, I reported the result of all these to Canonical and the 2 underlying KDE Frameworks bugs to KDE. I also reported the impact of CLDR's change behind Qt Locale's change to the Unicode Consortium. Of course, all of that was entirely unreported. 
Figuring that out required a deep look at the ITS, in particular since the faulty KDE components were hard to identify.
My upgrade to Disco Dingo had unfortunately disappointed once again my hope to see a long-standing KOrganizer bug fixed. I was still losing reminders. So I used that occasion to try at least determining if that one was tracked. I tried figuring out exactly what would reproduce the bug, and in doing so noticed even more KOrganizer bugs, and triaged quite a few. I ended up having reported 5 bugs affecting KOrganizer. That did not include the infamous reminder losses bug, but I did subscribe and vote for ticket #317656, which tracks either that bug or one with very close symptoms. I was not able to do all the triage required, but I did ask its Importance field to be fixed.
All of these searches and reports on KDE's antiquated Bugzilla-based tracker highlighted quite a few of its issues, which−equally unsurprisingly−were also unreported So I filed a few more tickets against bugs.kde.org.
A Prodigy's Emergency Kleanup Spree
All this triage had gotten me to flag some tickets as in need of more information. In at least 3 cases, a month after I intervened, the tickets were marked as resolved, and their resolution set to WORKSFORME. The accompanying comments were unclear, but it was clear that the problematic account was controlled by a bot acting automatically. Its behavior was not entirely erratic, but after watching it persist for nearly a week, as its owner was not indicated, I tried to contact him by writing to its email address.
Don't ask to clarify−I already tried.
The Cavalry's Fury
At that point, a krusader had been awakened. His fury would encompass many tickets, 5 issues being marked as resolved. Unfortunately, even as I write these lines, most (and−to the best of my knowledge−even all) persist. My quest had bekome kuite komplikated. Had I found my match?
Pleading the Army for Mercy
In November 2019, my quest's prospects looked bleak. I had had to report 1 bug against Ubuntu, get involved in CLDR, in particular to report the issue which had broken calendars, and file no less than 17 tickets against KOrganizer, KDE Frameworks and KDE's ITS, all related to my KOrganizer issues and the triage of KOrganizer issues I had done ensuring they were properly tracked. And none of these had been solved. Even the major KOrganizer issues I had reported in July, a full 3 months earlier, didn't show any sign of progress.
Worse still: from these nearly 20 reports, only one had been "confirmed"/acknowledged (even though most had been filed months before). In fact, the one contributor who had acknowledged one issue had also marked 5 others as resolved before any work had been done, effectively hiding issues. And nobody else had intervened. Not even 4 months after the issues had been reported, 6 had been mishandled. I had invested a few person-weeks in this debugging and had reported that many issues on the impression that they were all unreported. But if mishandling was so widespread, had I just wasted so much time reporting issues which had already been reported - but which I failed to find in my searches because they had also been mishandled?
And there was more: in the course of all my triaging, I had noticed multiple tickets whose "Severity" (importance) field was wrong or outdated. KDE's ITS leaves much to desire in this area; unable to even downgrade the "Severity" of issues I had reported, I did all I could: I commented, so someone with the necessary permission could do it. Weeks after I had requested 6 such changes, none had been acted on. Clearly, there was a systemic issue.
Clearly, in November 2019, KDE's issue tracking was in a really, really bad state. So I reported some of these meta-issues to the KDE community mailing list, hoping to get help properly diagnosing and solving these.
Santy-punity
Anyone who was involved any seriously in large free software projects knows about 2 very widespread (I could almost say "universal") plagues: lack of manpower and exceptionalism. Plagues which are far from exclusive to the free software world, or even to the software world. Perhaps such comorbidity is causal - does a group's small size not make its members even more exceptional?
Sooner or later, when mixed with competition against equivalent products, these inevitably result in developers burning out, abuse and issue denial, sometimes culminating in cover-up. Developer burnout is far from exclusive to young people, whether in the volunteer or corporate world. And the behaviours it brings can be surprising, even for middle-aged developers.
What does set projects apart is how these cases are handled. And consequently, how prevalent burnout and related behaviour becomes. In several projects, at some point, flamewars and abuse become so common that they become part of the norm and stop standing out.
The reaction to Issues with the issue tracking system was underwhelming. None of KDE's Directors reacted.
The least bad reply was Martin Flöser's, who confused the requests to adjust ticket importances with "nagging" to fix bugs. There was not the least useful answer about ticket importances.
The other reactions were about ticket mishandling. Characterizing the reaction as impunity would be a euphemism. There was no suggestion of any remedy. But there was condemnation, and even allegation of disrespect… supposedly displayed not by the perpetrator, but by the denunciator.
The only reaction from a KDE e.V. member, which best summarizes most answers, would be best described as anti-punity…
An Ultimate Plea
My attempt to fix ticket importances had failed. However, my consultation about the remedies for Graham's case could be considered as success. Not the one I was hoping for, but a clear demonstration that nothing would change. If KDE could not be shaken by such a fiasko, nothing would ever be enough. KDE issue tracking was unsalvageable. My quest to fix KDE alone was another utopia.
Following this admission, I changed my approach. In December 2019, instead of persevering in an attempt doomed to failure, I presented myself to the community and the issues I was facing, not as a developer, but as a KDE user. And I asked the most open questions possible, so I would hear about any solution. I was hoping I would hear about secret ways allowing to move as close as possible to the backseats, which my Debian loyalty would have caused me to miss. I asked how I could become a mere KDE user, and stop being a developer. Whether, in a not-so-distant future, I could hope to use KDE without regularly resorting to issue tracking systems−at least not KDE's. If I could be a free rider for real−not necessarily riding free of charge, but without sacrificing my "free" time. Or minimally, a reasonable and non-miserable time.
I was quite skeptical about what this attempt would achieve, but I had no choice left. I had tried GNOME unsuccessfully. I had tried KDE with several of the most popular GNU/Linux distributions unsuccessfully. I had tried fixing KDE. And I knew going beyond GNOME and KDE would only add disappointments. If I couldn't just use KDE, the only choice I would have left would be to completely change OS, once again.
I was hoping to be shown that most KDE users were now using *SUSE, which would be much more tested than any other KDE distribution. Or−at the very least−to be reassured with encouraging data demonstrating that development was or would be accelerating.
Krusader by Day, Janitor by Knight Is 2019 Best Drama Movie
In February, while researching an essay inspired by a recent KDE proto-flamewar, I learned that Nate Graham had been awarded the Akademy award for "Best non-application contribution" at the beginning of September 2019, 'for persistent work on the "KDE Usability & Productivity" blog'. In a sense, this put a different light on the incident. Perhaps it resulted not so much from burnout, but more from recognition-induced overconfidence, which−with some luck−could quickly fade away.
On the other hand, seeing Graham receive the same honours which−the decade before−were reserved to David Faure, Aaron Seigo, Sebastian Trueg and the likes did not augur so well for KDE's future.
No cacophony
Back to our story. In the end, nobody suggested I try openSUSE. There was also no response regarding momentum.
In fact, a year has elapsed since my December 2019 message, during which a few hundred mails were sent on KDE's community forum. But, as I write these lines, that plea remains entirely unanswered.
Has the situation improved during that year? Did our krusader just leave? Unfortunately, while the above account is largely centered on him, those who look up the full details will notice that the description is slightly caricatural. In reality, a few other contributors were somewhat involved. I don't want to generalize; I know for a fact that KDE still has experienced, wise, healthy and professional contributors involved to some degree, some in leadership. But I saw a worrying share of KDE contributors showing hints of similar patterns. I do not know if the krusader leaving or taking a break from KDE would be a positive or a negative thing for KDE. But I do know KDE would still be in a seriously worrying situation.
Remember my list of issues of the GNU/Linux desktop? In an earlier blog post, I mentioned Artem S. Tashkinov had (unintentionally) brought my project to a whole new level. His list was updated once again no later than in 2021. Guess what - one of the ironic issues I mentioned having worked on in 2016 is still there in 2021 (it persists at least in Ubuntu 19.04). Well, that issue, which I mentioned because it was mistakenly marked as resolved, and which is now at least 17 years old, is still marked that way, a full 5 years after my post. And that's not the fault of our krusader, but that of Martin Flöser. Just another bad apple? I'll let you judge pointing out that's the same Martin Flöser who I mentioned above for authoring the only half-decent reply to Issues with the issue tracking system.
Would the situation with severity tracking have improved? No such luck. Just this year, I was alerted about a long-standing defect whose report was recently marked as not reporting a bug, by Justin Zobel. Who is that? Having never heard about him, I checked. It turns out Zobel is a recent addition to the "KDE Bugsquad".
That's for the reassuring part. The other part? The affected ticket reports an easy to fix major meta-issue, reported against the bugs.kde.org product of bugs.kde.org, presumably the product whose tickets should be best handled, as they should be well monitored by KDE. When we see that Zobel is the only KDE contributor who started a discussion on the KDE Bugsquad's discussion forum in the last 5 years, we can safely deduce that squad is scaringly non-scary. For context, in 2009, 34 topics were discussed on the same forum. So much for reassurance
I can't discuss severity tracking without mentioning a final point. There is nothing truly new here. The same Justin Zobel recently accidentally got me to realize one more case going back as far as 2004. Which I've asked to fix in 2007... still without results. I'll let the reader judge whether that's reassuring or worrying.
Ticket mishandling is also nothing new. Even a ticket reporting the ITS's issue with severity tracking was itself mishandled by a different kolleague as early as 2011.
It is krystal klear the symptoms reported are not specific to a single contributor, and are not going away anytime soon.
A Grahammy-Worthy Rebrand of KDE
The project which inspired me most and which I contributed to the most disapproves of making up excuses for hiding issues. Not just by convention, but per its social contract, with the following as third article…
In contrast, as I am writing these lines, KDE's issue tracker documentation has been defending marking as resolved issues on which no work was done at all, for a full 3 years…
Contempt and issue denial has firmly started entering kulture. Not just praktice, but doktrine, and even tools, forcing contributors to effective komplicity.
As mentioned in the preamble, "KDE" used to stand for "Kool Desktop Environment". Since then, perhaps after becoming more inklusive, the "K" lost its meaning, so "KDE" would only mean "K Desktop Environment". But KDE wanted to become more than a desktop environment, and that sense of "desktop" didn't age so well, so the "D" lost its meaning too.
KDE may still be an environment, at least a human environment, but "KD Environment" being a little strange, the ex-acronym has had no defined meaning for more than a decade. In light of its status at the start of this decade, I think it's time someone proposes a new definition…
As a product, KDE was never very functional; it's always lacked a lot of the functions and stability of the leading options. But the cost in time and frustration could be seen as an investment compensated by the pride to be associated with a remarkable project.
As a product, KDE may not be less functional today than it ever was, at least in absolute terms. In relative terms though, I doubt it has followed the competition. In my first years with KDE, I used to browse with Konqueror, which worked almost as well as its GTK competition. But with the web platform's evolution, I had to go back to Firefox more than a decade ago. Even in my KDE-est years, I always used some GTK applications, in particular for advanced Debian package management (Synaptic). But over several years, I gradually gave up on several KDE applications and switched back more and more to GTK solutions. I no longer use KDE or even Qt products for web browsing, email, or as office suite, where GTK (Firefox and Google Chrome, Mozilla Thunderbird and LibreOffice) now/still truly dominates.
Even in the KDE applications I still used, functionality is not necessarily maintained. After I switched to Ubuntu 19.04, I switched from Kopete, which I had been using for 15 years, to Pidgin, due to Kopete having become unstable. One of my worst disappointments was to realize that the same migration had also got me to lose the KDE product which had been my favorite for more than a decade, Amarok, which was removed from Ubuntu starting with 19.04. Amarok still hasn't been ported to Qt 5, and was removed from Debian as a result (although a fork of Amarok also based on Qt 4 is for some reason still included). Consequently, the best music player I found in Ubuntu 19.04 is Clementine, based on that old fork of Amarok. The only official KDE applications I was still using on a weekly basis with Ubuntu 19.04 were KMix, Yakuake, Dolphin, Okular, KWrite, KNotes and KOrganizer, despite experiencing serious bugs with the latter 2.
But KDE was redefined as a community rather than as a product. That hasn't helped users figure out which components are useful and which are only curiosities. How could one tell looking at its applications which one of Dragon Player, Kaffeine or KMPlayer is best for playing videos? Unless distributions help, how could one tell that in fact, neither Elisa nor JuK is the right choice to play music? How can a user tell a mature application like KPatience apart from a project which puts their data at risk like KMail?
As a community, KDE's functionality is lower, and seems to be on the decline. Our relation with a project is based on its results as well as its community. Nowadays, being associated with KDE is for me a source of more shame or guilt than pride.
From Dysfunctionality to Pathology
Kommunity
You may remember my interest in Ido and GNU/Linux did not just come from Ido and GNU/Linux. It also came from their communities.
Ido's community is much smaller than KDE's. Both communities are composed of intellectuals, and their members are probably of comparable intelligence. I see the difference in these communities as twofold:
- Communication
- The Idist community has a common language mastered by all its members.
- Idists are inherently interested in communication. They tend to excel in communication. KDE contributors are−for their part−technologists. They are not as interested in communication, and in fact, many tend to be less skilled in non-linguistic aspects of communication.
- Health
- Ido’s difficulties since World War II have unfortunately left it with a community on average very old, and therefore:
- (hair-)wise
- largely retired, and therefore less short on time
- Involvement in Ido rarely requires coding. As the main task is to write literature, the main barrier to entry to contribute to Ido is mastery of Ido, which−for speakers of many Indo-European languages−is quite low. In contrast, involvement in KDE requires mastery of a system relatively complex even from a user perspective, and very often, of technologies rarely taught in school like Qt as well as the somewhat aging C++, not to mention the numerous additional frameworks almost all KDE components may rely on. And most importantly, mastery of the implementation of the component which needs work. Such a high barrier to entry comes with a corresponding tendency to high levels of involvement. As this work is usually volunteer, this pushes many developers to overwork. And to make things worst, coding requires high focus, something particularly hard to maintain for professionals who can only volunteer in their spare time.
- Ido’s difficulties since World War II have unfortunately left it with a community on average very old, and therefore:
Barriers to entry are particularly important. It is no coincidence that the most under-provisioned task Ido needs, the development of Ido itself, is the task with the highest barrier to entry. Ido’s community lacks linguists with enough expertise in many languages to create quality vocabulary.
In general, Idists are neither badly under-skilled for the task they are trying to accomplish, nor burnt out. The health differences make Idists way less susceptible to burnout than my kolleagues, even if involvement is entirely volunteer (i.e. even more volunteer than KDE development). Despite my relatively young age, I appreciate collaborating with Ido’s old community considerably more than with KDE's (the same could be said of other struggling free software projects).
Kuantity
.jpg "KDE developers, a resource doomed to pandemic scarcity? Credits: Wilson Hui")
I just described how KDE−as a product−has slowed down relative to competing free software. For a more objective analysis, let's use my July 2019 vakation’s battle as example. The first resulting fix was integrated 1 year after I reported the issue. The other major fix was committed over 15 months after I reported the issue, to be shipped in KDE Apps’s December 2020 release. That means the fix first arrived in Ubuntu in version 21.04, which is just a short-term support release. To truly reach Ubuntu's corporate users, it will take Ubuntu 22.04, which won't ship before April 2022. That is, unless there is a backport, a serious bug in a core productivity application will have taken from 11 to 33 months after reporting to be fixed in a distribution owned by one of KDE's 7 patrons. Even if most of the work had already been done.
Irony
But none of this is news to the kommunity. In 2017, KDE set 3 goals for itself. 2 for the product, but one for the community: streamlining the onboarding of new contributors. Each of these "winning ideas" was as noble as vague, but included some specifics, such as the following for the last one.
The first challenge was to make these goals actionable. The community goal resulted in several concrete tickets proposing changes, notably to the ITS. Some of these proposals were implemented. KDE e.V. even funded an onboarding "sprint", right during my vakation. While a few changes brought new issues, a number of valuable changes were made.
But in all 3 cases, these "grand ideas" were too wide to be accomplished quickly. The goals were supposed to "define the general direction of the KDE project over the next three or four years". So it may be unsurprising to see that 3½ years later, all 3 are still recorded as outstanding.
Yet one thing might not have helped. Not even 2 years after setting these goals, the community decided it was time to replace them. Besides generating new verbiage and press releases and replacing existing goals with even less achieved new grand ideas, the process also resulted in the disappearance of any community goals. All new goals were "all about the apps", all about the product.
Coincidentally or not, this change happened right as the above fiasko was unfolding. Remember the ticket reporting a major ITS issue which had been mishandled in 2011? I fixed it. Only to see it broken once more just the same way in November 2019, by a different kolleague. No other than David Edmundson, another dekorated treasure (2018 Akademy award).
You're reading right. Most of the kommunity had realized the necessity of increasing its insufficient manpower. Part of it had put time and money into declaring and advancing its goal of streamlining onboarding.
It specifically ambitioned to form "a welcome team to guide newcomers", find "a mentor for each newcomer" and solve issues with its ITS, aware of the important potential of ITS contributors. Yet, at the same time, when the very people it considered as "new contributors" were helping to make that very goal actionable, rather than trying to retain, value and empower these contributors, another part of the kommunity was kontradiktorily dismissing their work.
Low-Kuality?
Some would argue the above exposes an issue in the quality of contributors. That KDE is too open.
The Tiki project is notorious for its laxist granting of permissions. KDE is considerably better in that regard. Getting a "Developer account" requires one to submit an application. The approval process is undocumented, but judging from the form, it should suffice to filter the worst applicants. KDE has no list of who went through that process and how each developer did. The process is undoubtedly far from Debian's rigor, but I believe that is not a huge problem.
Successful large-scale peer production projects have shown that the barrier to admit contributors can be surprisingly low. What matters is not so much the minimal quality of contributors as the average quality, and the level of power each contributor holds. A smart power distribution combined with processes often based on soft security can compensate inexperienced contributors and their mistakes.
The main issue depicted above is a soft security failure. In general, soft security's weak point is identification of mistakes. But in this case, plenty were well identified and reported. In this case, soft security failed because mitigation failed. There was simply no mitigation; no one followed up. 2 factors could explain that.
The first is failure to reach sufficiently privileged members. It could be that no sufficiently important KDE member has seen the report. This hypothesis breaks down when we see a 2-week period at the end of Q1 2021 where all board members but one were involved in discussion on the very forum where the report was sent. It is clear that the board follows kde-community pretty well.
The second possibility is reluctance to intervene. Many may find a furious krusader intimidating. But a krazy krusader can also be effective, if his fury is properly directed. In a mini-army, no one wants to lose an effective soldier. Managing a mercenary to whom you can't offer any money is a delicate task.
Managing soldiers well requires military experience, management experience, and the resources needed to design balanced measures, and apply them. Visibly, KDE lacks the manpower to do that at this time. It probably has for a long time; while I've never been as involved in KDE as in other projects, I find it particularly worrying that I haven't had to turn down any recruitment attempt, after hundreds of contributions. My case may be anecdotal, but if top talent isn't allowed to adjust the importance of its own issue reports after 15 years of involvement and becoming a member of the Bugsquad, KDE may have important recruitment issues. And indeed, many people I see today have been here for a long time (which is of course a sign of health, but only up to some degree).
I don't think low-kuality kolleagues really explain the above situation. I believe KDE's recruitment/management shortcomings can be attributed to insufficient experienced community managers.
Lethargy
We've already seen a number of problems:
- high issue density in the products
- frequent regressions
- neglected documentation
- legacy ITS engine, many issues in ITS
- neglected issue database, high share of issues unreported to KDE and/or improperly tracked
- issue denial
- decreased activity, discrepancy between capacity and ambitions
- delays to fix major bugs, some reported
- insufficient development, wide failure to keep up with competition
- (presumed) burnout, failure to detect/manage burnout
- insufficient recruitment and community management
- little, diminishing distribution in operating systems
What do all these symptoms amount to? The lack of code review could explain the first couple... but then why doesn't KDE already mandate code review? This all seems to point in too many directions, but there is one simple disease which can explain all of the above : lack of manpower, or more accurately, a general lack of momentum. I unfortunately can't see a single specific issue which would be the key to KDE's recovery.
KDE doesn't have the necessary combination of product and community to keep up. Its product doesn't attract enough distributors, which don't attract enough users, who don't become developers able to improve the product, nor managers able to integrate these. Code review is a lot harder in projects which have a single developer. Insufficient resources hurt the infrastructure, and encourage multiple tradeoffs to maintain pace, including overwork which degenerates too often into burnout.
Agony
A Mini-Khronology: Momentum, Trinity and the End of Supremacy
While researching this post, I realized it was no wonder why my plea was met with silence about openSUSE. It seems openSUSE no longer defaults to KDE since at least 2020 (after a first short departure a decade earlier), and SUSE Linux Entreprise has even been defaulting to GNOME since 2009! GNOME is now default on Debian, Ubuntu, SUSE Linux Enterprise and the Red Hat family. Where does that leave KDE? I don't know exactly, but visibly no preference from any distribution which matters, really. KDE's own page about distributions starts with Kubuntu! But it's not alone; from the 5 distributions listed, 3 are just KDE flavors/images of distributions which don't default to KDE! The other 2?
- KDE Neon, a distribution based on Ubuntu and built by KDE (mainly Jonathan Riddell, after his resignation from Kubuntu)
- openSUSE, which (as just explained) doesn't even use KDE anymore by default
The last of these 5 "featured distros" is "Manjaro KDE", the KDE flavor of Manjaro Linux, a virtually unknown distribution based on Arch Linux! Tough times
Measuring the market share of desktop environments is extremely difficult, and I don't have precise data any more than anyone else, but KDE's situation has surely become grave. I'm convinced the following is close to the best explanation a handful of paragraphs can achieve.
At the start of the millennium, KDE was propelled by Mandrake's leading market share. 2005 was an important year, as Trolltech made Qt available under the GPL on all platforms (not just Qt/X11). And in 2009, Qt was released under the LGPL.
But something which would turn out even more important for KDE happened before. In 2004, when I last tried GNOME, KDE remained the desktop environment with the most market share. Debian was at the peak of its worst crisis, and a new company created its most consequential fork. Canonical, which would (years later) bankrupt Mandrake, was created, and picked GNOME as the default environment for Ubuntu, the distribution which would effectively replace Mandriva in the following years. Initially, Ubuntu must have been unsure about its choice, so it also created Kubuntu, based on KDE.
In 2008, KDE had already lost considerable market share when it botched its release of KDE SC 4, a major re-architecture. While doing so, it lost its most famous user, as well as its reputation of superiority. KDE suffered a surprisingly significant fork, and the already ridiculous fragmentation only got worst. In 2012, Canonical stopped funding Kubuntu, worsening an already strong trend for Kubuntu and KDE.
In 2000, KDE's main discussion forum about development received 23182 messages. There is no doubt that's a lot of traffic for a single mailing list. A significant share of these messages were−ironically but understandably−requests for unsubscription. Arguably, it may be a good thing that the flow has since diminished. Perhaps that's a sign that some issues have been settled, or simply that more forums were created allowing to send more messages to more focused mailing lists.
What would be harder to argue is that a reduction of traffic by more than an order of magnitude is not worrying. Yet, 20 years later, kde-devel traffic had dropped so much that it received a mere 934 messages in 2020. And what is undoubtedly worrying is to have to rely on MARC's archive to collect the above data, since KDE's official archive is broken, having been incomplete for months, if not years.
When Canonical moved momentum in GNOME's favor, it did not immediately seal KDE's fate. 12 years later, Slashdot asked whether KDE was slowly dying. The answer to that may have come a couple years later, when Red Hat announced that Red Hat Enterprise Linux would no longer support KDE. And indeed, the release of version 8 saw the removal of KDE from RHEL's current version, as soon as 2019. Since that post (published 2016-08-20), 57 months elapsed, during which Slashdot published 27 more posts in its KDE category, averaging 6 KDE posts/year. In contrast, during the 60 months between 1999 to 2003 inclusive, Slashdot published 168 posts in its KDE category, averaging 34 KDE posts/year… 6 times more stories than recently. And no, Slashdot doesn't publish less stories in general. ReferenceSlashdot doesn't make it easy to compute such statistics. I manually computed these figures from the following 2 pages: latest, oldest
As I write these lines, KDE's relative importance in the GNU/Linux desktop market has been slowly decreasing for over 15 years. And unfortunately, I am convinced its popularity has also been going down in absolute terms. It could be said that KDE has traded its initial licensing deficit and strong market share lead for a popularity deficit. Unfortunately, Qt's previous year has shown this perspective may still be overly optimistic, and that KDE could soon go back to a complicated relationship with Qt.
gNO-Money
Donations can be heavily influenced by marketing and are far from allowing precise comparisons of market share. This comparison strongly suggests that KDE has lost much to GNOME in 15 years. But it doesn't show GNOME decisively winning a war and benefiting exponentially. The GNU/Linux desktop ecosystem remains encumbered by high fragmentation.
In contrast, the Mozilla Foundation measures its income in millions of USD-s (829 in 2019). Mozilla's issues are undoubtedly mostly rooted in its governance, and the vast majority of GNOME development is not funded by the GNOME Foundation, but if Mozilla is failing in its core mission with a budget orders of magnitude greater than GNOME's, it's hard to imagine GNOME succeeding in an enormously bigger mission - developing not just a browser, but a full desktop environment - without a huge further momentum increase.
It seems like supreme irony and cruel unfairness to think that Mozilla, despite its financially comfortable situation, is crushed by competitors based on WebKit and Blink... which are ultimately based on KHTML/KJS, tiny and completely underfunded KDE sub-projects, and that Konqueror remains such a poor browser, more than a decade after WebKit's creation. But such is free software. 
Legacy
I would have wished to end this story on a more positive note than the previous. Unfortunately, I still remember the teachings from my experience as a young sailor. And I am highly skeptical that I could change KDE's destiny alone−even if I magically got funding to work on it fulltime. The project is not what it was in 2004; KDE has changed. It's no longer just about fixing a product; it's also about healing its kommunity. Any of these tasks is surely too much for any single person, and I will certainly not tempt fate letting myself become one more burnt out kontributor worsening the problem.
And there is also a matter of integrity. I would feel komplicit staying part of a decades-long and uncertain project to finish a product, while marketing it as stable and dissimulating its issues all along the way.
So here I am. While I may follow up on issues I started driving, this epik will remain my last significant direct volunteer kontribution. I do not repudiate my past involvement in KDE, but I should be considered unassociated from now on. It has already been more than a year since I used KDE as primary environment on any of my PC-s.
Oligarchy and C Shielding from Ignominy
Everyone knows my tendency towards tenacity. So where does that leave me and my quest for a free PC OS?
I am neither as energetic nor as utopia-prone. Microsoft, its operating system and other software are relatively far from being as dominant as they were in 2003, at least in relative terms. Even Microsoft Office now uses open formats by default, and acknowledges inclusion of tons of free software. Free software is now in the mainstream media, and way more widespread, even in relative terms. Even on PC-s, where it's in all browsers. The world has in large part adopted free software - it is no longer a war between one company and a bunch of utopians.
The USA's electoral system is still far from being fixed. Thankfully, the USA is nevertheless more aware of the climate crisis. More importantly, its domination is being challenged by an oligarchic superpower, at least economically.
The climate crisis is certainly far from resorption, but correspondingly, denial of its impact has marginalized. The USA remains a top greenhouse gas emitter both in the absolute and per capita, but its per capita and absolute emissions have started diminishing, and it has finally joined the Paris Agreement (for now…). Arguably, it may no longer be the greatest environmental threat, now or in the medium term. The USA nowadays evoke greater pity than anti-hegemony, at least for me.
The career in software and the many more software projects I now have satisfy my passion for software, and make it much harder to free time.
If I was to give a last chance to another desktop environment, I would try GNOME, as it's surely the one most advanced and which has most momentum. But I wish to minimize the probabilities I ever have to touch C again, and I am skeptical that this decade will see the triumph of a free desktop based on it. The choices GNOME made over 2 decades ago mean its barrier to entry is even greater than KDE's (and its attractivity to volunteers motivated by learning technologies is even lower).
And GNOME's momentum isn't extraordinary. If its finances suggest acceleration, media coverage gives a different picture. To use the same comparison as with KDE, during the 57 months since 2016-08-20, Slashdot published 46 posts in its GNOME category, averaging 10 GNOME posts/year. A lot more than for KDE, but in contrast, during the 60 months between 1999 to 2003 inclusive, Slashdot published 178 posts in its GNOME category, averaging 36 GNOME posts/year… 4 times more. ReferenceFigures manually computed from the following 2 pages: latest, oldest
GNOME's momentum doesn't benefit from the GNU/Linux distribution which−technically−has the most momentum, by far; Chrome OS, the only OS with strong momentum which could be considered as a GNU/Linux distribution, is unfortunately one of the least interesting, based on neither GNOME, KDE, nor any other real desktop environment. According to The Register's analysis, GNOME's momentum was broken by threats made by Microsoft more than a decade ago; what replaced KDE's short-lived dominance was a sky-high fragmentation which remains out of control.
Finally, GNOME, like any GNU/Linux environment, is based on−well−GNU/Linux, and its PC foundations. There is no way to use GNOME without experiencing GNU/Linux. The previously mentioned list of issues from Artem S. Tashkinov may be very harsh (and vulgar) and over-emphasize a few issues, but I think it overall supports its conclusion pretty well; GNOME's budgetary lead over KDE is far from enough to make a real difference. Making GNU/Linux competitive on the desktop would require a multi-year effort with a budget not in the hundreds of thousands, but in the hundreds of million euros. (That same list acknowledges lack of manpower as an issue not just for KDE, but also for GNOME.)
Prophecy
Given my mixed feelings, I chose to spin this epic as half-dramatic and half-comic. But the path to this post was nonetheless seriously difficult. Giving up on KDE was already a difficult enough decision to take. Giving up on GNU/Linux on the desktop is even harder. It feels like throwing away a huge part of the efforts I put into this, a bit like disowning an adopted child.
I know my kolleagues won't find this read to be the most pleasurable and motivating. I have no krystal ball and am not pretending that KDE becomes insignificant today. I hope this doesn't stop unduly anyone's efforts, and rather encourages others to review their priorities, and perhaps understand the importance of licensing. I know that all KDE contributors−including all those discussed above−have good intentions, and in a sense, I am grateful for what happened; was it not for this incident, I would have had no choice but to come to that same decision later.
Victory Simply Unlikely
Can KDE's momentum be restored and get even further? Unlikely, but nothing is impossible. My knowledge of KDE's current architecture is modest. I did not read even 0.1% of its code. KDE's architecture massively improved in 15 years. I definitely can't say KDE has the best architecture from among the current options, but I certainly can't exclude it. If one day a massive organization decides to switch to a free desktop environment and has the resources to build a quality one, that organization may choose KDE as a basis.
The United States of America would certainly have the resources to bring the necessary momentum, but would just as certainly lack the political capacity to launch such a project, competing with one of its greatest companies. Could the world's third economy revive KDE? Can Japan, a unified and fairly democratic and socialist state highly dependant on technology, overcome NIH syndrome by focusing on improving its commercial balance with the USA, and allow a Western technology to breakthrough? I won't hold my breath, but nothing is impossible.
For my part, that approach will be the form in which I will remain involved. As a Canadian citizen, the chances my country will be part of such an initiative look slim, but I will be sure to encourage it as much as possible. Who knows if Canada can one day integrate a transatlantic EU? And if such a strengthened union could finally figure out maths.
Back to slightly lesser(?) utopia
Posterity
I thank Chris "calc" Cheney, Pierre Habouzit, Josh Metzler for their work on early Debian packaging, Glen Ditchfield and Albert Astals Cid for helping me stop my quest with some satisfaction, the latter in particular for his relentless work on KDE. And most importantly, huge thanks to all others it would be illusory to try thanking individually, whether you contributed to KDE, its dependencies, or otherwise contributed to the experience of KDE users, and whether or not your involvement went through difficult periods or not. No matter our actions and their results, no matter if you have been praised or flamed, our ultimate goal is noble. I have been using Microsoft Windows on a top quality PC for about a year now, and there still isn't a week that goes by without regret for a reliable, well-integrated (and hopefully free) desktop operating system.
The extent of my ability to experiment with and enhance KDE products (and related software) only came thanks to a lifetime of extreme luck. But I can't really discourage others from embarking on a similar journey at this point. I can't say I really regret mine. It was an incredible challenge - both by its difficulty and for the learning opportunity it provided. These utopia surely helped me choose my career path.
Modesty, Family and Company
A huge thank you to all of my friends, who tolerated my lower availability (and at times energy) during all this time.
Finally, I must thank relatives. My uncles Dave and Steeves Gourgues, who introduced me to electrical computers, especially Steeves, for giving my family its first computer, for introducing me to science and technology, and to the world of computer development.
And most importantly, the 2 closest, who know nothing about the kernel, but who knew so well how to prepare me to that journey - even if involuntarily. For my first PC-s and your incredible material support, but most importantly, for sharing your rigor, leadership, work ethics, your standards, diplomacy and many more skills, and−above all−your ambition and faith in mankind, thank you so much, Johanne Gourgues and Charles Cloutier.
All the honor is yours
Updates
This story was published in 2021. The next year, its dekorated krusader was elected to the KDE e.V. board. Following a vote with 4 candidates for 2 seats, Nathaniel Graham joined the five-member board, for a term of 3 years.
R.I.P., KDE
2024
More than 5 years after I gave up on it, KDE is finally declaring Kopete as unmaintained. The end result is unsurprising given how poor the IM ecosystem has become, but it is nevertheless disappointing to see it took over 2 years after its latest release, and that the status is still not reflected on Kopete's home page.