The Awful Dilemma

I like fixing bugs… It makes people happy who have their bugs fixed, it makes Krita better, and it can be done in relatively small time laps. And it gives one a sense of having been usefully productive to go to the weekly bug summary, and see oneself in the top-five of bug resolvers. Not that I’m there right now, though I was last week, because sometimes one has to dig deeper.

These weeks I’m working on refactoring Krita’s resource systems. Resource in graphics app parlance are things like brushes, gradients, patterns — mostly small files that are stored somewhere on disk and that are loaded on start up. This code dates back to 2000 or so and was originally designed for a world where people would have a few dozen of each resource installed, and where brushes and patterns wouldn’t be bigger than 64 x 64 pixels.

These days, people want to have libraries containing hundreds of resources, and many are huge, like 5000×5000 pixel images. Krita cannot simply load all of that in memory like we’re doing now. It takes too much memory. It takes too much start-up time. It makes organizing resources too hard for the user. Because it uses the ancient KDE system for finding resources in the installation, local installation and local user folder in a tiered system, some resources cannot be edited, like with kxmlgui customization files, any application update will spell disaster.

The whole system will have to be scrapped. We’ll have to have a buffer between the actual resources on disk and the application — a caching database. I kinda feel like I’m jumping down an akonadi-type rabbit hole!

And then there’s tagging and organizing and all the bugs that 18 years of accretion have both fixed, added and papered over. The codebase is the most amazing mix of simple-minded, fiendishly over-complicated and sometimes downright mis-guided patterns and anti-patterns.

So, I’m coding, for the first time since the export filter warning project a couple of years ago, lots and lots and lots of new code. It’s fun! It’ll take at least two months of solid work, probably more, especially since most of it is actual research…

Still, going so deep and losing oneself in the high of concentrated coding means that bug fixing falls by the wayside — even though the result should end with scores of bugs closed — that I feel pangs of guilt. I know that this or that thing is broken, and my fingers itch! But I find it impossible to really carry all that’s needed for this refactoring in my head, and dig into problems in other systems.

The 2016 Kickstarter

This year’s kickstarter fundraising campaign for Krita was more nerve-wracking than the previous two editions. Although we ended up 135% funded, we were almost afraid we wouldn’t make it, around the middle. Maybe only the release of Krita 3.0 turned the campaign around. Here’s my chaotic and off-the-cuff analysis of this campaign.

Campaign setup

We were ambitious this year and once again decided upon two big goals: text and vector, because we felt both are real pain points in Krita that really need to be addressed. I think now that we probably should have made both into super-stretch goals one level above the 10,000 euro Python stretch goal and let our community decide.

Then we could have made the base level one stretch goal of 15,000 euros, and we’d have been “funded” on the second day and made the Kickstarter expectation that a succesful campaign is funded immediately. Then we could have opened the paypal pledges really early into the campaign and advertise the option properly.

We also hadn’t thought through some stretch goals in sufficient depth, so sometimes we weren’t totally sure ourselves what we’re offering people. This contrasts with last year, where the stretch goals were precisely defined. (But during development became gold-plated — a 1500 stretch goal should be two weeks of work, which sometimes became four or six weeks.)

We did have a good story, though, which is the central part of any fundraiser. Without a good story that can be summarized in one sentence, you’ll get nowhere. And text and vector have been painful for our users for years now, so that part was fine.

We’re also really well-oiled when it comes to preparation: Irina, me and Wolthera sat together for a couple of weekends to first select the goals, then figure out the reward levels and possible rewards, and then to write the story and other text. We have lists of people to approach, lists of things that need to be written in time to have them translated into Russian and Japanese — that’s all pretty well oiled.

Not that our list of rewards was perfect, so we had to do some in-campaign additions, and we made at least one mistake: we added a 25 euro level when the existing 25 euros rewards had sold out. But the existing rewards re-used overstock from last year, and for the new level we have to have new goodies made. And that means our cost for those rewards is higher than we thought. Not high enough that those 25 euros pledges don’t help towards development, but it’s still a mistake.

Our video was very good this year: about half of the plays were watched to the end, which is an amazing score!

Kickstarter is becoming a tired formula

Already after two days, people were saying on the various social media sites that we wouldn’t make it. The impression with Kickstarter these days is that if you’re not 100% funded in one or two days, you’re a failure. Kickstarter has also become that site where you go for games, gadgets and gags.

We also noticed less engagement: fewer messages and comments on the kickstarter site itself. That could have been a function of a less attractive campaign, of course.

That Kickstarter still hasn’t got a deal with Paypal is incredible. And Kickstarter’s campaign tools are unbelievably primitive: from story editor to update editor (both share the same wysiwyg editor which is stupidly limited, and you can only edit updates for 30 minutes) to the survey tools, which don’t allow copy and paste between reward levels or any free text except in the intro. Basically, Kickstarter isn’t spending any money on its platform any more, and it shows.

It is next to impossible to get news coverage for a fundraising campaign

You’d think that “independent free software project funds full-time development through community, not commercial, support” would make a great story, especially when the funding is a success and the results are visible for everyone. You’d think that especially the free software oriented media would be interested in a story like this. But, with some exceptions, no.

Last year, I was told by a journalist reporting on free and open source software that there are too many fundraising campaigns to cover. He didn’t want to drown his readers in them, and it would be unethical to ignore some and cover others.

But are there so many fundraisers for free software? I don’t know, since none get into the news. I know about a few, mostly in the graphics software category — synfig, blender, Jehan’s campaign for Zemarmot, the campaign by the Software Freedom Conversancy, KDE’s Randa campaign. But that’s really just a handful.

I think that the free and open source news media are doing their readers a disservice by not covering campaigns like ours; and they are doing the ecosystem a disservice. Healthy, independent projects that provide software in important categories, like Krita, are essential for free software to prosper.


Without the release, we might not have made it. But doing a Kickstarter is exhausting: it’s only a month, but feels like two or three. Doing a release and a Kickstarter is double exhausting. We did raise Krita’s profile and userbase to a whole other level, though! (Which also translates into a flood of bug reports, and bugzilla basically has become unmanageable for us: we need more triagers and testers, badly!)

Right now, I’d like to take a few days off, and Dmitry smartly is taking a few days off, but there’s still so much on my backlog that it’s not going to happen.

I also had a day job for three days a week during the campaign, during which I wasn’t available for social media work or promo, and I really felt that to be a problem. But I need that job to fund my own work on Krita…


