Bobulate

I'm in Calgary, which means snow and sun and -12 and +18 and rain and locusts and beer and pizza, all in one week. So if I'm otherwise unresponsive, it's not because I'm wrapped up in lifehacking or philosophizing late into the night.

I will be going to Akademy, but I won't be submitting a talk - as member of the programme committee, that would be kind of conflict-of-interestish. There will be quality and ebn and solaris bofs, though.

Interesting Free Software events I can think of in the Netherlands in short order:

May 15th is the NLUUG spring conference on security.

There's another CodeYard community day on June 21st; these Community Days bring together CodeYard participants from across the country (twenty to thirty of them) for a one-day combination of talks about computer science topics (model checking this time, by Frits Vaandrager) and hacking on the CodeYard projects everyone is involved in.

Then in early july (5-11) there is the eth-0 outdoor LAN event. Assuming good weather it looks like a wonderful location in the quiet north-west of the Netherlands (I'm not fond of "the west" as I associate it with big dirty cities, but up that way it's quite nice). And camping is always good. The organizers are hoping to get a good KDE-NL presence there, which I think would be a good thing for KDE-NL as well. We can have our yearly BBQ there or something.

August gives us Akademy in Belgium.

September has the Holland Open Source Conference (which is more about stuff on servers than stuff on desktops) which this time is partnering up with other conferences at the Westergasfabriek, it seems.

I don't know what to do in October.

And November has the NLUUG fall conference which has mobile devices as its theme; this will be co-hosted with the Embedded Linux Forum ELC conference, so for two days of embedded devices come to both conferences.

After that I think we can settle down for Sinterklaas.

I'd like to welcome to the fold (as it were) Marijn Kruisselbrink, who will be working on Small Form Factor (SFF) support form Plasma. For "small" think "smaller than an Eee" -- an Eee is still a PC with the fine-grained input provided by keyboard and mouse. This is a humongous step forward in providing a smooth KDE experience in unexpected places (I think we can skip the rule 34 interpretations of this). But remember it is Plasma focused. There are plenty of KDE applications that don't play nice with small screens already (big configuration dialogs, mostly). That's not on the agenda, but might be a side project if we get really excitied about dealing with form factors (it's also been on the todo list for EBN checking for ages).

It turns out I've already stood and admired Marijns work, but just not realized it was him At FOSDEM he was hard at work on the Mac doing Plasma things to get the whole KDE4 desktop there (while I was doing similar stuff on the KDE4 branded SunRay next to him). And at dinner he produced the Plasma 1973, which also got a big round of "oohs" and "aahs".

So I'm looking forward to being involved -- at arm's length -- in Plasma development this summer. While I work on big iron, my student can work on small iron. KDE Ubiquity.

After blogging recently that KHTML on Solaris was suddenly broken, the KHTML team (or part of it at least) hunted me down, shook me around and said "let us help you fix it." Or something like that. Maybe if I was a better writer of noir fiction I could make it sound more impressive, but Maksim sat down (virtually) with me to go bughunting, and after some binary search of the commit space we settled on r.796955, an otherwise innocuous commit. It took a further 15 minutes of staring to finally spot the missing "return" statement. That got drowned out in other compiler output and we just missed it. Duh, but a simple fix and KHTML renders things with tables nicely again (that's nearly every webpage out there -- very few use no tables at all).

So then we moved on to stack handling in KJS. I originally added a gross hack to work around the fact that Solaris doesn't have pthread_getattr_np(); that got KHTML to compile, but anything with Javascript crashed as soon as the garbage collector was used (web pages with no JS are rare and I think even clicking a link activates the GC). With the help of some friends, and some friends friends, and some friends friends friends who happen to own a major interstellar trucking company, we got to use some fairly obscure Solaris API (but that's fine in KDE SVN: there's a real need for exactly this bit of obscurity, and it's even documented as ... is typically used by debuggers, garbage collectors, and similar applications. Most applications should not require such information. Good thing this is GC code.)

So thanks to him, now I have a KHTML that renders right and supports JS, so I can use it to browse my webcomics again. And applying Konqueror on Solaris to Acid3 gives the same 73/100 score it gets elsewhere (although there are some freezes and slows, so something else is wrong somewhere). So thanks, KHTML folk, for following up on the lazyweb form of vague complaining.

One last blog entry on metrics; so far I've received a lot of useful comments. It's time to restate my position on metrics (as a guy who works on software metrics a fair bit): raw measurements, published without sufficient context, cause confusion and invite unfounded comparisons. That's just because of how people see numbers: that apple scores 3, this pear scores 5 (I guess one is a Braeburn and the other a Doyenne de Comice) The unfounded comparison is that the pear is better than the apple.

