As for all my blog entries, this is my personal opinion about one of my hobbies. And it is neither the official position of the KDE project, KOffice project or Krita project on the subject.
I have been thinking to write that blog entry for a long time, I am often pointed out that I am duplicating effort made somewhere else, while this is sometimes true, this is not always the case, and some other times, it is even intentionally. But giving the reason over and over is really annoying, so now I will simply be pointing to this blog entry.
Four reasons to either develop a new library, subsystem or plug-ins, from scratch, while there are solutions that allready exists and look similar :
1) There is no library that does quiet what you want to do, or not even close to it. When I blogged about color conversion in PigmentCMS, I was pointed out that I should have want to use Babl, which is a color buffer converter, for one thing PigmentCMS is more, CMS usually means Color Management System, but in this case, it also means Color Manipulation System, so PigmentCMS is basically much more than color conversion, it includes all kind of color transformations, that said, Babl could have been used for the color conversion, but in fact, we are already using LCMS for that, and for the color spaces not supported by LCMS, we are going to use CTL (Color Transformation Language). So basically, there was little that Babl was doing, that wasn’t done by other external libraries or some other mean.
We are also often asked why we don’t use GEGL in Krita ? The answer is quiet simple, GEGL didn’t exist when development started again on Krita, in 2004, while GEGL was started around 7 years ago, until recently it was a dead project and when Øyvind Kolås took over, he nearly rewrote everything. So basically, GEGL didn’t exist, and development on both libraries happened at the same time, share some concepts, have some different design decisions, and is developed using two different languages (and agreeing on one would have been an impossible tasks). Besides, there are positive effects to this situation, while it seems a waste of time, because both seems to share the same goal, image manipulation, but there isn’t a higher Truth about it, so by having two competing libraries, two competing pieces of software, we can make different experimentations, discuss it and improves our solutions.
2) License issue. Sometimes, you are interested in a library, but because Krita is pure GPL and rely on some pure GPL libraries, you find sometimes yourself in a position where you can’t legally use a library and distribute your software. The current example I have is the CTL (Color Transform Language) library developed by AMPAS (the organization behind the Oscars ceremony), they are using a derivative of BSD with a jurisdiction clause that makes it impossible for pure-GPL software to use the library (for the disbelieving ones). The two first alternatives is to alter either one licenses, when neither is possible, if you want to use the features provided by the library, the only option, left, is witting an alternative implementation.
3) The library is broken beyond repair, badly documented, rely on bad design, is buggy and use a programming language you dislike (which makes contribution to it nearly impossible). My main example is libexif which is poorly documented, buggy, has an horrible API (worse than most C-library using an object layer) and is not extensible to other meta data specification. If applying the strict rules of no duplicating effort, exiv2 would never have existed. And that would be a shame, as Exiv2 is vastly superior, now in a single API, with a good documentation, one can decode/encode Exif, IPTC and XMP. Implementing Exif support in Krita 1.5 took me more than a week, while replacing it with Exiv2 (and at the same time consolidating in RDF compatible storage) took me twice as less time. So, Exiv2, while duplicating the features of an other library, was clearly not a lost of time.
4) Fun and Knowledge (which are my two main motivation behind my Krita involvement). I am not payed by a company, my whole Krita involvement development is made on my free time, so it has to be fun. And the one single most important thing in the world that deserved our protection, attention and care is Knowledge. There are two parts on acquiring some knowledge, first reading the theory (articles, books, etc…) and second part is practical experiment. Without the first one, you can’t do the second one, but with only the first one, you have achieve strictly nothing, you have no idea of the challenges implied by the theory. In the computing world, the practical experiment is writing code.
Typical example of this is for me is the panorama plug-ins in Krita, I could probably force me into trying to glue the various piece I can found on the web and put them together and voila. On a side note, the alignment library of Krita is flexible enough that you can replace any part or even all part by something else without breaking the features that rely on it. But, I wouldn’t find any fun in doing that, nor would I acquire any interesting knowledge. Besides, unlike what can have been told we are very open to external patches and contributions, so, if someone comes with a patch that does something better than my code, I will happily apply that patch to Krita, and even if that’s mean that my code goes into a black hole, I wouldn’t consider that I have lost my time, after all I have acquired some precious knowledge writing that code.
It’s the fourth point in this blog entry, but it is the most important to me. The first three are driven by the need to achieve something, while this one is driven by the true motivation for open source (you also can have fun and implement something totally new, and I do it too, but that wasn’t the point of this blog entry).