Kickstarter lets one know where the backers are coming from. Kickstarter itself is a source of backers: about 4500 euros came from Kickstarter itself. Next up is Reddit with 3000 euros, twitter with 1700, facebook 1400, 1000 and blendernation with 900. After that, the long tail starts. So, in the absence of news coverage, social media is really important and the Blender community is once again proven to be much bigger than most people in the free software community realize.


The campaign was a success, and the result pretty much the right size, I think. If we had double the result, we would have had to find another freelancer to work on Krita full-time. I’m not sure we’re ready for that yet. We’ve also innovated this year, by deciding to offer artists in our communities commissions to create art for the rewards. That’s something we’ll be setting in motion soon.

Another innovation is that we decided to produce an art book with work by Krita artists. Calls for submissions will go out soon! That book will also go into the shop, and it’s kind of an exercise for the other thing we want to do this year: publish a proper Pepper and Carrot book.

If sales from books will help fund development further, we might skip one year of Kickstarter-like fund raising, in the hope that a new platform will spring up that will offer a fresh way of doing fund raising.

Krita on OS X

Ever since our first kickstarter in 2014, we’ve been building every release of Krita for OSX. The initial work to make that possible took two weeks of full-time hacking. We did the work because Krita on OSX was a stretch goal and we wanted to show that it was possible to bring Krita to OSX, not because we thought two weeks would be enough to create a polished port. After all, the port to Windows took the best part of a year. We didn’t make the stretch goal, and the port to OSX got stuck.

And that shows. We build Krita on a mid-2011 Mac Mini that runs Mavericks. That has a couple of consequences: Krita doesn’t run well on anything but Mavericks, and the hack-build-test cycle takes about half an hour. That means that fixing bugs is nigh on impossible. Some things have been broken since the start, like OpenGL, other things broke along the way, like proper tablet support, loading and saving jpeg files. And more. Still, though we didn’t make the stretch goal, the demand for Krita on OSX is there: we’re getting about half a dozen queries a week about Krita on OSX. So, what should be the next steps?

Step one: define the goals. That’s easy. Krita on OSX should run on all versions of OSX that are supported by Qt5, be a good citizen, that is, come as an app bundle in a disk image, save settings to the usual locations, use the regular temporary file location and provide the same feature set and performance as on Windows and Linux. (Which might be difficult because of problems with Apple’s OpenGL implementation: Apple wants developers to use their platform-specific alternative.)

Step two: estimate the effort needed. With the Qt5/Kf5 port of Krita, estimation is more difficult because only now people are creating the first Kf5-based applications on OSX, and are running into new and interesting problems. Things like finding resources in standard locations: for Krita 2.x, we had to hack KDE’s standard paths implementation quite severely. The main issues are: OpenGL, tablet support, standard paths, bundle creation, platform integration and optimization.

My best effort estimation is three to four months of nearly full-time work. That’s similar to the Qt5 port, and comes to about 12,000 to 16,000 euros. Add in a decently fast Mac, and we’re looking at, roughly, an investment for 15,000 to 19,000 euros. Add a bit for unexpected events, and let’s say, 20,000 euros. A lot of money, but actually quite cheap for a development effort of this kind. It’s more than the Krita Foundation has availabe, though…

There is a secondary consideration, borne from experience with the Kf5/Qt5 port: if it will take three months of development time, then that development time is not spent on other things, like bug fixes or kickstarter features. That will have an immediate impact on the project! The port has already made the bug list grow horribly long, because work on the port meant less work on bug fixes.

If we decide to it, step three then must be: do it… There are a couple of possibilities.

The first: run a kickstarter campaign to get the money. Wolthera and I actually started setting one up. But we’re just not sure whether a kickstarter campaign is going to succeed, and to fail would be really bad. It would reflect badly on Krita as a wider project and might jeopardize the 2016 kickstarter campaign to fund the next round of feature improvements. It might even cannibalize the 2016 campaign. We’re not sure how likely that is, though, because we’re not sure the campaigns would be targetting the same user group. Right now, our campaigns are supported in equal parts by free software enthousiasts and by artists. We’re not reaching the OSX community, because Krita isn’t ready on OSX, but conversely, we don’t know how to reach the OSX community. We don’t even know whether the OSX community can be involved enough to reach a funding level of at least 15,000 euros.

That makes starting a kickstarter campaign (which is in itself two months of full-time work) a really dicey proposition. Even cutting the goal up into tranches of 5000 euros for the basic port (and a new Mac) and then stretch goals of 2500 euros seemed chancy to us. Plus, if we get stuck at 5000 euros there really is not enough money to do a decent port.

The second possibility: fund it out of pocket, and try to get the investment back. That could be done by making Krita for OSX exclusively available on Steam, or by a possible increase in donations because we can now reach the OSX user community. The first option could be scotched by someone taking our work and making Krita available gratis on OSX. That would be totally OK of course: Krita is free and open source. Nothing says we have to give our binaries aways, but on the other hand, nothing can stop anyone else from giving our binaries away. Or making their own, once the hard work is done. The second possibility, increased donations, is a kind of gamble. It might work out, or it might not…

The third possibility: fund the development out of pocket, but take a longer period to work on it. Get a Mac and devote, say, two weeks of initial work, and then invest a day a week to OSX. Slice up the week. A bit like I’m now doing four days a week of paid non-krita development to fill up my empty bank account, one day a week of porting and one day a week of stable-version bug fixing.

The final possibility is to do nothing. Maybe a capable OSX-loving developer will come around and start doing the work out of love for Krita. But I’m not sanguine about that happening, since we’ve seen four or five people trying to build Krita on OSX, and all but two failed. The first attempt was using MacPorts, which doesn’t lead to an installable app bundle, and the second attempt was the one done for the 2014 Kickstarter.

Which brings us full-circle to the question: what now?

Qt World Summit 2015

I hadn’t been able to attend the Qt Dev Days since the old Nokia days… My last one was when they handed out the blue N9’s. KDE, as a sponsor/partner for the Qt World Summit, had access to a number of passes, and was going to have a booth, and I applied for one. I like doing booth duty and I think I’m fairly good at getting people to listen to our spiel. Here’s a report from the trenches!

Monday is training day, and the KDE team didn’t have passes for trainings. Besides, it probably was more instructive to sit in the hack room and hack anyway. With about ten KDE hackers around, the room was full and stuffy, but on the other hand, it was like a mini sprint. At the end of the day, I had the kxmlgui framework in a state where I could use it again for Krita without needing to fork it.