Which brings us to the notion of comparability. Basically, the thing to note is you must compare apples to apples. There's a blog post by Alex about LOC and an insightful comment by Zed Shaw exhorting to basically comparing things where comparison makes sense; context is crucial in such matters. (In Alex' blog post, it becomes clear in the comments thread.)

Cases in point: comparing LOC of program A and program B. I think that you can sensibly claim that there is a relationship between LOC and maintainence effort; if A and B are written in the same language by similar programmers for similar functionalities (how to establish that is another matter) then you might conclude that A is easier to maintain than B if A's SLOC count is smaller than B. Might be, because of corner cases such as perl one-liners. You can't even translate SLOC(A) > SLOC(B) to mean "A is bigger than B" in any meaningful way: but the mere existence of such numbers is going to invite such a comparison.

Similarly, absolute numbers of bugs reported: invites a comparison that is meaningless without context; for Free Software projects the context includes the project's culture for reporting bugs, which makes it kind of hard to adjust for. But Gartner is (or used to be) pretty good at playing the "X has more bugs than Y" game, in a pomegranate and grapefruit sense.

But now let's turn to apples and apples. The gist of Zed's comment is that it does make sense to watch metrics over time. Because we may assume that today's A is quite similar to yesterday's A (this goes for developers, KDE subprojects, etc.) This is a fair comparison: if I do 10 commits today, and did 2 yesterday, I might be more productive today than yesterday. This assumes that the kind of commits I do doesn't change from day to day and we've already discussed the tenuous relationship between commits and actual productivity, but still: all else being equal, 10 is better than 2. Watching metrics over time also alerts us to sudden changes. If my commit rate falls to 0 and my mailing rate falls to 0, then possibly I'm on vacation. In a more knotty fashion: if the cyclomatic complexity of some piece of code suddenly goes up, we can think that it will require more testing or possibly some refactoring and algorithmic improvement in the near future, or that the code has changed in some fundamental way (new features or something). Again, we need more context to determine whether this is good or bad.

.. or do we?

Most likely "good" and "bad" are just the wrong words to be using. And I'm talking like a manager who is watching the process of software development like an ant farm -- they're doing something, but I don't understand what or why. So let's stop with that.

The reason I actually do source code metrics is that they can be used by the developers to show something that the developer may not even be aware of; discontinuities in the graphs are interesting rather than good or bad and it's best if the developer reflects on what happened to see if there are any quality implications inthe discontinuity. For some metrics, it's just nice to be able to point to distinguished events (like the green-blobs graph which shows developer activity per week; you can point out where coolo got married). Metrics can be employed to give developers an idea of where effort is needed, or -- through counting simple errors -- a place to get started.

In the end, within the KDE project -- this is a reasonably apples-to-apples environment -- the old adage of the EBN applies: if the numbers go down, our quality has gone up. When the numbers go up, we're introducing new code. And when the numbers go up drastically, we've probably introduced a new tool to count a new class of errors that weren't on the agenda previously.

Having discussed (or blogged) a bit about sprints and their productivity, maybe we should collectively sit down and try to figure out what makes a sprint successful. That means defining what a sprint is -- i.e. what are the artifacts under study -- and what we mean by successful.

[But before we go on: Bluestorm, thanks for your comments, by the way, on gaming the system. I hadn't heard the term 'affective grounds' before, but it covers a lot of the effects we're seeing here. Also, I should add as a disclaimer that I work with Paul every week and drink beer with him too, so he and I are sort of on the same page.]

So, I'm going to shake a definition of sprint out of my sleeve here. I'm going to disallow too small -- i.e. Kevin visits Aaron and they hack -- and too large -- everyone goes to Akademy and we hack -- events, for one thing.

