This post was orignally planned as my 10 year anniversary post, but due to me finishing my thesis and starting on my new job this got a bit delayed and now I’m already 11 years on the Krita team. Boudewijn has already posted a much more detailed look back at the history of Krita. Here just some of my thoughts on the last 11 years.
I started working on Krita in late December 2003. The funny thing is that I’m not an artist and I don’t really have a use for the application itself and was more interested in the development of a graphics manipulation in general. Ironically my art teacher back then claimed that you could not do art with the computer because there was not direct connection between the hand and the canvas and therefore the machine had more influence than the artist.
Back in 2003 Krita had never been released and the application was only able to do some very crude painting. I think the main reason that I started contributing to Krita back then was that I was much more comfortable with the single window UI and the fact that it used Qt/KDE and C++. In the early days I would never have imagined that I would be still with the project after 10+ years and how big the project is now. Even that the project exists today is a miracle and result of many developers putting in effort without ever knowing how it would develop. For the first few years we had almost no users and the users that we had were die-hard KDE users. At the time that wasn’t a bad thing as it allowed us to do some radical changes and experiments. Many features that were developed during this time still provide the base for the current Krita.
The early days of development were a bumpy ride. We made three releases based on Qt/KDE 3 and Krita was starting to take of with version 1.6. Then we made the jump to KDE 4, which was expected to be big, but in hindsight turn out much bigger than anyone was expecting. In the end it took several years to complete that and if we had known how long it would take we wouldn’t even have started that. During that period the project the suffered quite a bit as development stalled for some time and we lost some developers which got exhausted from the port. The biggest things we learned from that is to never start porting to a new set of libraries before it’s even tested, to never make a release cycle longer than a couple of months and when you are porting to never do anything but porting.
After Krita 2.0 was released we got back on track and made good progress. Releases happened much more frequently still the improvement from version to version became bigger and bigger. Looking back it’s interesting how old even the last version looks. One of the major turning points in this time was the decision to concentrate on painting in Krita. Back then it was a big controversy, but today I think it was maybe the best desision we ever made. It sharpened the development and made Krita overall a better application. I think we proved the everybody wrong who said that we focus on a too small user group. Based on bug tracker and forum activity we certainly have at least a tenfold growth of the userbase since then.
The current development of version 2.9 is really exciting. This version will bring support for multiple-windows inside the application which is one of the biggest changes we ever made to the user interface. Also really nice it that the 2.9 beta is attracting a lot of user testing. Several years ago I made a post about Krita needing more bug reports, now we got in the last two weeks more bug reports for the 2.9 beta than we got in a whole year back then.
For the future there is a lot of interesting stuff coming up. Due to my new job I won’t be able to contribute as much as I used to, but I will continue to work on Krita. After 2.9 we will make the jump to Krita 3.0 which will use Qt 5/KDE Frameworks 5. The new libraries are not that interesting I think as in terms of desktop development not much changed since the KDE 3 days. For some users it will mean less dependencies which will certainly close some discussions. I think the developments I’m looking forward to in 2015 are Level of Detail painting (which should bring us up to Photoshop speed) and animation support which is one of the most requested features. Both have already seen some initial development, but will need more work in 2015.
I want to thank every developer who ever worked on Krita and all the users who supported us.
Sven's Blog 
December 27, 2014 at 5:36 pm
hahahha “we had were die-hard KDE users” i am one of them
December 28, 2014 at 8:06 am
i have no artistic talent so i rarely use these kinds of programs (maybe Gimp 2-3 times a year) but Krita, Blender and some others always impress me by their quality.
thanks for all the work you have done and to all the people who give of their time. hopefully having free (both libre and gratis) software of this quality is very important.
December 28, 2014 at 11:46 am
“I started working on Krita in late December 2013.”
I think you meant 2003.
December 28, 2014 at 1:35 pm
@Steve Emms: Right, I have corrected that. Thanks.
December 28, 2014 at 8:11 pm
“Then we made the jump to KDE 4, which was expected to be big, but in hindsight turn out much bigger than anyone was expecting.”
Is anybody else concerned about that statement. To me it confirms something I’ve long suspected about C++ (and perhaps the entire object-oriented programming model). A library version update should not require what sounds like a major rewrite of an application. But all too often, it seems to. I don’t know if that is a function of the language – or of the enormous structures that tend to get built to implement any object-oriented framework. Theoretically, if your object model doesn’t change much, then porting to a new framework version should require little more than a recompile. But it never seems to.
To me, that says the creators of the framework are either winging it (and getting it largely wrong – requiring major restructuring in the next go round), or simply not thinking forward enough to build in the kind of expandability that they will ultimately need. Over the years, I’ve stuck with C, largely because the C++ examples my co-workers generated were God-awful – adding lots of gratuitous complexity in the service of potential functionality that never gets taken advantage of in any meaningful way.
I’m not saying that the QT framework suffers from this, and to the extent that it’s complexity is in the service of platform portability, I’m all for it. But if the transition from QT3 to QT4 (or KDE3 to 4 – if that’s where the issue was) was as difficult as the poster suggests, I’d like to know if the team acknowledges that anything was done wrong – or if they think that’s just how it is. Because I don’t think it has to be…
December 28, 2014 at 9:14 pm
@littlenoodles: The actual port was not that difficult, but there were many different factors that came together. It has nothing to do with Qt or C++.
There were a few problems:
The port started very early. We started way before the KDE 4 libraries were finished. One of the reasons for that was that KWord wanted to use the new Scribe text rendering engine to make sure that Qt supported all we needed the port was started really early. The problem with that was we were developing against a moving target.
Due to change in other parts the other developers didn’t want to idle while waiting for other parts to finish. That trigger more refactoring and rewrites in other places which added up the longer this state went on. For example in KDE 3 times all the KOffice applications were a collection of independantly develop applications, shao for KDE 4 all where unified and put onto a common basis which was the flake library.
When everything was over it ended up as a major rewrite of many of the applications that was much bigger than anticipated. That was all made during a major version change of the libraries and the build system.
In hindsight you always know more and we would do it totally different now.
For the Qt 5/KDE Frameworks 5 version it will be different. We waited until the Qt and KDE libraries are out and tested. The next step will be to do the port which is more or less running a few scripts and after that to make sure that everything still works. Then we will release 3.0 without any functionality changes.
December 29, 2014 at 4:23 pm
@slangkamp: Thanks for the additional info. I didn’t say it *has* to be hard to do a version upgrade – just that it all too often *seems* to be. My only comment on your explanation is that it feels like a problem when ‘wanting to use the new Scribe text rendering engine’ amounts to wanting to do a full port to KDE4. Again, I suspect that’s due to the tendency of class libraries to have so many internal dependencies. In C, the Scribe engine would be its own library – largely independent of the rest of the framework. While I’m sure that the framework offers powerful constructs that helped the writers of Scribe to build it more easily – and make it ultimately more powerful, there still seems to be a downside to all that interdependence. That said, I guess your point is if you’d waited till KDE4 was done and stable, it wouldn’t have been hard in any case…
December 29, 2014 at 6:03 pm
@littlenoodles The problem isn’t the internal dependencies of the libraries, but the dependencies of the applications on eachother. If you change the text component in an office suite all the other applications use that, so everybody has to wait for that to be done.
This is not related to the language e.g. the change from GTK 2 to GTK 3 show similar problems.
November 14, 2015 at 4:01 pm
Hi, I’m doing a report about Krita and I would like to contact you through email for asking some questions in order to start my investigation right. If you could give me some contact information or contact me directly I would be really thankful.
Thank you so much.