Very gratifying was the recognition KDE got on Tuesday, during the intro talk and the keynote by Lars Knoll. We know we’re doing a good job stress-testing Qt, and a good job as a community helping Qt develop and grow, and it was good to see that recognized.

Not so awesome was the need another keynote speaker felt to connect to his public by making a little “I won’t tell my wife” joke. Not terribly seriously over the edge, perhaps, but unpleasant nonetheless. When can we have a tech conference where speakers don’t assume that their public are heterosexual, white, middle-aged married men? I happen to be one of them, of course…

I didn’t attend many presentations. Of the talks I attended, both Guisseppe D’Angelo’s “Integrating OpenGL with Qt Quick 2” and Olivier Goffart’s “Using namespace std:” stood out because the presentation was clear, the information went deep so I could learn something new. Olivier’s way of engaging with the public worked really well.

The real meat of the QtWS was working the booth, though. We had a good presentation: nice blue table cloth, two good posters (need to have OS logo’s next year, most people thought KDE was Linux-only), a presentation running on a big screen and videos (Plasma Phone, Calligra Gemini, Krita) running in a loop on a nice convertible Windows 8 laptop, together with some software, like Krita Gemini and Marble to show people that KDE’s Frameworks are a truly tested technology you can use to create serious real-world technology. Here’s a picture Dan took:

That was a story that worked: almost everyone whom I asked “do you know KDE” answered with “Yes, I even used to use it”. So I’d go on explaining that KDE is more than the desktop they used to use, but that there’s this set of frameworks, full of tried, tested and reliable technology. Some examples later, I’d point them at the inqlude website. KDE really doesn’t have a website that ‘sells’ Frameworks, which is a problem. Inqlude worked, though. I could also help reassure some people that doing a new desktop application with QWidgets wasn’t a choice for a dead technology, also by showing off Krita Gemini: QWidgets and QML in the same application, with a seamless switch. All in all, we reached a fair number of interested people and we had a story that appealed and got through.

Wednesday evening, my feet ached and the arm that I had broken just before aKademy was very painful as well, but I was pretty satisfied. Plus, I had a stack of Kiki postcards, and pretty much everyone whom I handed one smiled, no matter how tired they were!

One cannot visit Berlin and skip seeing one of the museums. That’s my story, and I stick to it. This time, I went to the Gemäldegalerie. Usually, I visit the Bode Museum, which has some incredible sculpture. The Gemäldegalerie was showing a special exhibition around Adobe’s famous Illustrator splash screen’s painter. The exhibition was a tad disappointing though.

Botticelli’s work was shown together with 19th and 20th century works inspired by him. Some of those works were really interesting, some were boring. Warhol’s Venus on an Amiga 1000 is much less interesting than the Amiga 1000 itself. Other works were more interesting, like Antonio Donghi or Evelyn de Morgan. But that’s fine: not everything needs to be riveting. More of a problem was the presentation of Botticelli’s works themselves: a
boring, long row of paintings grouped by subject. As if the exhibition designer was fresh out of inspiration. The central room with the sole two works signed by Botticelli was flooded in a red light that made it impossible to see anything.

Anyway, after the exhibition followed a four kilometer walk through the galleries, with so many great paintings that a certain visual indigestion was inevitable. But I’ll go again, and perhaps again. This might be my favorite for now, with the red-haired girl helping her grandmother, and the dancing pair:


Why aren’t you using github?

Is a question we, Krita developers, get asked a lot. As in, many times a week. Some people are confused enough that they think that github is somehow the “official” place to put git repositories — more official than,, or wherever else. Github, after all, is so much more convenient: you only need a github account or login with your social media account. It’s so much more social, it’s so cosy, and no worries about licensing either! So refreshing and modern.

So much better than, say, SourceForge ever was! Evil SourceForge, having failed to make a business out of hosting commercial software development projects is now descending to wrapping existing free software Windows         installers in malware-distributing, ad-laden installer wrappers.

The thing is, though, Github might be the cool place to hack on code these days, the favourite place to host your projects: that is exactly what SourceForge was, too, back in the days. And Github’s business model is exactly what SourceForge’s was. And if that isn’t a warning against giving your first-born children in the hands of a big, faceless, profit-oriented, venture-capital-backed company, then I don’t know what is!

And yes, I have heard the arguments. Github is so familiar, so convenient, you can always remove your project (until Github decides to resurrect it, of course), it’s git, so you’re not losing your code revision history! But what about other artefacts: wiki, documents, bugs, tasks? Maybe you can export them now, I haven’t checked, but what will you import it into?

I’ve spent over ten years of my life on Krita. I care about Krita. I don’t want to run that sort of risk. One thing I’ve learned in the course of a mis-spent professional life is that you always should keep the core of your business in your own hands. You shouldn’t outsource that!

So, one big reason for not moving Krita’s development to github is that I simply do not trust them.

That’s a negative reason, but there are also positive reasons. And they all have to do with KDE.

I know that a lot of people like to bitch about KDE — they like to bitch about the layout of the forum, the performance of the repo browser, the size of the libraries, the releases of new versions of the Plasma Desktop, about fifteen year old conflicts with the FSF (which somehow proves to them that KDE isn’t trustworthy…) The fact is that especially in the Linux world, a bunch of people decided ages ago they didn’t like KDE, it wasn’t their tribe and they apparently find it enjoyable to kick like a mule everytime we do something.

Well, shucks to them.

Then there are people for whom the free software world is a strange place. You don’t see something like Corel Painter being hosted together with a bunch of other software on a bigger entity’s website. It’s confusing! But it’s still strange, to many people, to see that Krita shares a bug tracker, a forum, a mailing list platform, a git repository platform with a bunch of other projects that they aren’t interested in.

Well, I see that as a learning moment. And not as a hint that we should separate out and… Start using using github? Which would also mean sharing infra with a bunch of other projects, but without any sense of community?

Because that is what make KDE valuable for Krita: the community. KDE is a  big community of people who are making free software for end users. All kinds of free software, a wild variety. But KDE as a community is extremely open. Anyone can get a KDE identity, and it doesn’t take a lot of effort to actually get commit access to all the source code, to all projects. Once in,
you can work on everything. All the pieces needed to develop software are here: websites, forums, wikis, bug trackers, repo hosting, mailing lists, continuous-integration, file hosting, todo management, calendaring, collaborative editing, file hosting. The system admin team does an incredible job keeping it all up and running, and the best thing is: we own it. We, the community, own our platforms and our data. We cannot be forced by a venture capitalist to monetize our projects by adding malware installers. We own our stuff, which means we can trust our stuff.

