For someone who really doesn’t like the company or the platform, I’ve had curiously many macs. It started with a Powerbook Pismo which I got secondhand to investigate some problems Krita had with big-endianness (it had a powerpc cpu and ran Debian), during the first Krita kickstarter I got KO GmbH to buy a mac mini so I could work on porting Krita to macOS. That one was horribly slow, so then in 1015 I got a 15″ macbook pro. In 2020 I first got an M1 MacBook pro, to look into making Krita ready for the M1 cpu. And after that an M1 mac mini for KDE’s binary factory. I haven’t noticed other projects making use of it, though, and it’s a bit unstable.
And then, since I still could get a good trade-in value, I decided to swap the 13″ M1 for a 14″. The 13″‘ screen was always a bit too small for me and I hated the touch bar with a vengeance.
I’ve been using it now for a bit, and here are my impressions…
The out of the box experience was… Trying my patience a lot! First it needed to download and install 6.1 GB of updates before I could even start sending over my user files. That took hours, even over my really fast glass connection..
Then I wanted to transfer my user folder from the old macbook to the new one; I was warned that that would take five hours. In the end, it was “only” two hours. But that worked really well: everything was copied and ready for me.
Only at that point, by now it was early in the evening could I log in. Asnd that didn’t work. I needed to futz with my Apple ID from another Apple device — and that several times. When that was finally sorted, and I don’t remember <i>how</i> I sorted it in the end, macOS insisted on setting up all kind of stuff I’ll never use, like iCloud.
The next day, I could finally setup my development environment, dropbox and other stuff. Dropbox on M1 macOS has a problem: it can no longer install the kernel extension that would automatically download an off-line file, which means… For every file in Dropbox that I want to use, I need to manually make it available off-line. That’s still not sorted.
As for the development environment, installing XCode took, once again, hours. I only use the command-line stuff, the IDE I use for working on Krita is Qt Creator.
So, now I was all set to go and build Krita. At that point it was clear that this laptop is amazingly fast. Compiled C++ files scrolled by at a clip that I only know from C on other computers.
Actually developing, though, is not such a nice experience. The problem is mainly with the keyboard. As far as keyboards go, the actual keys type fine. It hasn’t got a lot of travel, but it’s easy on the nail polish, it feel good — typing text is a lot of fun. It’s got function keys again, which is also nice.
But…
It’s missing so many keys. I know, that’s par for course with Apple, but when using Krita, a missing Insert key means no easy way to create layers. And there’s a lot of inconsistency between applications. In Terminal, you switch tabs with Control-Tab, in Firefox with Option-Command-Left/Right, in Qt Creator with Option-Tab. I haven’t figured out what it is in Kate. Navigating around text is also inconsistent between applications. And that means that I just never get any finger memory down: especially since I also use all other operating systems…
The window manager is also pretty primitive and needs help from an external utility called Rectangle.
And the permissions stuff is crazy. The wacom tablet driver needs permissions to use Accessibility — as does, for some reason Dropbox.
The hardware for the rest is fine… The screen is good, I don’t mind the notch since I run pretty much everything full-screen, all the time. Battery life is good, but not as good as the 13″‘ battery life was.
As for the rest of the hardware, the screen is fine, I don’t mind the notch, because I pretty much always use all applications full-screen, because of how bad window management is compared to KWin, even with Rectangle.
And I have got a cute cover sticker with Kiki on it!
I have previously written about this subject, and back then couldn’t reach any conclusion. The options open to us were all confusing: we could try to write Krita’s canvas directly in Metal, OpenGL and Direct3D and show those in native windows in our QtWidgets based application.
We could try to rewrite our canvas in QRhi, the semi-private GPU API abstraction Qt 5.15 and up provides — though it might not have enough functionality for us, since it us just written for what Qt needs for QtQuick.
We could try to rewrite all of Krita in QtQuick and integrate our canvas into QtQuick’s render loop: but yes, that means a complete rewrite, because you cannot put a QWidget in a QtQuickWindow, and putting QtQuick into a QWidget window means you’re rendering using OpenGL, which breaks on Windows, now that Qt6 doesn’t come with an Angle option.
So we had a big blue button meeting on Friday, where we discussed this issue and some other issues.
Here’s what we concluded:
We will patch Qt6 to render OpenGL using Angle on Windows and macOS.
In the meantime, using Qt 5.12, we’ll move forward adding QtQuick based elements to Krita.
And we’ll try to make a QtQuickWindow based version of Krita for Android. Sharaf Zaman has succeeded in prototyping that, so we know it can be done now; something we lost in the migration from Qt4 to Qt5.
We also want to strip out the CPU-based canvas in Krita and port our usage of QPainter on OpenGL surfaces to straight OpenGL.
And finally, something we should have done during the port to Qt5, we’ll move uploading the canvas textures into a thread, which should solve the performance problems on macOS.
All in all, it was a very focused and very productive meeting, though I guess the conclusion might be a bit startling. And we’re a bit daunted, but only a bit: we already patch the heck out of Qt anyway.
Two days ago, my macbook pro M1 arrived. I mainly got this device to test Krita on and make ARM builds of Krita, but it’s also the first macbook anyone in the Krita community that allows playing with sidecar and has a touch strip.
So, SideCar works, as expected. There is one problem, though, and that’s that the pressure curve of the Apple Pencil seems to be seriously weird, so I first thought I was painting with a sketch engine brush. But apart from that, it’s nice and smooth.
KDAB has published a library to integrate support for the touchbar: kdmactouchbar — so on that front we might see some support coming.
Krita itself, the x86 build, runs fine: the performance is much better than on my 2015 15″ macbook pro, and rosetta seems to even translate the AVX2 vectorization instructions we use a lot. Weirdly enough, X86 Firefox doesn’t seem to be able to load any website, and Safari is very annoying. Looks like the macOS build of Kate isn’t notarized yet, or maybe I need to use the binary factory build for that. XCode took about two hours to install and managed to crash the system settings applet in the process.
We haven’t succeeded in actually making an ARM build yet. We first need to build the libraries that Krita uses, and some of those seem to build as X86, and some as ARM, and we haven’t figured out how to fix that yet.
The laptop itself is, well, a laptop. It’s not bad, but it would never be my favorite. Yes, it’s very fast, that’s what everyone says, and it’s true: Qt builds in a mere 20 minutes.
The keyboard is nice, much better than the one on the 2015 macbook pro, so Apple was able to make some progress. But the edges of the palm rest — well, all of the edges are really sharp, which is quite painful when typing.
Really cute was the way the language choice on installation tells you to press Enter in all the language, including four dialects of English.
MacOS 11 is also really annoying, with an endless stream of notifications and please-use-your-finger-to-unlock for the most innocuous things. The visuals are appallingly ugly, too, with really ugly titlebars, a cramped system settings applet and weird little pauses now and then. And if the performance monitor can still be put in the menubar, I haven’t found the way to do that.
Anyway, that’s it. We’ll be making ARM builds of Krita one of these days. If you value your freedom, if you like the idea of actually owning the hardware and being able to do whatever you want with it, don’t buy one.
Adrian Page first coded an OpenGL-based canvas implementation for Krita in 2005. That was back in the Qt3 days. OpenGL was fairly simple back then, but we had to duplicate all our canvas handling code, once implemented in OpenGL, once implemented with QPainter.
Krita’s canvas code executes in three phases. There’s the image projection, that is, the result of combining all the layers, which is drawn first. Then we draw the canvas decorations: that’s the selection outline, the guides, the assistants, the reference images and so on. Then we draw the tool decorations: that’s the outline cursor, the line for the straight line or ruler tool and so on.
Obviously, implementing all of that twice, once in OpenGL, once with QPainter isn’t ideal.
The Good Days
So we were elated when Qt4 appeared. Qt4 came with an OpenGL based QPainter engine. This was ideal; we could split up our canvas code. The image would be drawn with pure OpenGL on a QGLWidget or with QPainter on a QWidget, and the canvas decorations and tool decorations would be drawn with QPainter on either canvas.
The Qt documentation even came with a nice example showing how this was to be done.
The First Fly in the Ointment
However, the Qt developers apparently saw the OpenGL QPainter engine more as a way to speed up the drawing of QWidgets than something that application developers would use. And the OpenGL QPainter engine never was able to render a complex application completely correctly.
So at some point, the engine stopped working on macOS. Mostly because Apple doesn’t want people to use OpenGL, so they’re starving their drivers from development, but also because the Qt developers thought that the OpenGL QPainter engine was a failed experiment because it didn’t improve performance when painting their widgets: they had forgotten that applications developers are using QPainter in their OpenGL applications. Or even told them not to do that. Though the documentation never reflected that opinion.
With the migration from Qt4 to Qt5 something else happened: Qt4 QML was based on QGraphicsView. I’ve always suspected that QGraphicsView was created for companies that needed mapping software, but in the Nokia days there were several attempts to use QGraphicsView as a basis for a mobile ui framework, DUI (best link I could find; there’s serious loss of history here).
Those attempts failed, until someone came up with QML, which initially was also rendered with QGraphicsView.
We used QML to create Krita Sketch and Krita Gemini. Because it was based on QGraphicsView, the touch ui we created worked seamlessly with our OpenGL-based canvas.
When Qt5 came out, QML was based on OpenGL and a scenegraph. We spent several months and quite a bit of money trying to integrate our OpenGL canvas in in the new scenegraph, but it just did not work. At all. It couldn’t be made to work, and Krita Sketch and Krita Gemini died.
(As an aside: it was much harder than we had expected to port our OpenGL code from Qt4 to Qt5. It was a huge hassle, in fact.)
The Next Episode
And then Google Chrome happened.
The quality of OpenGL drivers on Windows was always variable, sometimes even really bad. We had already encountered that when developing Krita Sketch, when we suddenly had a lot of Windows users.
Google encountered the same problems with Chrome, and they implemented a solution: Angle.
Angle seamlessly translates OpenGL into Direct3D. And once Chrome used that, all their crashes were gone.
And the GPU manufacturers had no reason all anymore to fix their drivers, so they didn’t. Games would use Direct3D, Chrome used Angle, and pretty soon Qt added an option to use Angle, too, because otherwise QML-based applications on Windows would keep crashing.
This was excellent news for us. We started using Angle, and the number of bug reports dropped a serious amount. And when we wanted to support HDR screens on Windows, the fact that we were using Angle already was great, because that enabled us to make HDR work, because on Windows, HDR can only be made to work when the window is rendered using Direct3D.
The HDR patches still haven’t landed in Qt, so we are carrying them, along with a lot of other patches that are needed to make Krita work well.
We regularly port those patches to newer versions of Qt5, but we make all our Krita binary builds with Qt 5.12, because every version of Qt since 5.12 has been too buggy to use. For example: with 5.15, using a QMdiArea in subwindow mode will hang on Windows.
Except for the fact that Krita Sketch was still dead, and we were porting to Android, and a mobile UI would have been nice, everything was fine.
Qt6 Drops Angle
Because, obviously, Qt’s Angle build option only existed to make sure that QML apps would work on Windows, not for anything, Qt6 has dropped the Angle option…
Because there’s going to be a new framework which will use the various GPU API’s (Metal, Vulkan, Direct3D, OpenGL) directly with a abstraction layer (Rendering Hardware Interface ) above them that will be used to render the QML scenegraph: RHI. It looks like that’s all internal to Qt, though.
It’s really hard to find documentation, but it looks like QPainter will render using those modules; but what isn’t clear is what will happen when we’re going to use QPainter on a QOpenGLWidget. Or would we have to implement a Metal canvas, a Direct3 canvas, and an OpenGL canvas? And will we be able to access the HDR functionality on Windows?
Or should we just patch Qt6 so it can be built with Angle again?
Update
This blog post appeared on hackernews, and one of the reactions (the one I linked to) was really helpful: Jean-Michaël Celerier has actually implemented something outside Qt, using Qt’s RHI interface. So that is possible! Even though the documentation says “Aim to be a product – and in the bigger picture, part of a product (Qt) – that is usable out of the box both by internal (such as, Qt Quick) and, eventually, external users.”
So, I guess the choice for Krita boils down to using RHI — after we’ve determined that it is possible to use that, or using Angle.
In both cases we would be running an abstraction on top of Metal, Direct3D, OpenGL or Vulkan. In the first case, we’d tie Krita even closer to Qt (and every Qt major release changes its approach to graphics, so in a couple of years, who knows…) In the second case, we will have to maintain patches against Qt.
(Recommended music while reading this: Peggy Seeger singing “The Housewive’s Lament)
I’ve been having nightmares, well, really weird dreams for quite some time now. Things like finding myself trying to clear up the floor of a large DIY store just before the first opening day, and not managing it, no matter how many friends were helping. Trying to pack all my luggage when leaving a rented holiday home, and never being able to fit everything in. Trying to pack furniture and stuff into boxes before moving out because someone needs to replace the floor, and having to squash ancient china cups in a carton box, breaking them all in the process. If I manage to wake up, I’m exhausted and tired.
And I guess I’ve grokked why I keep having these dreams. And it’s not lockdown or Covid-19. It’s this:
When we held our last bug fundraiser in 2018, we decided to focus for a year on stability. we had about 300 bugs. And we’ve never even managed to come close to that number of bugs ever since! And yet, in the past year, we’ve closed more than a thousand issues.
Clearly, something is wrong here. This isn’t sustainable. We have managed to deflect a lot of reports that were actually cries for support to a new community website, krita-artists.org and to r/krita. Our experiment with ask.krita.org wasn’t successful, but krita-artists really works. We still do get a lot of worthless bug reports, but I think it could be a lot worse, now that we really have millions of users on four platforms.
But it’s still not sustainable. Every report needs to be read, often deciphered, triaged, investigated, fixed — and all those steps involve communication with the reporter. Even the most useless bug of reports can take an hour to resolve with the reporter.
11:32:47. Eep, incoming bug interrupt. Bug 422729 – No action (assignable shortcut) for Magnetic Selection Tool. 11:33:24: Check, yes, reporter is right. 11:34:32: Confirm. Check code. Notice that all .action files that define actions in the plugins/tools folder are wrong. 11:37:35: Add note to bug report. Fix all of them. 11:47:49: reporter asks a question that needs to be answered, but is not very relevant. 11:56:29: answer given, while I’m building Krita with my fix. 11:57:03: Tested fix, isn’t complete, more work needed. Oh, wait, tested the wrong build. Tested the right build, but the new action isn’t found. 12:00:00 Debug more. 12:25:45: fixed some more broken xml files, ready to make the commit. 12:27:41: Bug is fixed. 12:31:33: Fix is backported to krita/4.3 branch and an extra commit is added that in future will print a warning if the xml parser cannot read the .action files.
Back to this blog post… This was a fast fix: it took about an hour, and in between I also had to run downstairs to receive my new book on Jan van Eyck.
So, this bug report reported a small, but real issue and uncovered a deeper issue. Without the report we probably wouldn’t have noticed the issue. Krita is better because of the report, and the reporter is one of our “known-good” reporters: he has reported 16 bugs this year, one is still in Reported state because we couldn’t reproduce it, six are Confirmed, two are Assigned and seven are Resolved Fixed. Yu-Hsuan Lai has helped us make Krita materially better!
But… Even with me, Dmitry, Agata, Wolthera, Emmett, Eoin, Ivan, Mathias and more people fixing bugs all the time, we’re not getting the numbers down. The floor remains littered, the luggage unpacked and the china unboxed.
Of course we’re not the only ones in this situation: every project that takes bug reports from the general public faces this issue. Some people argue that any bug that has a workaround should be documented and closed; but workaround don’t make for a happy workflow. Others argue that every bug report that is older than two weeks, or a month should be closed because it’s clearly not a priority. But the issue reported is real, and will get reported over and again, with no way of chaining the reports together.
It’s also possible to treat reports like a funnel: first ask people to report on a user-support forum, like krita-artists.org, and only when it seems to be a real bug create a bug report, and only when it’s triaged, put it in a queue. But the problem with that is that nobody’s queue is ever empty. That can be done by assigning the bug to one of us: currently we have 64 bugs in the Assigned state. that means, on average, ten bugs each person’s queue. That in turn probably means betwee a week and a month of tasks already in our queue… Which means we shouldn’t actually look at any newly reported bugs, before we funnel them into our queue. (Another option would be to create issues on invent.kde.org for every bug we really want to work on, something we used to do with phabricator… But pretty quickly we drowned in those tasks as well.)
Which in turns means that either reporting bugs is useless or our todo queues are useless.
And that todo list doesn’t even include working on new features, refactoring old code so we decrease technical depth or working on regressions — that is, features we broke accidentally.
So, even though bug reports help make Krita better, the one thing I’m sure of is that we shouldn’t do anything that will make it easier to report bugs. We have more than enough reports to keep us busy.
It would be nice, though, if we could make it easier to make good bug reports, for instance by automatically attaching our system information and usage logs to a bug report made with the Help->Report Bug functionality.
Theoretically, that can be done, bugzilla offers a complete REST interface. And I seem to remember that we had that in KDE, years ago, but that it broke because of an update of bugzilla. There’s a new version of bugzilla coming, apparently, and maybe it’ll be worthwhile to investigate that again, in the future.
Argh… I think the dreams will continue for a while.
When I read “Qt offering changes 2020” yesterday, my first reaction was to write a pissy blog post. I’m still writing a blog post with my thoughts about the changes, but I’ll be nice. There are three parts to this post: a short recap of my history with Qt and then my thoughts on what this means for KDE, for Krita and for free software.
I started programming using Qt and PyQt when I read about Qt in Linux Journal, which I was subscribing to back in 1996. That means that I’ve been using Qt for about 25 years. I initially wanted to write an application for handling linguistic field data, and I evaluated GTK+, wxWidgets, Qt, Tk, fltk, V and a few others that have been forgotten in the mists of time. I choose Qt because it had great documentation, a consistent API, the most logical (to me…) way of doing things like setting up a window with a menu or handling scrollbars and finally because it made C++ as easy as Java.
I’ve stayed with Qt for 25 years because, through all the vicissitudes, it kept those qualities. Mostly. There are now a lot more modules, most of which aren’t necessary for my work, there are people working on Qt who seem to be a bit ashamed that Qt makes C++ as easy as Java and want to make Qt as computer-sciency as C++, there have been the licensing issues with the QPL, the changes to GPL, to LGPL and then again some modules back to GPL there have been the Nokia years, the Digia times.
But I’ve always felt that I could build on Qt. And the reason for that is the KDE Free Qt Foundation. To summarize: this is a legal agreement that keeps Qt free software. If the Qt company won’t release a version of Qt under a free software license within a year of a release, Qt becomes licensed under the BSD license.
With yesterday’s message, the Qt company is searching the utter boundaries of this agreement. To recap:
Long Term Support releases remain commercial only (the post doesn’t mention this, but those releases also need to be released under a free software license within a year to adhere to the agreement, at least to my understanding).
Access to pre-built binaries will be restricted: put behind an account wall or be only available to commercial license holders
And there’s a new, cheaper license for small companies that they can use to develop, but not deploy their work to customers.
This is a weirdly mixed bag of “changes”. The last one is a bit silly. Even the “commercial” side of Krita is too big to qualify! We’re five people and have a budget of about 125k…
The middle point is worth considering as well. Now there is nothing in any free software license that talks about a duty to make binaries available.
For a very long time, Krita, when part of KOffice, only made source tarballs available. Right now, we, like the Qt company, have binaries for Linux, Windows, macOS and (experimentally) Android. The Windows binaries are for sale in the Windows Store and on Steam, the Linux binaries are for sale on Steam. And all binaries can be downloaded for free from krita.org and other places.
This move by the Qt company would be like the Krita project shutting down the free downloads of our binaries and only make them available in the various stores. It would be legal, but not nice and would cost us hundreds of thousands of users, if not millions. It is hard not to wonder what the cost to the Qt community will be.
The first change, the restriction of the LTS releases to commercial customers has all kinds of unexpected ramifications.
First off, Linux distributions. Disitributions already rarely use LTS releases, and in any case, with Qt 3 and Qt 4 there didn’t use to be any LTS releases. But disitributions do have to keep older versions of Qt around for unported applications for a longer time, so they do need security and bug fixes for those older versions of Qt.
Then there’s the issue of how fixes are going to land in the LTS releases. At the last Qt contributor summit the Qt project decided on a process where all fixes go through “dev” and then are ported to the stable branches/LTS branches. That’s going to break when Qt6 becomes dev: patches won’t apply to Qt 5.
Albert has already blogged about this change as well, but he only really focused on distributions and KDE Plasma; there is of course much more to KDE than the Plasma desktop and Linux distributions.
As for Krita, we’re using Qt 5.12 for our binaries because we carry a lot of patches that would need porting to Qt 5.13 or 5.14 and because Qt 5.13 turned out to be very, very buggy. For Krita, using a stable version of Qt that gets bug fixes is pretty important, and that will be a problem, because we will lose access to those versions.
In my opinion, while we’ve done without stable, LTS releases of Qt for years, it’s inevitable that Qt 5.15 will be forked into a community edition that gets maintained, hopefully not just by KDE people, but by everyone who needs a stable, LGPL licenced release of Qt5 for years to come.
Splitting up the Qt community, already responsible for handling a huge amount of code, is not a good idea, but it looks like the Qt company has made it inevitable.
And once there’s a community maintained fork of Qt, would I contribute to the unforked Qt? Probably not. It’s already a lot of work to get patches in, and doing that work twice, nah, not interested. If there’s a maintained community version of Qt 5, would I be interested in porting to Qt 6? Probably not, either. It isn’t like the proposed changes for Qt 6 excite me. And I don’t expect to be the only one.
As for the more intangible consequences of these changes: I’m afraid those aren’t so good. Even in our small Krita community, we’ve had people suggest it might be a good idea to see whether we couldn’t port Krita to, say, Blender’s development platform. This would be a sheer impossible task, but that people start throwing out ideas like that is a clear sign that the Qt company has made Qt much less attractive.
If I were to start a new free software project, would I use Qt? Last Sunday the answer would have been “of course!”. Today it’s “hm, let’s first check alternatives”. If I had a big GTK based project that’s being really hampered by how bad, incomplete and hard to use GTK is, would I consider porting to Qt? Same thing. If the KDE Free Qt Foundation hadn’t that agreement with the Qt company, the answer would probably be no, right now, it’s still probably a yes.
Now as for the actual announcement. I think the way the Qt company represents the changes is actually going to help to harm Qt’s reputation. The announcement is full of weasel-wording…
“General Qt Account requirement” — this means that in order to download Qt binaries, everyone is going to need a Qt account. Apparently this will make open-source users more eager to report bugs, since they will already have an account. And, yay, wonderful, you need an account to access the completely useless Qt marketplace. And it allows, and now we’re getting at the core reason, the Qt company to see which companies are using the open source version of Qt and send salespeople their way. (But only if the people making the accounts are recognizable, of course, not if they make the account with their gmail address.) When I was working for Quby, I was unpleasantly surprised at how expensive Qt is, how little flexibility the Qt company shows when dealing with prospective customers — and how we never downloaded the installer anyway.
“LTS and offline installer to become commercial-only” — this will break every free software project that uses services like travis to make builds that download Qt in the build process. Of course, one can work around that, but the way the Qt company represents this is “We are making this change to encourage open-source users to quickly adopt new versions. This helps maximize the feedback we can get from the community and to emphasize the commercial support available to those with longer product life cycles that rely on a specific Qt version.” Which of course means “our regular releases are actually betas which we expect you freeloaders to test for us, to provide bug fixes for us, which we can use to provide the paying customers with stable releases”.
And yes, theoretically, the main development branch will have all bug fixes, too, and so nobody misses out on those bug fixes, and everyone has stability… Right? The problem is that Qt has become, over the years, bigger and buggier, and I doubt whether releases made fresh off the main development branch will be stable enough to provide, say, a stable version of Krita to our millions of users. Because, apart from all the bug fixes, they will also have all the new regressions.
“Summary”. “The Qt Company is committed to the open-source model of providing Qt technology now and in the future and we are investing now more than ever. ” — though only to the extent that the Qt Company is forced to adhere to the open-source model by the KDE Free Qt Foundation.
“We believe that these changes are necessary for our business model and the Qt ecosystem as a whole. ” — my fear is that the Qt Company will not survive the fracturing of the Qt ecosystem that this decision practically guarantees.
At the 2019 Libre Graphics Meeting, illustrator Livio Fania presented a heart-felt plea for more professionalism in libre graphics.
And that was the moment I began to think a bit. What is it that makes one project professional, and another not? Where, in this case, I’d take “professional” to mean “someone can depend on it so they can earn their daily bread with no more than the problems you always have with any software, because all software sucks, and hardware even more so”.
As Livio said in his presentation, funding makes a difference. If a project can fund its development, its continuity will be better, it will be better able to implement its vision and deliver what it promises, simply because funding equals time. That’s also what I tried to argue in my previous blog post.
In practice, it’s very hard to find funding for applications that that people do not earn their income with. Of course, there are very accomplished free and open source video players, editors or file managers. Those tend to be still completely volunteer-driven and very underfunded. And there’s a reasonably successful web-browser, which is actually funded quite well — but it’s funded to avoid Google being broken up as the monopolist that it is, mainly by Google.
And of course, there are applications that people use daily, earn their bread with and that are completely unfunded, even if they have donation buttons and money in the bank: GIMP, Inkscape, Scribus, various RAW photo applications, often by choice. This means that those projects are even more squeezed for time than a project like Krita. Just think how much difference Tavmjong Bah would make if he could be funded to work on Inkscape full-time! Tav gets $107 a month through Patreon… (Which I contribute too.)
But though Livio focused on the need to get funding to accelerate development, and it’s the first step, there’s more to creating a professional application.
The second step is: focus on the user’s needs. That starts with knowing what you want to create. If your goal is to implement a standard specification fully, as is the case with Inkscape, then is that goal sufficiently user-oriented to form the basis for an application designers can earn their daily bread with? It’s possible, but it’s something to always be aware of.
And like I argued recently, is looking inward, discussing the where’s and why’s of Free Software, no matter how enjoyable, not taking away time better spent getting to know your userbase, their needs and… The competition.
I would not be surprised if visiting the Linux Application Summit next would be less useful for Krita and its users than a week long training in Photoshop would be for me, as the Krita maintainer. We’ve all been there: we’ve all claimed we’re not competing with the big, sovereign, proprietary applications that are seen as a standard in the field where our application is the “open source alternative”.
But if you don’t compete, you cannot win. And if you don’t win, then millions of users will not use free and open source software. And I happen to believe that software freedom is important. And I’m slowly gaining the confidence to say: I am competing.
(And we are. Competing. Otherwise Adobe wouldn’t have been adding so many new features for painters and illustrators to their latest Photoshop release, some of them features Krita has had for a decade.)
And when we compete, which makes people trust us, and when our user fund our efforts, then we need to take another step towards professionalism.
That is, committing to continuity. I’ve always said “free software never dies”, but it does. Look at Amarok, which is thoroughly dead. Of course, Krita has been released since 2004, and there’s quite a bit of continuity already. But this does take commitment, which also needs to be public.
Finally, there’s the point where as a full-time project member, as the project maintainer, can no longer say “We don’t provide binaries. Get the source and build it, or wait for a distribution”. You have to provide your application in a form your users can use directly; it’s their time you’re telling them to use for something they don’t earn money with, if you ask them to build.
And then… We have to stop making excuses. Which is probably the hardest thing, because all software sucks, and all code sucks, and sometimes it’s impossible to fix a bug in Krita, because it’s in the OS, the Window manager or the development platform. Or the tablet driver, oh dear, the tablet drivers. But it’s your customer, your supporter, the person who depends on your work to earn their money who is stopped from doing that. And suddenly workarounds and hacks become necessary.
So, funding a core team of developers is the start, focusing on the field instead of the free software community, a will to compete, providing continuous improvement, making sure your software can be used and finally, not making up excuses if there are problems but fixing them.
Yesterday, me, Dmitry, Wolthera and Agata visited BlenderCon 2019. Intel had asked us to come to the conference to help set up the Intel/Acer booth, which was showing off Krita in all its HDR glory. After all, it’s pretty cool when a free software project has a real, tangible, technical, artistic first! It was great being there, meeting people who were really pleased to finally meet Krita hackers in the flesh.
(Aside 2: we tacked on a small sprint to this event, because the Intel team that works on these projects with us wanted to visit me in Deventer, and I wanted them to meet some other Krita hackers. At the sprint, I had HDR-enabled laptops for Dmitry and Agata, who were in dire need of new hardware. Yoga C940, really nice devices. We also discussed how to progress with the resource system rewrite.)
But, cool as HDR is, and the hardware that eventually arrived at the booth was pretty cool, too, and interested as many people were, that’s not the main thing I took away from the conference. What struck me once again was the disparity between how Blender is looked at from inside the Linux Desktop community, as if it were a largely irrelevant niche hobby project of no big moment in the larger scheme of things, and the reality of Blender as one of the most successful end-user oriented free software projects.
But first watch this:
Numbers
Let’s start comparing the numbers for some projects, roughly. Things I’m interested in are installed base, market share, funding levels, developer engagement, community engagement.
That puts the total Linux Desktop installed base at 90,000,000, of which one third is ChromeOS. All other Linux desktop projects, from Plasma to Gnome, from Mate to XFCE, from Deepin to i3 have to divide that remaining 90,000,000 installations.
Then financial stuff… In 2017, the Gnome project had an income of 246,869 euros, in 2018 of 965,441 euros, but that includes the Handshake donation, which is one-time. For KDE, the 2017 income was about 150,000 euros, and 2018 was about 600,000 euros, again including the Handshake donation. I can’t be bothered to look for similar statements for Mate and XFCE which are tiny in any case. In a normal year, Desktop Linux seems to have a total budget of about 400,000 euros, excluding commercial investment which is not controlled by the projects themselves. KDE e.V. does not use its budget to pay for development, and the GNOME Foundation supports development financially in a very limited way.
The Free Desktop has three percent of the installed base of Windows/macOS.
LibreOffice has been estimated to have 200,000,000 active users. About 10% are Linux users, which means that they count all Linux desktops, probably because LibreOffice is installed by default by all Linux Distributions. In 2018, the Document Foundation’s income was 855,847,78 euros, pretty much all from donations. According to OpenHub, LibreOffice had about 200 developers in the past year, and has had 1900 developers over its entire existence, and 64 in the last month. Microsoft Office has five times the market share, at the very least.
LibreOffice’s installed base is one fifth of Microsoft’s.
Krita has, according to data from Microsoft, which counts every time an exe is started on Windows 10, 1,500,000 active users (that is, distinct systems on which Krita is started at least once a month). A dumb extrapolation of that to 4,500,000 users on all platforms since Windows 10 has 33% market share is probably too coarse, but let it stand. It’s order of magnitude that’s important here.
In 2010, Photoshop had 10,000,000 users. Of course, Adobe has moved to a subscription service since. In 2017, Adobe Cloud (which also includes subscriptions without Photoshop), had 12,000,000 subscribers. Looks like going to a subscriber model is really curtailing their installed base. Also, no wonder that last year’s Photoshop update suddenly included all kinds of fancy features aimed at painters, not photographers.
Krita currently is at 3,000,000 downloads a year from krita.org, which excludes downloads from external download sites or Linux distribution installs.
Our current budget is in a bit of a flux, since it’s rising, mostly because of income from Steam and the Windows store, but it’s about 240,000 euros a year. All of that is used to support development.
Krita has had 52 developers contributing in the past year, and 450 over its entire existence, and 17 in the past month. We currently have five full-time developers.
(In case you want a comparison with projects similar to Krita, GIMP is 675, 74, 21 and Inkscape 423, 94, 18 — but for those projects, the translations are part of the git repo, for Krita those are external, so the comparison is questionable…) I don’t know download numbers for GIMP or Inkscape, because those projects intentionally don’t track those.
Let’s risk a limb: Krita’s installed base is about a quarter of Photoshop’s.
It’s pretty hard to find recent information about downloads or installed base for Blender. Of course, Blender works in an industry where the “market leader” AutoDesk has about 100,000 users in total. The same estimate, using information from 2014, claims 4,000,000 downloads for Blender and about 200,000 users. I haven’t found any information that’s more recent, but Blender 2.80 has made a big splash: I wouldn’t be surprised that it’s made an order of magnitude difference. (Besides, if I look from our download numbers to installed base as reported by Microsoft, the calculation in that article doesn’t stand.)
The 2019 Blender Conference, the ostensible topic of this blog, has over 600 paying attendees. But Blender is a tool that makes its users money; nobody makes money just using a desktop. It makes sense for someone making money with Blender to pay to go to a conference this packed with useful information and contacts.
Akademy is free, though Guadec asks for a registration fee. I couldn’t find information about how many people attended Guadec in 2019, but about 160 people attended Akademy; I am sure almost all contributors.
The BlenderCon fee gets you food, drinks, clothing and a bag. The whole conference feels very professional, from the venue to the catering, from the hardware, to the level of excellence of the presentations. More importantly, there is an ecosystem around Blender that actually rents booths to show off their offering, puts leaflets, stickers and brochures in the swag bag. Almost all attendees are seriously committed blenderheads: but that means users. This is not just one developer community looking inside itself once a year.
Blender’s development fund currently brings in about 1,200,000 euros a year, which funds 20 full-time developers. That’s not the only source of funding. Blender has about 172 developers in the past year, and 550 over its entire existence, and 64 in the past month, same as LibreOffice. Looking at the last number, it means that there are anyway more volunteer committers in the Blender community than paid developers. Funded development hasn’t eaten the community.
Let’s hazard a guess: Blender has four times the installed base of AutoDesk Maya. This is pretty rough, of course, so ingest with salt.
Funding Development
This is important, because one of the things that keeps getting argued in the KDE community is that paying for development destroys the community. So, where does that argument come from, and when might it be true, and when might it not be true? Remember, I’m only talking about projects aimed at end-users, about applications, about the desktop. Programming languages, libraries, web stuff, all that is irrelevant for this discussion. What is relevant is that we often hear people claim that it is impossible to successfully develop this type of software as free software.
Well, my guess is that the people who continue to claim that funding development on free software will destroy the community are either nostalgic for their nineties student days, or tried to build a business around free software that they recognized was going to be valuable, but that was built by others. They would have founded a company, hired the developers, then started working on projects and contracts for customers. Of course that will fail: customers only care about their needs. And once you’re invoicing per-hour, you’re bust. You will never find time to properly maintain the project you wanted to build your company around. You’ve turned into a leech, and will drain your central asset of its lifeblood.
The other way is what happens with Blender, with LibreOffice and with Krita. There is no company that uses the free project to build a business selfishly. Instead, it is the project itself that is funded. There might be businesses that profit from the existence of the successful project (like the cloud renderer companies that were showing off at the BlenderCon), but that’s not central to the funding of the project.
Instead, there is someone central to the project who drives its development and growth with enthusiasm and who cares for the community; the paid developers are not extraneous people uninvolved in the community, but part of it.
I was going to write “in my opinion”, but the facts are pretty clear. Funding the development of free software applications this way is essential to achieve real success.
Defining Success
Blender is a success. Blender has, in fact, won, as Ton says. Despite being 25 years old, it’s the tool young 3D creatives reach for automatically, Maya is for old fogies. It has support from all hardware industry players: Intel, AMD, NVidia. It has support from closed source companies like Epic, from companies like Adidas, who simply are users of Blender. It is becoming, if it hasn’t already become, an industry standard.
And if Blender, a free and open source application can become an industry standard, users of Blender will find it easier to accept that Krita, which is also free and open source, can serve their needs just as well. Blender shows that free software can be first class, and that will drag every other willing project with it in its wake.
At Krita, we’ve worked together with Intel, for over 15 years now. If you compare the market numbers for Adobe and Autodesk, then it’s clear there’s a much larger potential community of Krita users than Blender users (unless Blender turns Grease Pencil into a regular painting application…). No reason we cannot have community four times bigger than Photoshop’s installed base! We’ve got plenty of growth still before us.
But I used the word “community” here, instead of something like “market”. Because the second part that defines success is the ability to remain a community. Well, when it comes to that, Blender does show the way forward, too.
Autodesk has such a small user base that it cannot grow a community. It’s too expensive for that. Which means that long-term it has already lost. (Besides, it cannot buy and shutdown Blender, which is what AutoDesk does when faced with competition). The only thing it could do is make Maya cheaper, but unless they hire Mario Draghi, they cannot make Maya cheaper than Blender.
There are more Photoshop users, because Photoshop is cheaper, and Photoshop users have more of a community feeling, but the company is very proficient at alienating that community; people feel attached to the tool, but hate the company behind it.
For Krita, we’re trying to foster our community. We had a big sprint in August where we invited more artists than ever, we’re funding the development of our YouTube channel — but there’s a way to go. I wish we had someone to setup Krita Artists, analogous to Blender Artists…
What is Niche?
My argument is that the model by which the Linux Desktop, GIMP or Inkscape are developed make those efforts inevitably niche. Not that everyone agrees about what is niche. At the 2019 KDE Onboarding Sprint, I was told twice that Krita of course serves a niche market. Doing art is something only a very few people are interested in, after all, isn’t it? Not even the actual download numbers could change that impression. The desktop, KDE PIM, that sort of projects are the important ones, providing something everyone needs. It’s fine to disregard anything outside the Linux world because nothing we do could ever succeed there. Nobody uses Qt applications on Windows.We all know they just don’t feel right. (Which would be news to Autodesk, since Maya is written in Qt.)
To me, looking at the numbers I’ve tried to assemble above, the Linux Desktop is a niche, LibreOffice, Blender and Krita are not.
Ton has once told me he doesn’t feel connected in any way to the regular free software/open source crowd. Being Free Software is essential for Blender’s success. The GPL is core. But being part of the GNU/GNOME/KDE etc. world, he warned me, would be a drag on Krita becoming successful.
And you know what? Unless we can turn our own communities around, I’m beginning to think he’s right. To make a real difference, our communities have to cross boundaries and enter the wider world. To flourish, a free software project needs to have a budget to fund its core developers within the project, to implement the vision of the project.
Do they exist? Especially as free software? I don’t actually know, but I’ve never seen a free software project use something like what I’ve got in mind.
That would be: a website where we could add any number of test scenarios.
People who wanted to help would get an account, make a profile with their hardware and OS listed. And then a couple of weeks before we make a release, we’d release a beta, and the beta testers would login and get randomly one of the test scenarios to test and report on. We’d match the tests to OS and hardware, and for some tests, probably try to get the test executed by multiple testers.
Frequent participation would lead to badges or something playful like that, they would be able to browse tests, add comments and interact — and we, as developers, we’d get feedback. So many tests executed, so many reported failure or regressions, and we’d be able to improve before the release.
It would be a crowd-sourced alternative to something like Squish (which I’ve never found to be very useful, not for Krita, not at the companies where it was used), it would make beta testers not just feel useful, it would make beta testing useful. Of course, maintaining the test scripts would also take time.
It sounds simple to me, and kind of logical and useful, but given that nobody is doing this — does such a thing exist?
Clearly, something is wrong here. This isn’t sustainable. We have managed to deflect a lot of reports that were actually cries for support to a new community website, 