The next task I will work on will be a simple refactoring one, just like the first. I'll have to wait the end of this semester to start working harder on Nepomuk, but meanwhile I can still do something of some use. While the task itself isn't enough for much talk, the fact that it is a refactoring one is worth some attention.
Refactoring is not something an undergraduate student would care about. Why rewrite some functionality that is already working when you'll submit that programming assignment and never look at it again? This line of thought is perfectly applicable to projects of that nature - few lines of code, short life cycle, no perspective of growth.
However, when a code base starts to be measured in tens or hundreds of kilo lines of code (KLOCs), of which a good part was written years before, the situation changes drastically. Federico Quintero, known for co-founding the GNOME project, describes a state of badly written software that Refactoring practices try to thwart:
"When I was learning how to program, I noticed that I frequently hit the same problem over and over
again: I would often write a program that worked reasonably well, and even had a good structure, but
after some time of modifying it and enhancing it, I could no longer tweak it any further. Either its
complexity would overwhelm me, or it would be so tightly written that it allowed no room for
expansion, like a house where you cannot build up because it has a sloping roof, and you cannot build
to the sides because it has a wall all around it." 
This situation is perfectly conceivable. I have experienced it - like probably all programmers that started personal projects while learning to program. Continuous refactoring is a must to avoid that. I think this is even more true when the subject is a free software project. In an enterprise environment, people are paid to work, and it may simply not be an option to avoid touching that project with a messy code base and flawed architecture. In the free software world, on the other hand, people get in and out of projects everyday and as they wish - free software, free people. It's difficult for a newcomer to engage in a project where the simplest change can break everything, and parts that were meant to be simple are in fact hard to understand and tweak. And a free software project that fails to attract new blood to it is unlikely to prosper. KDE has a lot of initiatives that help to increase its Bus Factor (like the Techbase, Season of KDE, strong participation in Google Summer of Code, mentoring programs), and it seems to work well. At least for me.
That's it for now! While refactoring is surely good for the health of the project, it will also make me learn more about Nepomuk. The two patches I wrote were against the kde-runtime repository, where the configuration manager lies, and this one will be the first inside nepomuk-core. Time to work!
: Software that has Quality Without a Name (which is part of a great book, Open Advice - What We Wish We Had Known When We Started, available for free)