And we can improve our platform: try to improve a closed-source, company-owned platform like github! So suggestions for improvement are welcome: we’re now looking into phabricator, which is a very nice platform giving a lot of the advantages of github (but with some weird limitations: it very clearly wasn’t made for hosting hundreds of git repos and hundreds of projects!), we’re looking into question-and-answers websites. Recently, the continuous integration system got improved a whole bunch. All awesome developments!

But moving development to github? Bad idea.

Cross Platformity

Cross Platformity

Several years ago we started porting Calligra to Windows. Supported by NLNet. Some time later, Intel also supported KO to create two Windows versions of Krita, one for tablets, one for convertible ultrabooks and later still, a new version of Calligra Words, Stage and Sheets for convertible ultrabooks. Meanwhile, the Krita Foundation has been publishing Krita on Windows and OSX for some time now. That’s a fair amount of experience in puslishing software originally written on Linux on other platforms.

Let’s take a look at the starting position.

Calligra, or rather KOffice, as it was called when it started out, was created to be a native KDE application. Integrated with the KDE desktop environment, using all the features that KDE offers, ranging from inter-process communication to system-tray notifications, shared plugin loading, mimetype handling, and other resource icon locating. These applications are KDE applications through-and-through.

There are also some hidden assumptions in the way KDE works on Linux: for instance, that reading thousands of small files on startup isn’t a big deal. We Linux users are fortunate in having a choice of really good, really fast file systems, compared to Windows or OSX users.

So, on Linux, it’s not that big a deal if people aren’t running the KDE Plasma Desktop, since installing the libraries, the icons, maybe some system settings kcms will mean Krita will run just as well in Gnome as in KDE. It’s a pity that some distributions don’t make Krita depend on the oxygen icon set, and that others think that installing Krita means users need marble, but that’s the way Linux packaging works, or doesn’t work.

Now, there are two reasons for bringing a Linux application to another platform, two ways of going about it and two ways of implementing the port.

You can port an application to Windows or OSX because you want to use it yourself, as a Linux user in exile, or you can port an application to Windows because you want to gain a user-base on Windows.

And you can port an application to Windows or OSX by bringing the whole Linux and KDE environment with you, or by making the application as native as possible.

And finally, you can build on the target platform, with the target platform’s native compilers, or you can cross-compile from Linux.

If you’re porting for Linux exiles, the first approach is fine. It’s what on Windows is done by cygwin, msys, KDE’s emerge tool or KDE’s windows installer. It’s what FINK or MacPorts provide on OSX: a package manager, all the tools you’re used to, all the platform services the application depends on. It’s a big undertaking to maintain ports of so many components, and the porting system will often have temporary failures. I’m not saying that it’s wasted work: I use KDE’s windows installer to get Kate on Windows myself.

But it’s not going to work when you want to build a user base for your application on Windows or OSX. The package managers, the installers are too complicated, too alien and drag in too many unfamiliar things. Even using something as Emerge to build, and then package up the built bits into an installer is problematical, because those bits will still expect the full KDE environment to be available.

And a Windows user is going to freak out when starting an application starts daemons that keep running. No kded, therefore. Their “protection” software (snake oil, but scary snake oil) will yammer when there’s weird inter-process network communication. Bye-bye dbus. For a single application like Krita, a mimetype database is overkill. Loading icons by the hundred-weight, individually gives a bad hit on startup time. And yes, we’re getting nastygrams about the number of files we package with Krita versus the number of files Photoshop packs.

It’s really clear to keep in mind what the goal is. Because if you’re working together with someone else, and they’re of the linuxer-in-exile persuasion, and you’re of the native-user persuasion, conflicts will happen all the time. The first crowd won’t mind using glib in update-mime-database because, what’s the problem? While you’ll hate that requirement because building glib on windows and osx ain’t easy, and it’s a big dependency with a lot of other dependencies that come with it, and all just to be able to figure out that a .jpg file is a jpeg file.

Most ‘native’ Windows applications that use 3rd party libraries includes those libraries in their own source tree, either as dll’s or as source code. It’s easy, you never have to deal with newer versions of libraries breaking your code, you can build everything in one go. For some libraries, it’s even the only way: you cannot build the breakpad library outside the source tree of the application that uses it. But for a cross-platform application that also targets Linux distributions, this cannot be done. You cannot include all dependencies in your source tree.

So, we need to find a way to build all dependencies without dragging in a fake Linux or fake KDE environment. Without dragging in a package manager. One that creates applications that behave as natively as possible.

What we’re currently trying to do is this: build a cmake system that builds Krita’s dependencies and then builds krita. CMake’s external project system works pretty well for this. It’s not as complicated as the Emerge system, though there are similarities, and we’re even re-using patches from Emerge for our dependencies.

Here’s the list of all dependencies we currently build:

  • automoc: needed for kdelibs-stripped
  • boost: needed for Krita
  • bzip2: needed for kdelibs-stripped
  • eigen3: needed for Krita
  • exiv2: needed for kdelibs-stripped and Krita
  • expat: needed for exiv2
  • ffi: needed for glib (only on OSX)
  • gettext: needed for glib (only on OSX)
  • giflib: needed for kdelibs-stripped and qt
  • glew: needed for Krita
  • glib: needed for shared_mime_info (only on OSX)
  • gsl: needed for Krita
  • iconv: needed for gettext and exiv2
  • ilmbase: needed for openexr
  • intltool: for glib (only on OSX)
  • jpeg: needed for kdelibs-stripped, qt and krita
  • kdelibs-stripped: specially hacked up version of kdelibs4 that doesn’t need openssl, dbus and a whole lot of other things.
  • lcms2: needed for krita
  • libxml2: needed for kdelibs-stripped
  • libxslt2: needed for kdelibs-stripped
  • opencolorio: needed for krita, has it’s own 3rd party external projects: tinyxml, yaml
  • openexr: needed for Krita
  • patch: needed on windows only, creates a myptch.exe because patch.exe is banned on Windows…
  • pcre: needed for shared-mime-info
  • perl: needed on Windows to build Qt
  • pkgconfig: needed on OSX to build glib
  • png: needed for Krita and Qt
  • qt: we need to build this ourselves to strip out openssl, qtscript, the database stuff and more, and because we build with a version of Visual C++ that Qt4 doesn’t support out of the box
  • shared_mime_info: needed for kdelibs-stripped
  • tiff: needed for Qt and Krita
  • vc: needed for Krita
  • krita: what we finally want…

