not invented here?

here is my promised blog entry looking at various possible cases of Not Invented Here syndrome within the KDE project. i asked for people to offer examples, and that i would address them. so let's get down to business.

KOffice. KOffice predates OpenOffice by some years. why didn't the developers just abandon ship when OpenOffice arrived? besides the fact that those involved had already put a few years of passion into it, they did so because KOffice has a broader scope of applications, is lighter on resources, is better integrated and provides a very fertile ground for developing KDE technologies that useful outside of KOffice. office suites are very demanding consumers, and so it's not uncommon for bugs to be sqashed and new features emerge in KDE's libraries due to KOffice.

note that KOffice uses, and will continue to extend its usage of, the OASIS file formats that OpenOffice uses. KOffice abandoned its own file formats to do this, to create defacto standard to back up the paper one. this is the exact opposite of NIH and shows the strength of having multiple, cooperating projects in the same space.

if you, the reader, are tempted to ask why KOffice doesn't pull in OpenOffice code, then you probably haven't looked at the two code bases. however, it is important to note that KDE developers are integrating OpenOffice with KDE via icons, widget styles and use of KDE dialogs. we can all just get along.

KHTML. as with KOffice, KHTML predates other open source HTML renderers. additionally, it is used by non-browser applications that require a light-weight, integratable and programmatically configurable HTML widget. these range from KControl to KMail to Kopete. KHTML is not just about web browsing, it's about creating a widget for applications. ditto for the JavaScript engine, which is being used for application scripting among other things. these are things that we just can't get anywhere else.

i'd also note that efforts to integrate gecko and XUL with KDE have taken place. it's not complete yet for a number of reasons, none of which are technical in nature. i'll leave the explaining of that to those closer to those goings on, however.

DBUS. one person mentioned DBUS. well, DBUS doesn't have a stable API yet, and we're only now in a position (KDE4 devel) to start thinking about those kinds of massive structural changes. these things have huge impacts on our user base, and we don't take lightly messing with them =) so it's too early to call which way this one will go.

at the end of the day, it will come down to quality and interoperability. it is equally true that just because the code isn't yours that you shouldn't use it, just because code is out there doesn't mean you should. it's a matter of weighing the benefits vs the costs. and for DBUS we've had only preliminary discussions. so far, the discussion has slanted in favour of DBUS.

and of course, 3.4 did ship with at least one component (the media ioslave, used by a panel applet, konqueror, desktop icons, etc) that optionally used DBUS.

Multiplicity of functionally similar apps. the issue of having a number of applications that do similar things within the KDE universe was raised. this isn't "NIH", however. there are many, many reasons for this happening ranging from "differences in scope" to "a developer wanting to have fun". but this is not what NIH refers to. =)