A sprint is a gathering, in one physical location for a limited duration (less than 7 days) of a small group of developers (or contributors; don't let me rule out, say, a usability sprint; group is five to 15 people) of a defined project (you should be able to say 'this is the <foo^gt; sprint' and have it understood; not all of the developers need to belong to the project already) with a definite goal (stated beforehand; this tries to rule out 'lets get together and hack' and desires a little more vision) and a daily focus on working towards that goal (this suggests some minimal management during the sprint; Paul can best explain how the SQO-OSS ones go).

Actually a short sentence if you leave out all the parenthetical addenda. There are some arbitrary constraints in there; I'd be happy to hear of arguments why some of the arbitrary constraints should be adjusted or relaxed.

This brings us to successful. Given a sprint -- the object under study -- can we say if it is successful? Or how successful? I don't particularly care for a [0.0,1.0] scale, but it is useful. We might want to introduce some kind of adjective words for levels of success (such as 'not', 'partial', 'adequate', 'unqualified', 'rousing'). Bear in mind that the notion of success must be measurable which means that general well-being and happiness of developers does not count. That's not really measurable, is it?

Let's turn aside for a moment: suppose we have a definition of success. We can go through our historical cases of sprints and calculate the success score. Then we go through and we have to validate the results. Was the KDE PIM sprint in the Netherlands a 'rousing' success as the numbers would suggest? Of particular interest is actually both the negative results (finding a sprint that the numbers say really wasn't a success -- we would really need attendee validation that this is the case) or mis-files (say that the attendees find something a rousing success but the numbers say it was just so-so). In both cases we need to check back with the attendees for a qualitative validation of the sprint. And it would be very useful to have some other metrics applied indicating some other form of success (e.g. retrospective function point analysis). Both big jobs, and that is all based on the assumption that we can define success in some global fashion for sprints anyway.

Well, before we get to defining success, we should consider what we can actually measure about a sprint. Because that's the raw stuff we can use to define success. There's not much point in defining success based on the colours of socks worn at the event unless we start consistently taking pictures of feet. And that's just icky. I'll list some things that I can come up with:

• Number of attendees; number of days; number of attendee-days.
• Number of new introductions (pairs [a,b] who haven't met before, also known as the n00bness quotient and indicative of how the community for the given project is growing).
• Number of commits by attendees; total commits during event; number of commits to project; relative amount of commits on average per day compared with the medium-term average over the period [t-60, t-3] (t is in days) for the project, where the -3 is there to account for travel.
• Amount of beer drunk by attendees (we don't have this data for past events though).
• Number of new participants still active in the project at t+30. Proportion of all participants still active at t+30.
• Lines of IRC log during sprint.
• Number of bugs closed in Bugzilla during sprint. Number of bugs raised in [t,t+180] in the code added during the sprint (note: that's hard to measure).
• Number of design documents added to KDE SVN. Number of design pages added to Techbase. Number of Techbase changes.
• Mail messages by attendees to project mailing lists during events. Relative amount before, during and after.
• Length of time with increased commits-per-day in the project (at least historically, we have seen that a sprint means a boost in the number of commits per day for some time, six to ten weeks, after the end of the sprint).
• Number of dot stories about the sprint. Number of CNet articles about the sprint. Number of press articles in general. Number of times the sprint is mentioned on the project's website.

Most of these are measurable or could be made measurable by sending an observer to the event. My interpretation of "success" in a sprint would be some combination of new developer retention, all developer retention, relative commit gain and length of time thereof, along with some extra consideration of non-SVN artifacts (as Anne-Marie points out, doing a design document can be more important than code monkeying).

That's my initial stab at defining success for a sprint, without any intention to validate it or actually calculate it. What's yours?

Or, as a good subtitle: "the assertion that metrics-based software development is stupid."

I've got a nice article somewhere in a Communications of the ACM about software metrics. And how using those metrics to drive development or evaluate performance is generally a bad idea. Generally. Not always. Much of it comes down to "gaming the system", which I suppose I had best define as: In "gaming the system" the "system" refers to a system of a process and some measurement on that process and a rewards scheme based on the measurements; "gaming" is the practice of performing actions that result in favorable measurements, independent of whether those actions meet the overall goal of the system. You can see this happen in educational circles: when the system measures, say, student grades and financing is granted based on those grades, there is a strong pressure to raise grades and so obtain more financing, regardless of the grades the students should be getting.

There's probably more on that in Freakonomics. That's a pretty good book. Heck, there might even be more on it in Wikipedia.

But turning to software development: we produce software. But the word "produce" there is kind of weird, since software is intangible. When you're producing cars or corn you can count the physical output; you can look at a partial product and have a good idea of how much effort is needed to complete the product. Not so with software. How can you count products?

This is why we end up not counting the products, but derivatives of the product itself: commits, lines of code, etc. But because none of these directly relate to the goal of the process, namely software, we open up the doors to gaming the system.

When such circumstances arise as to promt the financial remuneration, compensation, consideration and recompense of a writer, scribe or author's efforts on the written page and in print it may be taken into consideration that a method of measurement of said activities and products which recompenses verbosity and not clarity of thought and expression may lead inadvertently and accidentally to over wordy, lengthy, tedious and altogether annoying prose. Or: paying authors by the word means they'll write longer sentences.

In our little software world, paying by lines of code or commits is a bad idea, because it will prompt people to start producing more lines of code or commits regardless of whether this is good for the overall purpose of the process, i.e. good for producing the end software product. Here's a good way to prop up your productivity, as a shell function:

commit() {
for i in `svn st | grep '^[AMD]' | awk '{print $2}'`
do
svn commit -m "$1" $i
done
}

Instead of committing a bunch of files at once, you commit each one individually (all with the same commit message). Suddenly one atomic commit becomes five! That's a five-fold productivity gain right there.

Waaaait a minute, you say. That's not productivity! Well, not in the common sense of the word, but within this system which pays by the commit, it is . And so you game the system. Same goes for lines of code, and much effort has been put into "correcting" lines of code counts to be more accurate as an indicator of overall productivity.

But it remains an indicator, no more. You can always do manual loop unrolling if you need more money within a system that pays for SLOC.

One of the few things that can do a reasonable job of measuring software productivity is function point analysis. Based on lots of experience in managing software, you chop the required functionality into function points, assign an amount of time to each, and developers work on the function points and tick them off as they are completed. This does a pretty good job of measuring productivity, but even in commercial software development there's about an order of magnitude difference in function points per hour between different projects within the same organization (again, from memory out of a CACM issue). Closer analysis of the numbers is always needed if you want to steer future development based on these numbers. And let's face it, the whole premise is hopelessly flawed in the anarchic community based development that characterizes KDE.

So we get back to counting the things that we can count. Because developers do produce lines of code and commits. If that's all that is countable, then -- here the old adage about hammers and nails applies -- then that's what you count.

Note that within a project (especially a gigantic umbrella project like KDE) I will never suggest that "more productive" (based on what we can measure) means "better" or "more useful." Because productivity is based on something derivative of the actual useful effort put into the project -- the purpose is to produce cool software, and we can't measure that effectively. So for the sprints considered recently -- SQO, Plasma, and there's KDevelop too and Anne-Marie mentions the KDEEdu sprint -- with this measure of productivity we can just crunch the numbers and draw a graph. But none of that says anything about the purpose, use or success of such sprints, except within the system we're working in.

We could -- and the KDE e.V. does, in a way, by encouraging each sprint or developer meeting to introduce new people to the project -- use a different measure of productivity for sprints. We could count the number of person-pairs (a,b) physically present at a sprint that have never previously been in one room together. The SQO sprint scores 0 on that count, Plasma considerably higher. We can game that system by bringing in random hobos from the street.

So whenever you are measuring derivatives of a process and not the actual product or goal of that process -- and I will argue that for Free Software development this is the case we have to live with -- you can game the system and need to live with it.

So where does this leave us with SQO-OSS? We are measuring stuff about things. The things being Open Source software projects, the stuff being, well, .. being stuff. And the stuff includes numbers about the process, such as numbers of commits, active SVN accounts, growth of SLOC, number of reported bugs. It's really important to remember that the raw numbers are not really comparable between projects or even between different parts of (umbrella) projects. I'm aware that bad comparisons will inevitably follow (case in point: introduce a metric that counts the letter F in source code, and conclude that fvwm is better than postgres because the numbers are bigger). Here careful scientific study -- and that doesn't happen on blogs, but in papers and conferences -- is needed to amalgamate and normalize the numbers into something that is at least somewhat comparable.

There's a European project -- not SQO-OSS -- to bring together a number of existing Open Source quality models. That's the kind of long-term research that is needed to be able to do a qualitative comparison between software products and we expect that SQO-OSS will deliver the kind of numbers needed to evaluate such a shared quality model. However, qualitative assessment will be needed for a long time to come to tune the models and validate their results.

So the short summary: using the word "productivity" to denote one derivative product of the process that is sprinting is confusing, but in the world of software metrics we can't do much better than that without having a much better grasp of the quantifiable and measurable goals of such processes.

And, as an addendum: I have a SQO-OSS T-shirt that says "commit". It's because I do the most commits in SQO-OSS. Am I the most productive? Yes, says the metric. Am I the most useful person in the project? Who knows. We're all in this together. But looking at the qualitative aspects of my commit behavior, I'm into small atomic commits much more than others in the project. I will happily commit typo-fixes every half hour while going over a document; others do the whole document as one commit. That's a workflow difference that games the system even when it's not intentional (or productive, since I'm not paid per commit).

So it's a Star Wars paraphrase. So what? There comes a point when a Free Software desktop reaches the state that it works well enough to live in tolerably. Then after that you get "pleasant to live in". For me, KDE4 is somewhere between those two -- and that is largely due to my choice of platform (Solaris) and source of KDE (SVN trunk). The screenshot shows what could be my desktop all day, every day -- konsole, kate, okular and kmail. I mean, there's other apps I do use fairly regularly like konqueror (what's a world without lolcats?) and kolourpaint (because I have to exercise my graphics skillz) but I can get by on just those four.

So for certain types of code monkeys (who never make a typing error in the shell, because that's not fixed yet) you can take this desktop and just use it.

You can see in the screenie that I'm compiling kdenetwork now and that the kopete gadu plugin needs some work; the PDF of a book I'm working on is there in okular; you can see that I've been submitting some compile fixes as bug reports to TT's tracker and that kmail works -- this is a consequence of SSL now working: I can get at my IMAPS server. The big blue square is all KHTML displays right now, though -- why that should be, compared to last week's version, I don't know.

So can we blow up some Cardassian cruisers now? Let's do some shoutouts instead.

The bug squad is doing impressive things. Just sorting through all the bugs is a big thing to do. As our range of platforms expands, this becomes a bigger job because the platform the bug may manifest on becomes more and more niche (or, for the KDE4 Windows ports, less niche but also less popular under the current set of developers). And I can appreciate the dedication of the bug squad because some bug reports and bug reporters are downright unpleasant. We get occasional angry ALL CAPS messages to the webmaster or sysadmin or somewhere else from bug reporters; there's not much to do about them, but I notice it leaves a (negative) stamp on my day and I hope it doesn't get the bugsquad down. (There's a fine line and a good blog meme between legitimate anger about bugs and pointless shouting.)

Paul will crunch the numbers if you ask him to. As we develop more of this kind of tools and they become easier to apply to KDE as a whole, look for this kind of information to leak onto the EBN and into the commit digest. The KDevelop hackathon may provide similar insights. Me, I hope that C++ parsing becomes a nice separable library from KDevelop.

There's big issues with "productivity" as a measure in Paul's blog post. This always happens. There was critique when we introduced the top-committers in the EBN. The same applies to the commit digest. Just counting SVN commits is not a measure of "productivity" as it is understood in common usage. So either we need to refrain from the use of the word entirely in usage and just say "commit count" or "commit count times commit size pro-rated by the following function based on Booch's 1992 study of the comparative size of expressions in various programming languages" or we need to understand that "productive" can have meanings far removed from common sense in some settings. Frankly, "productive" is a more convenient word than any description, but it needs clear definition. Since we can't base a definition of "productive" on much other than the "hard" results in KDE SVN, that will just have to do.

Of course the Plasma sprint was more productive in the sense of team-building (first meeting, always exciting) or API review (SQO-OSS knows where it is headed and didn't need to do wild things this week) or pizza eating (we had mostly Indian and Thai in Berlin) but that's simply not measurable. Anyway, regarding the use of the word "productivity" and critiques thereof I'd like to quote from the Hitchhiker's guide interactive adventure by Infocom:

You have destroyed most of a large galaxy. Please pick your words with more care in future.

Sebas blogs about some plasma results which are cool and I gather that I need to start asking him to develop my KWin features for me. Dude, I still want focus follows mouse.

And then I want Death Star laser cannon follows mouse, and the Rebellion will be crushed. Oh, and some better security on those darn exhaust ports.

The thrill of exploration -- that feeling of satisfaction in discovering new views, or achievement in porting more software -- can be tempered by the horrors that may be found across the newly opened frontier. Today I sat down and patched up the OpenSSL detection in kdelibs (OpenSSL lives in /usr/sfw where we normally don't want to look because of old versions of other software that lives there too). That was pretty painless, except maybe where the CMake macros FIND_PATH and FIND_LIBRARY use inconsistent macro arguments. Huzzah, OpenSSL is found. Only the 32-bit version, though -- I'm not brave enough to try to massage the KDE build into both 32- and 64-bit versions yet. So what new horizons do we see?

Well, lots of pointer-to-function casting problems. Sun Studio considers pointers with extern "C" and C++ linkage different enough to issue a warning. The warning occurs when you try to assign an int (*)() to a variable of type extern "C" int(*)(). And if you are assigning function pointers with function-pointer arguments, the warning gets raised to an error. This program illustrates the issue:

extern "C" {
int foo() { return 0; }
int bar(int (*f)()) { return f() + 1; }
}

int main(int argc, char **argv) {
int (*f)();
int (*g)(int (*)());
f = foo;
g = bar;
return g(f);
}

This compiles with no warnings with GCC, but with Sun Studio 12 you get

"t.cpp", line 17: Warning (Anachronism): Assigning extern "C" int(*)() to int(*)().
"t.cpp", line 18: Error: Cannot assign extern "C" int(*)(extern "C" int(*)()) to int(*)(int(*)()).

I'm really not sure why one is a warning and the other an error. To know that I'd have to check closely the calling conventions and I'm not really in a mood to do that. Suffice to say that adding a typedef for extern "C" int() functions allows me to specify the types so that it satisfies the compiler. For KSSL there's four typedefs needed to get it up and running. And then -- a second sigh of satisfaction in the morning -- KDE4 supports SSL on Solaris. So I can read my https based web-pages again.

And what thorns await on this side of the hill? Well, it seems the Konqueror HTML rendering has gone totally insane as it renders only backgrounds and those very tall. So that part is still very problematic. I've got a desktop pager overlapping the system tray bits. There's a new plasma-themed throbber at the end of my panel (this sounds like a good line for spam mail, really) that I don't know what it does but I imagine it will become clear in time. Starting firefox from alt-f2 crashes krunner. But all these thorny thickets don't obscure the long-range view: it's beautiful and Free out here.

[[ Thanks to John Levon pointing out that my grep skills suck; I moved okular's chm support to the more standard uint types and now all of kdegraphics builds again. Having an okular that displays PDFs might not be a great leap for Mankind, but it's certainly useful on the desktop. ]]

A hacking sprint like we had in Berlin takes some recovery -- this is common to sprints, as you might see by reading either Chani's or Aaron's "I'm tired" posts after the Plasma sprint in Milan last week. I think it was a good week for sprinting. Maybe Paul will put up some charts showing the kind of productivity effects the different sprints had on their respective projects. I know it felt good to be together in a small group hacking towards a shared goal that, we could articulate over beer and food.

Recovery after such an event takes a few days. I didn't even have to change timezones but I've been sleeping weirdly for a few days; it finally feels like I'm settling down again today.

Which means taking out KDE4 for a spin on Solaris again and catching up with what broke in the meantime. Not much, really. Only the introduction of some new dependency libraries -- poppler, in this case -- opens up new perspectives for finding broken code elsewhere. You can't debug what doesn't get compiled due to missing dependencies, after all. I'm running into one thing in okular's chm support, which uses u_int32_t and similar; Solaris of course has only uint32_t while Linux only has the version with the extra underscore and FreeBSD has both. I'll have to wrestle a little with it; it should probably just be ported to use quint32 instead.

There is little rest for the wicked, though. Friday I'm packing up again to go to Calgary to visit old friends. I hear the weather is just peachy there.

While Paul covers the SQO-OSS sprint which I am also attending (an event well-supplied with expletives and cookies) I figure I might summarize the first Amsterdam Girl Geek Dinner, which I got to attend thanks to an invite from Donna of the Gender Changers.

It was humongous.

As a guy I mostly stood in the corner and tried to stay out of the way. Some of the attendees were annoyed to find so many guys there; the ratio was 7:1 instead of the (usual in Computer Science classes in the Netherlands) 1:23. Plans were hatched for small-scale IT events around the country; networking and fiber-optic handling was discussed with much verve.

Fabienne, from HardHack.org and other places, a well-known hardware hacker, gave the presentation at this first GGD. All the fun things you can do with a cellphone and a soldering iron. That turns out to be lots. Inspirational is the right word. And if you're interested in hardware hacking on the cheap, the HardHack event is this weekend in Berlin.

And then it was over and everyone snuck out of the FlexBar and back into late-night Amsterdam. The next GGD is in three months or so - watch the site for announcements.

The next morning I hurried through Amsterdam again to get to the FSFE licensing workshop. This was a congregation of business lawyers, Free Software people and corporate legal folk to talk about licensing. What works. What to watch for compliance (gpl-violations.org was there too).

So in short I spent a day in a room full of IT lawyers. I can continue to assert I've never met a lawyer I didn't like. Lots of back-and-forth on interesting topics; trademark law, ramifications of the GPLv3, tools and compliance checking (KDE doesn't do half bad on that front, simply because we have the EBN and some decent tools and a clear license policy). A good feeling of learning from best practices, too. And then that was over and I had missed the last train back home. Drat.

Well, a little more careful reading of the license headers and Krazy's license check explained to me why akode gets so many license complaints from our automatic tools: it has a cut-and-pasted spelling error (Franklin Street) everywhere, I've gone and fixed some of them. That reduces the noise to manageable proportions. Once that's past, there's much fewer problems. Focusing just on akode because that's what I happen to be checking right now, we have:

1. Missing license headers in all the files in mpc_decoder. There is a readme, which refers to LGPL.txt. Presumably that is LGPLv2.1, but it would have to be checked. The file LGPL.txt itself has been removed. This is a fairly straightforward thing to fix: hunt down the source of this code, check exactly which license it has, and add the headers to each file (and encourage the upstream to do the same as this example shows how software licenses in external files can quickly be lost).
2. Unacceptable licenses. Well, this is what the license checker says, anyway, and I'm not sure I agree. The mpeg_decoder plugin is GPLv2+, and our library policy says LGPL (or BSD). But these are *plugins*, and there may be other rules that make sense for them. Something to ask the tame legal advisors, at any rate.

Looking briefly at other directories in kdesupport:

1. chrpath is a utility program - I wonder why it's in there at all, really, although it's useful on Solaris as well - which is GPLv2 but none of the files have license headers. They do name copyright owners and how the code was derived, but for the license we need to check the COPYING file. Again, best to keep the license text in the source file.
2. Eigen has a special exception applied to its template files, which are themselves GPLed. There's one missing license (quaternion.cpp) and the tests are GPLed -- this yields false positives which we should take out from the checker.
3. kdewin-installer ships lots of third-party code in whole; this triggers zillions of warnings from our license checking tools. The installer itself is GPLv2 (only) which is problematic these days, given the bits it probably links to.
4. qca is just wonderful (but I understand it's no longer developed in KDE SVN).
5. qimageblitz tests are missing licenses.
6. soprano has some GPL code that the checker complains about; this warrants a double-check to see if the GPLv2 is ok there (like in tests and standalone applications).
7. Strigi has some tests that miss a license, some single files are GPL licensed (and this is a problem forlibs building on top of it).
8. Taglib is LGPL 2.1, mostly, with the wrong address of the FSF.
9. Finally, qt-telepathy has headers with no licenses, but the headers themselves seem to be auto-generated and trivial.

So all in all we can say that kdesupport is supposed to be LGPLv2.1+ and most of the module is, in fact, licensed that way; there are a few minor sticking points but nothing that one or two emails can't massage away. So let's do that massage (Aaron gives good one,s too, if you happen to be at a KDE event) so that we can pass our own license purity tests. We're a Free Software project; the Free Software licenses we use are our most important tool in creating and maintaining that freedom.

[[ And as an addendum, I found GPLv3 license logos while wandering around on the FSF sites, which are one way of clearly advertising what the license is on the code you ship. Quite useful, also in reports when talking about licensing. ]]

This blog post is distributed under the following terms:

Copyright (C) 2008 by Adriaan de Groot <groot@kde.rg>. All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

THIS BLOG POST IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. DANGER WILL ROBINSON. BAA MEANS NO.

Woo hoo! Going to Amsterdam. That'd be more thrilling, maybe, if I didn't live in the Netherlands. But Amsterdam is really far away, both emotionally and in terms of train travel. Cologne is much closer, both in my experience of "yeah, I'd drink beer there" and travel time. There's two events I'll be visiting (and Chani is passing through Schiphol sometime this afternoon on her way to the Plasma sprint, but she's unreachable and only in-transit for about an hour - a pity, as I'd much have liked to meet a Real Plasma Hacker for once).

The Amsterdam Girl Geek dinner will have about 35 attendees, which I think is a great turnout for the first time of such an event. This is the kickoff of something intended to be a monthly event for women (in spite of the girly moniker) in IT and an initiative I really applaud.

Next morning, the FSF Europe FTF (old website: I can't find the FTF mentioned on the new FSFE site) is holding a licensing workshop; I'll be there to communicate about how KDE deals with copyrights, licensing, etc. That's just one of the reasons I was looking at the licensing of KDE code recently. I will be dragging along a partial checkout of support and libs in order to check them on the train (using my eee, so's to finally test its functionality).

Maybe there's other things to do in Amsterdam. I don't know. I should get a tourist guide

Yesterday I went through KDEPIM to get it to compile on OpenSolaris; this was pretty straightforward and I caught extra compile issue where KDEPIM and pimlibs had diverged. KMail starts. It then complains about logging in to my IMAP server using PLAIN; I haven't sorted out whether that is a configuration issue on my end or if it is something with SSL instead. Something to track down after I knock over kdenetwork.

I have added stack trace support to kdeui so that when an app crashes (not if) you get a trace dumped to stderr; this is faster and more convenient than using gdb even if you don't get the nice window with a trace like this. I'll have to work on it a little, though, as it prints C++ symbols in mangled form. But having this feature immediately confirms my suspicions that Konqueror is crashing deep in the KJS engine when doing garbage collection. This does not surprise me, as I know I put an egregious hack in there in order to get it to compile at all. So remember: any comments I make under the heading "Solaris" about the stability of KDE4 applications apply only to the port of said apps on OpenSolaris with the weird set of tools that the KDE-Solaris team has chosen. What goes on on other platforms is a different matter entirely.

Anyway, the backtraces (from printstack(3)) look like this:

/lib/libc.so.1'__sighndlr+0xf [0xfef00d0f]
/lib/libc.so.1'call_user_handler+0x2bf [0xfeef5c32]
/opt/kde-4.0/lib/libkjs.so.4.1.0' 1cDKJSJCollectorbEmarkStackObjectsConservatively6Fpv2 +0x6a [0xf950306e] [Signal 11 (SEGV)]
/opt/kde-4.0/lib/libkjs.so.4.1.0' 1cDKJSJCollectorbFmarkCurrentThreadConservatively6F +0x74 [0xf95033f8]
/opt/kde-4.0/lib/libkjs.so.4.1.0' 1cDKJSJCollectorbEmarkStackObjectsConservatively6F +0x18 [0xf950341c]

Which is perfectly readable if need be. An improvement would be to de-mangle names nicely so I don't need to pipe the output through c++filt.

[[ Words of thanks to Robert Knight for thinking about my Konsole problems and pointing out where I should start looking. Thanks too to Joep Vesseur who keeps pointing me in the right direction for Solaris tweaks even when he claims not to know C++. In the time it took to write this blog entry, I got kdenetwork to 29% compiling. ]]

I remember, not all that long ago, Tom Albers (among others from the release team) launching a licensing initiative; this was partly to push for acceptance of GPLv3 in KDE code (since we have dependencies using GPLv3, we need to update to something compatible and GPLv2-only is not compatible). Today, I started looking at the code in KDE SVN in response to an academic query about the licensing of our software. I looked at headers in kdesupport. Granted, it's not a "core" SVN module, but it does ship all kinds of things that KDE really needs. And headers, well, sometimes headers are just small and trivial and boring. So I was expecting a few issues. There always are. What I wasn't expecting was for over 200 of the 1083 header files to be missing copyright headers that our tools recognize.

It also turns out that our license tool has a bug and rejects the 51 Franklin street address that the FSF currently occupies (well, according to the website it does), so we need to fix that up before starting to fix that up.

The EBN reports on bad copyright headers, so you can get a partial report from there. For instance, Eigen has a bunch of files under GPLv2+; license policy is that libraries must be LGPL (but that's policy as codified in the tools; I'm not really convinced that these should apply to kdesupport as well). Taglib has one missing license warning -- unicode.h is derived from a public domain work but the license text is not recognized. akode is full of unlicensed code.

The whole exercise was thus quite surprising to me; it also means I can't answer all that accurately what the licenses are that we use in kdesupport + libs + pimlibs + base. Most of it will be (L)GPLv2+ or (L)GPLv3, but we need that to be explicit.

You can check your own code as well; the license checker is in KDE SVN. You can get it with svn co svn://anonsvn.kde.org/home/kde/trunk/quality/krazy2/plugins, it's the license script in there. Krazy plugins are (generally) perl scripts with a strict interface; this means you call the script with --verbose for a long report and a list of files to check. For instance, you can do perl license --verbose `find src/ -name *.h` to check all your header files. Similar check for cc, cpp, etc. if you find a file that is licensed properly but isn't recognised, please drop me and Allen a note (or kde-quality@). Keep in mind:

• Each file itself needs a copyright header. Don't defer to a COPYING file elsewhere.
• Put your name in it if you're the primary author. Put your name in it if you have provided a sizeable contribution that may be copyrightable (i.e. has some creative merit).
• Don't use variations on the licensing language. The EBN / Krazy checker is kind of strict about what's acceptable because the advice we have obtained on licensing issues is that it's best to be (a) recognizably the same as another license (b) complete. So put that whole GPLv3 blurb in there, not just "This file is licensed under the GPL"; the blurb may be cut-and-pasted out of say, kdelibs/kdecore/services/kservicegroup_p.h or use the blurb in the licenses/GPL_V2 (or _V3) file in kdelibs/licenses.
Doing all that makes it much safer to distribute the code for everyone. Questions and comments on the tools themselves can best go to kde-quality@; things about license policy to kde-licensing@ with a CC to me. And then write more Free Software (under the two-clause BSD license, for instance).