And this is what’s still missing:

  • kdcraw: would provide camera RAW import
  • poppler: would provide PDF import and export
  • openjpeg: would provide jpeg2000 import and export.

All this is described here for OSX and here for Windows. My goal is to make a CMake based project that can build everything on OSX and Windows, and on Linux, for Windows in one go. It needs much more work, in fact more time than I actually have… Anything that can slim the number of dependencies would be very welcome!

And now it’s coming full-circle: I actually would like to have installers for Krita that work on Linux, too. Just like Blender or Qt Creator have, a 32 and 64 bits installer that people can download, run and get the latest build of Krita, without weird extra dependencies, without waiting for distributions to pick up the next version of Krita. The system we’re building should be able to provide that…

Evolving KDE

Paul and Lydia have blogged about how KDE should and could evolve. KDE as a whole is a big, diverse, sprawling thing. It’s a house of many rooms, built on the idea that free software is important. By many, KDE is still seen as being in competition with Gnome, but Gnome still focuses on creating a desktop environment with supporting applications.

KDE has a desktop project, and has projects for supporting applications, but also projects for education, projects for providing useful libraries to other applications and projects to provide tools for creative professionals and much, much more. For over a decade, as we’ve tried to provide an alternative to proprietary systems and applications, KDE has grown and grown. I wouldn’t be able, anymore, to characterize KDE in any sort of unified way. Well, maybe “like Apache, but for end-users, not developers.”

So I can only really speak about my own project and how it has evolved. Krita, unlike a project like Blender, started out to provide a free software alternative to a proprietary solution that was integrated with the KDE desktop and meant to be used by people for whom having free software was the most important thing. Blender started out to become the tool of choice for professionals, no matter what, and was open sourced later on. It’s an important distinction.

Krita’s evolution has gone from being a weaker, but free-as-in-freedom alternative to a proprietary application to an application that aspires to be the tool of choice, even for people who don’t give a fig about free software. Even for people who feel that free software must be inferior because it’s free software. When one artist says to another at, for instance, Spectrum “What, you’re not using Krita? You’re crazy!”, we’ll have succeeded.

That is a much harder goal than we originally had, because our audience ceases to be in the same subculture that we are. They are no longer forgiving because they’re free software enthusiasts and we’re free software enthusiasts who try really hard, they’re not even much forgiving because they get the tool gratis.

But when the question is: what should a KDE project evolve into, my answer would always be: stop being a free software alternative, start becoming a competitor, no matter what, no matter where. For the hard of reading: that doesn’t mean that a KDE project should stop being free-as-in-freedom software, it means that we should aim really high. Users should select a KDE application over others because it gives a better experience, makes them more productive, makes them feel smart for having chosen the obviously superior solution.

And that’s where the blog Paul linked to comes in. We will need a change in mentality if we want to become a provider of the software-of-choice in the categories where we compete.

It means getting rid of the “you got it for free, if you don’t like it, fuck off or send a patch” mentality. We’d all love to believe that nobody thinks like that anymore in KDE, but that’s not true.

I know, because that’s something I experienced in the reactions to my previous blog. One of the reactions I got a couple of times was “if you’ve got so much trouble porting, why are you porting? If Qt4 and KDE 4 work for you, why don’t you stay with it?” I was so naive, I took the question seriously.

Of course Krita needs to be ported to Qt5 and Kf5. That’s what Qt5 and Kf5 are for. If those libraries are not suitable for an application like Krita, those libraries have failed in their purpose and have no reason for existence. Just like Krita has no reason for existence if people can’t paint with it. And of course I wasn’t claiming in my blog that Qt5 and Kf5 were not suitable: I was claiming that the process of porting was made unnecessarily difficult by bad documentation, by gratuitous API changes in some places and in other places by a disregard for the amount of work a notional library or build-system ‘clean-up’ causes for complex real-world projects.

It took me days to realize that asking me “why port at all” is in essence nothing but telling me “if you don’t like it, fuck off or send a patch”. I am pretty sure that some of the people who asked me that question didn’t realize that either — but that doesn’t make it any better. It’s, in a way, worse: we’re sending fuck-off messages without realizing it!

Well, you can’t write software that users love if you tell them to fuck off when they have a problem.

If KDE wants to evolve, wants to stay relevant, wants to compete, not just with other free software projects that provide equivalents to what KDE offers, that mentality needs to go. Either we’re writing software for the fun of it, or we’re writing software that we want people to choose to use (and I’ve got another post coming up elaborating on that distinction).

And if KDE wants to be relevant in five years, just writing software for the fun of it isn’t going to cut it.

Project Activity in Bug Reports

Project Activity in Bug Reports

Sven Langkamp recently mentiond that Krita had crept up to second place in the list of projects with most new bugs opened in bugzilla in a year. So I decided play around a litte, while Krita is building.

Bugzilla has a nice little report that can show the top X projects with open bugs for certain periods. Krita never is in the default top 20, because other KDE projects always have more open bugs. But let’s take the top 100 of KDE projects with open bugs sort the data a bit and then make top 10 lists from the other columns.

Note, there might be projects where more bugs were opened and closed in the past year, but I cannot get that information without going into SQL directly. But I think most active KDE projects are in the top 100.

New bugs created. This is a pretty fair indication of userbase, actually. A project that has a lot of users will get a lot of bug reports. Some might quibble that there’s a component of code quality involved, but honestly, pretty much all code is pretty much equal. If you just use an application, you’ll mostly be fine, and if you start hacking on it, you’ll be horrified. That’s normal, it holds for all software.

  • plasmashell: 1012
  • krita: 748
  • plasma: 674
  • kwin: 482
  • digikam: 460
  • kmail2: 388
  • valgrind: 274
  • Akonadi: 270
  • kate: 267
  • kdevelop: 258

I have to admit to being a bit fuzzy about the difference between plasma and plasmashell. It looks like our own developers know how to find bugzilla without trouble, given that there are two, three developer-oriented projects in the top-ten. Of course, valgrind is also widely used outside the KDE community.

Now for bugs closed. This might say something about project activity, either development or triaging. It’s a good statistic to be in the top-ten in!

  • plasmashell: -917
  • krita: -637
  • digikam: -615
  • plasma: -479
  • kwin: -391
  • okular: -346
  • dolphin: -263
  • amarok: -255
  • valgrind: -254
  • kate: -249

Not a hugely different list, but it’s interesting to see that there are several projects that are in the top-ten for closing bugs, that aren’t in the top-ten for receiving new bugs. Maybe that is an indication of code quality? Or maybe better bug triagers? If a project is in the first list, but not in the second list, it might be taken to mean that it’s got users, but that development is lagging.

Open bugs. A project can go a long time and collect a huge amount of bugs over that period without having much activity. For instance, in this list, KMail has 880 bugs, but there were zero new bugs in 2014 and only seven bugs closed. I’d say that it’s time to remove kmail from bugzilla entirely, or mark all remaining kmail bugs as “unmaintained”. The same goes, I guess, for the kio component: 550 open bugs, 1 new, 1 closed in a year.

  • plasma: 1449
  • konqueror: 1432
  • kmail2: 1107
  • kopete: 942
  • kdelibs: 921
  • kmail: 880
  • Akonadi: 650
  • valgrind: 580
  • kio: 550
  • systemsettings: 495
  • kontact: 479

Krita has 237 open bugs, by the way, but since we’re working the 2.9 release, that number fluctuates quite a bit.

Conclusions? Well, perhaps none. If bugs are any indication of a project’s user base and activity, it’s clear that KDE’s desktop (plasma, kwin) have the biggest userbase, followed by Krita and Digikam. Maybe that comes as a surprise — I know I was surprised when Sven noted it.

And there’s one more twist — everyone who uses the Plasma shell or kwin can easily report crashes to bugzilla, because they’re on Linux. Most Krita (and I guess Digikam) users are actually not on Linux. Krita’s Windows crashes right now still get reported to a server hosted by KO, which is something I need to work on to change…

Switching between Stable, Nearly Stable and Unstable Krita — a guide for artists

The first thing to do is to open the Cat’s Guide To Building Krita, because  that’s the base for what I’m going to try to explain here. It’s what I use for developing Krita. I usually have every version from 2.4 up ready for testing.

Now — there are very good reasons why you might want to have more than one version of Krita available. Currently, the master branch is frozen, and when it opens up, it’ll be for the Qt5 port. We’re fixing bugs like crazy in the Calligra/2.9 branch, and there’s a ton of cool stuff in there, but if your livelihood depends on Krita, you might want to use 2.8 until, say, we release 2.9.1…

So, here’s how to set that up. On Linux, of course. Building Krita on Windows or OSX is a pain.

First: remove your distribution’s Krita and Calliga packages.

As per the Cat’s guide, setup your environment, but do not create the ‘inst’ dir:

mkdir -p $HOME/kde/src
mkdir -p $HOME/kde/build

Instead, we create different install directories for different versions. Let’s setup 2.8, 2.9 and git master:

mkdir -p $HOME/kde/2.8
mkdir -p $HOME/kde/2.9
mkdir -p $HOME/kde/master

Get the source code (again, check the Cat guide!):

cd ~/kde/src
git clone git://

Now, get the git-new-workdir script. Here’s a copy on my webserver. Or  check whether your distribution provides it. We’ll use it to make two new source directories out of the repository you just cloned:

cd ~/kde/src
git-new-workdir calligra 2.8
cd 2.8
git checkout calligra/2.8


cd ~/kde/src
git-new-workdir calligra 2.9
cd 2.9
git checkout calligra/2.9

Now you’ve got the source code for Calligra Master in ~/kde/src/calligra, for the 2.8 stabele version in ~/kde/src/2.8 and the 2.9 beta branch in ~/kde/src/2.9.

Get the libraries and dependencies. This wiki page has a lot of details: Calligra/Building. The Cat’s guide’s list is a bit outdated. Here’s the full list of dependencies we need for Krita:

  • KDE (minimum 4.3)
  • Qt4 (minimum 4.6)
  • Perl
  • zlib
  • libpng
  • boost and boost-system
  • openEXR
  • openGL
  • GSL
  • Eigen3
  • Exiv2
  • LCMS2
  • Vc (the 0.7 release)
  • SharedMimeInfo
  • Poppler and Poppler-Qt
  • openjpeg (optional)
  • libjpeg
  • fftw3 (optional, but will make blur much faster)
  • glew
  • openColorIO (optional, for HDR painting)
  • libtiff
  • kdcraw

And you need cmake, make and the compiler, of course.

Now you can setup your build directories. This is different from the Cat’s guide and note that you cannot move your existing build directory around:

cd ~/kde/build
mkdir master
mkdir 2.8
mkdir 2.9

Now download the ‘changeto’ script and put it somewhere where you can execute it. It’s a really simple script: all it does is move around a symlink, like this:

rm ~/kde/inst
ln -s ~/kde/2.8 ~/kde/inst

The script has a couple of commented lines you can enable to setup switching your configuration and settings, too, but I don’t use that myself. There are other ways to setup this, of course. This is simple-minded enough that it works for me… Note: the -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4 is needed on systems like Ubuntu where Qt5 is the default: check whether qmake is Qt4 or Qt5 first.

cd ~/kde/build/2.8

And build and install Krita 2.8. Then execute the changeto script:

changeto 2.9

And do what we just did for 2.9 — the same commands, but replace 2.8 with 2.9. You could do the same again for master — changeto master and build and install the master branch from the ‘calligra’ directory.

For the rest the setup is the same. If you setup your paths to point to $HOME/kde/inst and switch with changeto to the version you use, you can safely use Krita 2.8, Krita 2.9 Beta1 or git master whenever you want. You probably don’t need to ever update 2.8 again and you can keep Krita 2.9 updated as per the Cat’s guide.

Note that Krita 2.8 needs the kbuildsycoca command from the Cat’s guide, but Krita 2.9 doesn’t anymore. Everytime you switch to 2.8, execute kbuildsycoca.

If you run into trouble, join us on irc and ping me — but keep in mind that I am in Europe and enjoy my eight hours sleep every night.

Ten years of working on Krita

October 2003… I had just gotten my first graphics tablet, a small Wacom Graphire, because I needed to draw a map for the novel I was working on, a map of a battlefield. It seemed a good idea, back then, to do that digitally, for ease of adding and removing layers and so on. However, I wasn’t too happy with the way GIMP worked back then, not realizing it was because I wasn’t familiar with digital painting at all, not because GIMP’s workflow was bad or something like that.

So I started looking for alternatives, and I came across Krita. Krita had gotten its start in 1998, when Matthias Ettrich held a presentation at the 1998 Linux Kongress, which was reported by Michael Wiedman. One of the things he wanted to demo was the ease with which it was possible to hack a Qt gui around an existing application, and the application he choose to demo it with was GIMP (back then it was still called The Gimp, I think). About 1100 lines of code hacked together one evening before the congress started that integrated GIMP into KDE by giving it a KDE compliant user interface: toolbars, statusbar, menubar and made it use the KDE standard dialogs. His goal was to show that there was no reason for any duplication of effort, if a complex application like GIMP can be integrated into KDE with so little effort. KDE was two years old by then and Gnome had just started and the mood was incendiary, so the patch, named kimp, caused a something of a flamefest which left a sour taste in everybody’s mouth.

Not satisfied with this situation, people within the KDE project decided to start their own image editor application (although there was some dissension). At that time, there was an application in KOffice called KImage which had been started by Michael Koch, who came up with the name KImageShop, so this can be seen as the earliest forerunner of Krita, was originally written in Qt 1.x, but had been ported to Qt 2.0 in March 1999. The codebase would later be ported to Qt3 and to Qt4!

At the 31st of May, 1999, the KImageShop project officially kicked off with a mail by Matthias Koch. Involved were also Matthias Elter and Daniel Duley (mosfet). Their plans were certainly ambitious! The basic idea back then was to make KImageShop a GUI shell around ImageMagick. (And indeed, until 2004 ImageMagick was a core dependency of Krita.) It was going to be a corba-based application with out-of-process filter plugins, compatible with GIMP plugins, which are also out-of-process, though of course not corba-based. Multiple colorspace support was planned from the outset, though it took until the Krita 1.5 release in 2006 for the project to achieve that goal. ( went through a reorganization in 2009, killing all old content, so this is a link to the svn version of the original announcement.) Some things planned back then still haven’t been realized, such as export support for GIMP’s xcf file format. Even distributed and multi threaded image filter application was already mentioned!

After an initial spurt of development, the mailing list soon became quiet. The main reason seems to have been that Matthias Elter, Carsten Pfeiffer and the other authors were busy getting KDE 2.0 ready and done. KImageShop started to bitrot and it became hard to compile.

In October 2000, John Califf became the new maintainer. He started with an enormous enthusiasm and energy and quickly make KimageShop at least compilable. During his tenure, KImageShop was renamed to Krayon, a name half-jokingly thought up by Sean Pecor. As he (and others) expected, the new name would give problems, but it seemed stick around after Bart Syszka liked it too. During this short period,, led by Shawn Gordon, was active as well — they had hired someone to work full-time on KImageShop / Krayon. But John Califf’s 54th and last commit was February 12th, 2001, and nothing much happened after that for over a year.

In June 2002, Patrick Julien appeared on the scene. By then, Krayon had been disabled from compilation for legal reasons: a German lawyer thought “Krayon” too close to the name of a German website ( which used to sell a series of graphics cd’s. seems to have become a “lizensberater” since then, and von Gravenreuth is no more.

But back then, the first thing that had to be done was to find a new name. The discussion was long, and in the end Krita was chosen. Looking back, it seems to have been an excellent choice. We never had any legal problems since (touch wood!), and after a few years patience, the domain became available as well!

New maintainer Patrick Julien embarked upon a refactoring of Krita following the Gang of Four’s Design Patterns lead.

And that was more or less the state when I started looking for something to draw maps with, using my little Graphire… The project had stagnated again by then, after the promising refactoring had basically set down the broad architectural lines Krita is still based on.

I didn’t know C++ back then, but neither was I a novice programmer. I’d been earning the daily bread for me and my family for about ten years, first as an Oracle PL/SQL developer, then Visual Basic, then Java. I had written and gotten published a book on Python and Qt, so I knew Qt as well. I had no experience with graphics, though…

In October 2003 it was not possible to paint with Krita: all tools except for the layer move tool had been disabled. The paint tool was the first thing I worked on, and I was very proud when I had a tool that could place squares on the canvas — and the size of the squares was sensitive to the tablet pressure!

And then the ball started rolling again… In 2004, I Patrick Julien handed over maintainership. Many of the people who are still working on Krita were already around by then, and by September 2004 we were ready for the first preview release of Krita! The backend had been rewritten once more (and that would happen at least two, three times again), we had working tools, plugins, filters, color models, wacom support… Get the (apparently incomplete) source code!

Then 2005 arrived, and we were driving ourselves really hard to make the KOffice 1.4 release. Originally planned for the first quarter of 2005, it actually got delayed until June. We had a great feature list (for a brand-new application):

  • Layers (without fixed boundaries).
  • A familiar set of tools — brushes, selection tools and shape tools.
  • Painting with filters.
  • An extensible system for the addition of new color and paint models.
  • Support for pressure sensitive tablets.
  • The ability to read most graphics file formats, including gimp and photoshop files.
  • Exporting to many graphics file formats (but not gimp or photoshop)
  • A complete colour management system based on lcms.
  • A useful set of filters (implemented as plugins, so the set of filters is extensible) including a CImg based image restoration plugin.
  • The ability to use Gimp palettes, brushes, patterns and gradients

Real artists ship, and we had shipped! Champagne was being served, and then compilers were fired up again, because after 1.4, a 1.5 has to follow. We had a sprint at my place in Deventer. That was also around the time I discovered IRC… 24/7 presence is taking its toll these days.

A bit less than a year later, we were still hard at it, and Krita had gained adjustment layers, scripting, 16 bit/channel support, CMYK, an OpenGL canvas… And we released it with KOffice 1.5 in April.

In 2006, we were old hands at hacking and releasing and hacking and releasing. But things were changing. Google’s Summer of Code program arrived, and we had our first students working on Krita and KOffice. We released 1.6, and Krita 1.6 was really a very nice, stable image editor. The first professional users started taking a look at Krita, but still found it wanting. And the long-awaited port to Qt4 got started. Oh… And Krita got the Akademy Award for Best Application!

But that really was the beginning of a time of troubles. Looking back, I’m surprised we never gave up. I had to give up, personally, for a bit of time, when I got burned out, not really because of the hacking and porting, because that was still fun, but tensions in the KOffice community got steadily worse, something that would end with the KOffice/Calligra community split in 2010.

And another problem was that we simply couldn’t figure out how regain stability. The KDE 4 platform was unstable, Qt4 wasn’t exactly as good as it should have been — and we made KOffice go through a huge redesign, where much of what we had learned in Krita about canvases, tools, plugins and more was placed in the core of Calligra, in the flake library. in retrospect, we ported too quickly, and we changed too much, and we got stuck.

So, 2007 and 2008 went past, without a release. It took three years to get to the Krita 2.0 release in May 2009, and that while that release was a huge milestone, it was also completely unusable. None of the KOffice applications had anything like the stability or plain usefulness of the 1.6 release. Looking back, it’s a wonder the project didn’t die. Of course, we still had fun coding, there were Google Summer of Code students, there were Libre Graphics Meetings (the first I attended was the 2007 in Montreal, also the first time I crossed the Atlantic!).

But it was clear that something had to be done. And in December 2009, we all had enough. We had released Krita 2.1 in November, and while we felt we’d made progress and proudly claimed “This release marks the beginning of the user-readiness of the 2.x series of Krita.”, it wasn’t really. We did have our own website, now, though! And the all-new KDE web forums!

It was during a KOffice sprint in the Trolltech offices in Oslo, that Lukáš Tvrdý, a former Summer of Code student, presented his idea: he would have several months between finishing his thesis (about Krita brush engines!) and his graduation, and instead of seeking a job hacking up websites, he would like to try and work full-time on Krita, to get rid of all the pesky bugs, performance issues, all the papercuts, sock-wrinkles and plain-out filthy bugginess. But he needed money to buy bread and pay for his apartment… So the first Krita sponsored development drive was born. Crowd-sourcing avant-la-lettre, it brought in enough to keep Lukáš well-fed and happy hacking.

This really made a huge difference. We got in touch with David Revoy, the French artist who was back then working on Sintel for the Blender Foundation. His timelapse showing how he worked with Gimp and Mypaint on concept art really gave us a kick in the pants — he should have been using Krita!

But we were honest enough to know that he could not have used Krita. So, armed with his suggestions, we went back to work. We had a goal — “make Deevad happy with Krita”, we had received the sponsorship needed for Lukáš, and we were really motivated. Krita was fun again!

We kept on releasing, though: 2.1 was released in November 2009, 2.2 in May 2010, 2.3 in December 2010 and then… The Calligra/KOffice ruckus happened. It took a long time before the first Calligra release was made, numbered 2.4. Krita 2.4 was released in April 2012.. We’d spent all of 2011 on it, and parts of 2012. It was a long release-hiatus, but it was worth it. Krita 2.4 was ready for the end-user, we felt.

At the Krita sprint in Amsterdam in 2011, David Revoy had said of Krita 2.3 that it came close, and was a nice application for amateurs, but not ready for professionals — fun to use, but just too many rough edges, too many things that hampered workflow. Krita 2.4 fixed that. It had taken a year, since 2.3, and in fact, two and a half years since we first put “make deevad happy” as our No. 1 goal, but we’d made it. Which is not to say that we were done…

So, there’s been 2.5, 2.6, 2.7 since then. Every release makes me wonder why we thought the previous release was the bee’s knees — and every release excites me, because there’s so much new, so much fixed, so much polished.

Right now, we’ve got a Krita Foundation which owns the Krita trademark, Dmitry Kazakov will work on Krita full-time for the next four months, there’s a company giving commercial support for Krita, every month the number of users increases. We’ve ported Krita to QML for Krita Sketch and Krita Gemini… We’ve got a shop full of cool swag. And my novel still isn’t finished!

Looking back, I wonder — why did I pick Krita to work on? Probably because I didn’t like to start a new project, and besides — I probably couldn’t have pulled it off. I didn’t know anything about graphics… And Krita was in Qt, promising, but still small and needed so much basic stuff done that I knew I could get into it. Now, in 2013, Krita is over 300k lines, excluding the Calligra libraries. Newcomers have a much tougher time of it! (But don’t let that deter anyone!)

Ten years is a lot of time. In that time, I’ve bought and sold two houses, and am living now in the third. My daughters were at primary school back then, now they are first-year students at University. I went through three jobs, and am now working at a company I’ve co-founded. And I’ve always kept working on Krita…

Ten years is a long time! Here’s to the next ten years of Krita! To an awesome community of artists and developers, to great code and lots of fun, to learning and doing, to coding and painting!


Thank you, everyone, Aaron, Adam, Adam., Adriaan, Adrian, Adrian, Albert, Alberto, Alexander, Alexander, Alexis, Alfredo, Allen, Ana, Andras, Andre, Andreas, Andres, Andrew, Andrius, Andre, Andy, Anne-Marie, Ariya, Arjen, Bar, Ben, Ben, Benjamin, Benjamin, Benjamin, Benoit, Bernhard, Bo, Brad, Bram, Burkhard, Camilla, Carlo, Chinkal, Christer, Christian, Christan, Christoph, Chusslove, Clarence, Cyrille, Dan, Dan, Daniel, Daniel, Danny, David, David, Dirk, Dirk, Dmitry, Edward, Elvis, Emanuele, Enrique, Fabian, Frank, Frederik, Fredrik, Fredy, Friedrich, Gary, Geoffry, Gioele, Giovannia, Gopalakrishna, Gabor, Hanna, Harald, Hasso, Helge, Helio, Hoang, Hugo, Inge, Ingo, Jaime, Jaime, Jason, Jakob, Jakub, Jan, Jaroslaw, Jens, Jessica, Johannes, John, Jonathan, Jonathan, Jose, Jure, Kai-Uwe, Kevin, Kevin, Kurt, Laurent, Lauri, Leo, Lukas, Lukas, Maciej, Malcolm, Marc, Maria, Marijn, Martin, Matthew, Matthias, Matus, Melchior, Michael, Michael, Michael, Michael, Mohtaba, Montel, Nick, Nicolas, Olivier, Patrick, Patrick, Pavel, Peter, Pierre, Pierre, Pino, Rafael, Raphael, Rex, Rob, Roopesh, Sahil, Samuel, Sander. Sascha, Sebastian, Siddharth, Silvio, Silvio, Somsubhra, Srikanth, Stefan, Stephan, Stephan, Stuart, Sune, Sven, Thiago, Thomas, Thomas, Thomas, Thomas, Thomas, Thorsten, Thorsten, Tim, Timothee, Tobias, Tom, Torio, Torsten, Unai, Urs, Vera, Volker, Waldo, Werner, Wilco, Will, William, Yann, Yue, Yuri, Manu, Ismail… And everyone I’ve forgotten to mention!