KRunner from the top?

Yesterday I was hit by the idea of putting KRunner at the top of the screen and making it 'slide in' when called up. The "floating dialog" just wasn't doing it for me anymore and so I went ahead and implemented this to see what it would feel like. After working out various kinks, I have to say that I really like it. So I decided to do a quick screencast showing KRunner in action at the top of the screen for you to watch and then, hopefully, offer some feedback on it. It's even better if you can try it out yourself by building from SVN trunk, of course, but I know not everyone can or will do that. If the reactions are generally positive, this will be the default for 4.4.

There are two small problems with the screencast, however. The first one is my fault: I forgot to show that you can click on and move the KRunner window back and forth along the top of the screen. The second problem is the typical screencast software fail: it doesn't capture smoothly enough to show any of the animations so you'll just have to trust me when I say that the KRunner window animates in and out of the screen nicely. Those animations are done by KWin, using the same effect we wrote for the autohiding panels in fact, and they are super sexy smooth.

Anyways, you can watch the screencast on blip.tv, download the Ogg file or watch it in the embedded player below if it shows up for you:

Read More

we all want to be different

In a blog entry the other week I talked about three challenges that arise as the number of individual groups participating in KDE has grown: time line mismatches, differentiation pressures and confidentiality requirements. I wrote a bit about time line mismatches, so let's move on to differentiation pressures. Here's what I said (in part) about this issue in that first blog post:

"When it comes to monetizing and commercializing a F/OSS product, there is often the desire to offer differentiation through features or behavior in the software. This can lead to forking the software to various degrees or reinventing / replacing components or entire stacks.

There is no singular root cause for this, however, which makes it a really interesting issue. Sometimes the differentiation pressure comes from operating in an overly competitive space, sometimes from being in a market that has unique pressures or requirements and other times it comes from the desire to build brand identity. This leads to a situation where sometimes the differentiation is rather frivolous and other times more substantial and the result of a hard requirement."

If such differentiation efforts go wrong, it often will reflect poorly on your project even if it wasn't your fault. If differentiation is too hard, the downstream may look for another project to work with. If it all goes well, you may find a new source for upstream contributions. How we manage this phenomenon to get the best results? Here are some of my thoughts, and I'd love to hear yours as well in the comments section.

Be Aware

If at all possible, keeping some communication open with those who are working with your project is a great idea. This can often help make sure you are aware of what they might be wanting to change. Knowing there's something being shifted around is a great way to catch issues that may result before they happen, which is a great way to help your larger community avoid frivolous or just plain bad ideas. At the very least it can help you make sure that those differentiation efforts don't run into walls that the project team may have unintentionally erected that now stand in the way of these differentiation efforts. Or, if it's one of those twisted scenarios, it may give you the lead time needed to throw up such walls. ;)

Communicate Your Hopes and Dreams

Sometimes people want to differentiate your product in a way that works quite counter to what you have in mind. When this happens, communicate to those downstreams why you feel that way. Maybe they are trying to grab features or code that isn't ready yet (and thereby inflicting great pain on your shared users) in an attempt to beat others to the punch; maybe they are taking the software in a direction that conflicts with other things in the pipeline or which have been tried before and just don't work well; maybe there are opportunities to work together and make something even better. Regardless of the situation, a common cause for mistakes in the drive to differentiate is "we didn't understand the consequences and implications".

Of course, they may not heed your input, but I find that often they will try to and a compromise or even straight out agreement can be found.

Make The Software Flexible

There are going to be some areas in the software that people building products around it are going to want to customize. It could be as trivial as the artwork or template data but it could also be a lot more invasive.

Identifying the areas where such changes are likely to be made can then allow the team to make it easy to make such changes. When it's easy, mistakes will be fewer and the differentiation efforts will go smoother. This is perhaps the most powerful answer to the differentiation challenge because it helps channel efforts (if it's easy to differentiate on A and harder to differentiate on B, many will take the path of least resistance .. which is handy if you want them to stay away from B ;) and can substantially improve the results which in turn reflects positively on you and your project.

Identifying such areas of possible differentiation can happen in a number of ways: clever guesswork based on what you know about your software and the people who use it; talking with the people who are working on differentiation features; watching what different groups tend to add to or modify in your software.

Once identified, think about how to make it easy for people to add unique benefits or tweak what's there properly (whatever that means for your project). Sometimes a plugin interface can make all the difference (avoiding nasty invasive patches being applied to the code base), sometimes scripting interfaces that allow for easy changes at runtime can help, sometimes tools that help craft these changes with or even for the differentiator can be extremely useful. Ensuring that there are clear divisions between data and visualization and other tight-coupling-preventing measures can also help as they lower the cost and danger of changing one specific thing. Perhaps most important is documentation; it is always a winner as it will help people working with your project know what they can do and how best to do it.

When All Else Fails ..

When things turn nasty and a group really bungles up a differentiation attempt and your project is or will be getting painted in a poor light because of it, let that group know that you don't agree with what's going on and why (communication). Perhaps make a polite public service announcement for your users so they are aware of the situation. If need be, distance your project from that particular effort and try to do some damage control. Politely send people who come complaining to you about it politely to the people responsible for the bungle; eventually everyone will get the message.

Due to our projects being Free software, it is impossible to avoid attempts at differentiation being made by others. As much as possible, be accommodating of such efforts and encourage people to do cool things with your stuff. They may do things you don't agree with, but that's the beauty (or price, if you wish to look at it from a negative slant) of freedom. Accepting that can be a great remedy to what could otherwise be frustrating. This doesn't mean you need to be accommodating however; just because someone makes some change to your project that you don't agree with doesn't mean you are now required to offer support to their users for those changes or that your software should be forced to adopt those same changes.

Above all, though, watch what kind of differentiation works .. and then suck the best of those changes into your upstream project so that everyone can benefit.

Read More

flu == documentation?

The P-man (and a few of my friends in town here) had the flu before I left for ABLEConf last week. (I need to blog about ABLEConf as well, but will do so later ..) As luck would have it, it would hit me while I was down in Arizona (I had almost completely lost my voice by the time I left, despite spending the whole last day in bed in the hotel) and I continued to feel "draggy" right through today. So, not feeling up to any overly serious hacking today, I wrote some documentation.

The result is a Runner plugin (as used in KRunner) in KDE Examples and a tutorial on Techbase that goes through the Runner plugin implementation step by step.

It's a first draft and I'm not feeling 100% still, so it will have rough patches still. Please check it out, improve it or ask questions for clarification.

Read More

animations in plasma with javascript on top

We were lucky this summer in that not only did we have a bunch of our own great Google Summer of Code students, but we got one more for "free": a student working with another mentor organization that has a strong working relationship with KDE completed their assigned project rather quickly, and so we inherited them, and another half-project, for the second half of the summer. They worked on animations using the new QtKinetic framework that appears in Qt 4.6 and over the last couple of weeks a number of Plasma hackers descended up on that work. We cleared out some of the lose ends, cleaned up the code, added a bunch more functionality and merged it into trunk this past week.

They are really quite powerful and very easy to use. We're still fiddling with some internal design decisions, but the API is ready to be tested and knocked on.

I recently spent an evening updating the simple JavaScript Plasmoid Engine so we can access them from JavaScript plasmoids. Then today, after spending the rest of it replying to mails and blog comments, working on my presentation for Saturday and closing a handful of bugs in the tasks widget and drag and drop functionality, I did up a small screencast showing the animations in (excuse the pun) action using JavaScript. You can click here to watch it on blip.tv., view it in the embedded viewer below or download the original Ogg file here. Enjoy!

This is all very new stuff, so all the usual "it's only alpha" and "won't be available until KDE 4.4 is released in Q1 2010" apply.

(Oh, and please excuse the cheesy introduction; it was a long day and I couldn't help myself. ;)

Read More

two simple things to improve the user experience

There's a lot of discussion about user experience around these days. That's good, though sometimes the focus is kept on solving "big issues" and a lot of the small everyday type things get missed. Here are two things that I personally run into a bit too regularly that can be easily improved on and which really do help with the user experience.

Jargon Is Bad

We use a lot of jargon when discussing, designing and creating our software. When we're working on something that's complex or new, new words and phrases (or new meanings on old ones) will crop up in our language when discussing it with each other. The world outside our creative circles remains innocent to these new bits of language floating about. This is all well and good .. until the jargon starts creeping outwards and meets people using the software.

In Plasma, we try to keep the jargon we've invented to help us work together out of the user interfaces. It's not a cashew, it's a toolbox. It's not a Plasmoid, it's a Plasma Widget. It's not "Plasma" it's "the desktop shell" or "the workspace" (if we're being more inclusive and talking about KWin, etc as well). It's not a Containment, it's an Activity if it's on a main, full-screen layer (e.g. desktop or dashboard) and something descriptive for the context (e.g. Panel) if elsewhere. It's not always easy because to us these words are just second-nature.

There's a lot more jargon in KDE, though: nepomuk (search service!), krandr (screen settings!), kwin compositing (desktop effects!), akonadi ... If we can keep the jargon out of what we see when using the software, it will help people immensely. We should instead be using terms that describe what it does or why I should care about it when I'm using it.

Micro-Options Suck

KDE has a great history of configuration options. Sometimes, however, we use that as a cop out and instead of making a good decision or a hard decision we make no decision and instead put an option in there. Besides the cost on the code itself (more code paths, etc, etc) there's a cost to the usage of the software.

Every option shown to the person using the software is something they have to read and understand. Then they have to choose whether to interact with that option or not. Is it what they are looking for? What happens if they toggle it? Where is that thing I'd like to control? At some point, people will give up, get frustrated or both. At best it slows them down, at worst it causes them to stop using the software all together.

So when deciding which options should be there, know the audience and its needs (e.g. technical applications will often have a lot more gadgetry to them) and be ready to make hard decisions. If it turns out that it does indeed need to be made optional, it can be added later. Taking back an option once offered is really hard, though. It makes people sad.

The good news is that if a few hard choices are made, including the occasional "no, I'm not going to make that optional even though you and your friend have asked for it nicely", there will be lots of room for other options that are highly valuable and useful.

So think twice before doing the "just make it configurable" dance. It's one step towards how we can have our cake (great configurability) and eat it too (have good looking and highly usable software).

Read More

in Phoenix this weekend

I'll be in Phoenix, Arizona (USA) this weekend attending ABLEconf which is a local F/OSS event that is aiming to increase awareness and use of F/OSS in Arizona. I'll be trying out a new presentation there (something I often do at smaller events) that shares what KDE is doing right now from the lens of fulfilling expectations when it comes to user experience.

If you're in the area, please come check it out. I'm sure we'll have a bunch of fun, or at least some interesting discussions. Besides ABLEconfg itself, I fly in on Friday and leave on Monday, which currently leaves me with a Friday evening and all day Sunday free. If you'd like to meet up then, drop me a note by email.

I used to do quite a few small local shows (including some that have grown to be less small these days :) and I'd like to get back to doing some of those again. I'll certainly be tooling around the Americas more again now that KDE e.V. board duties aren't pulling me over to Europe so often. If you are involved with a good event in the Americas that I should be at to spread the KDE message, give me a shout. (Preferably well in advance of the actual event. :)

(See, I can write short blog entries!)

Read More

kdeexamples

The KDE Examples module is coming along nicely. I spent some time today moving examples from kdelibs and kdebase into it and `tree` now report 71 directories and 130 files. We have examples for KConfigXT, KAuth (new in KDE 4.4), KIdleTime, Phonon (a bunch), Solid (another bunch), Plasma's new QtKinetic based animations (new in KDE 4.4), JavaScript Plasmoids, Ruby Plasmoids and DataEngines, Python Plasmoids and DataEngines and plasma-desktop interactive scripting console.

I'm sure there are many more examples out there to be found and added. If you know of any, either let me know or add it to kdeexamples yourself. If you'd like to write some little examples, that'd be great, too. There are some gems hidden away on pages in Techbase, as well, that need to be reaped.

There is one other thing that I could really use someone's help with: documentation. As usual, I'm stretching the limits of my available time already and it would be great to have mention of kdeexamples somewhere on Techbase as well as some documentation inside of kdeexamples itself describing how to get started with it and what is available. A simple text file could do the trick, old school README style, or if someone is feeling a bit more motivated a nice looking set of HTML files could be pretty awesome.

If you'd like to help add a bit of "welcome to the KDE Examples module, here's how to get rolling" documentation to it, please get a hold of me (aseigo at kde dot org) or find me on IRC and let's get this rolling!

Read More

comparing "KDE 4" and "GNOME 3"

There is small trend currently to write a blog entry or article comparing "KDE 4" and "GNOME 3". Now, I'm not involved in the least with the GNOME 3 efforts (no big surprise there, I'm sure :) so I can't and won't comment on what they are doing now or in the future (they can do so themselves quite well :), but there are two interesting points I keep seeing raised that I really do want to address ... and I don't feel like commenting on every blog post out there. ;)

KDE 4 .. or the KDE Workspace?

What these blog entries are usually comparing is not "KDE 4" with "GNOME 3" but two of the KDE 4 workspace components, Plasma and KWin, with gnome-shell. Little more than that is compared in most of them when the topic is "KDE 4 or GNOME 3?". This is unfortunate because KDE 4 is a lot more than just the KDE Workspace, which is just one product that comes from KDE, just as GNOME 3 will be more than just gnome-shell.

A primary example is the KDE development platform. It consists of KDE's libraries built on top of Qt, Akonadi, Nepomuk/Strigi and others and represents one of the most important products we create. This platform started back in the 90s as a means to an end: getting the KDE desktop workspace functioning and sharing code and functionality efficiently between KDE apps in a way that guaranteed some consistency. These days, while it has kept this same set of purposes as an important part of its mission, the KDE development platform has taken on a much bigger role and a life of its own.

I'd love to see some thoughts that extend beyond Plasma/KWin out there and look at things such as the maturity of KDE's development platform compared to what others are offering right now or, as in the case of GNOME 3, in the near future. I'm really excited how we have Nepomuk shaping up, for instance, or how in the last few releases we have seen integration of KAuthorization which gives us access to PolicyKit (including the upcoming polkit-1 release) on Linux using the same "hide the system level API details" strategy as Phonon, Solid and others which in turn has made the polkit-0.9 to polkit-1 transition painless for KDE applications. We have good, stable libraries built on really exciting technologies. (Just look at what's going on in Qt these days, or Akonadi!)

There are also other products that KDE projects churn out at a remarkable pace as well. Some are released in categorical packages, such as KDE Games (which just got another neat game the other day, a Bomberman-style game which stole some of our time last night here in the house ;), KDE Edu or KOffice; others are released as stand out individuals, such as Amarok. These are all independent projects within the KDE umbrella and most if not all of them are considered part of "KDE 4". They can all be run independently of the KDE Workspace and stand on their own merits.

What I'm saying is that if you lift your eyes up (or cast them further down, as the case may be), KDE 4 is a lot more than the KDE Workspace and we should be sharing those other bits with people too.

"You say you want a revolution"

The other point that keeps coming up is whether there is too much, too little or any actual revolution out there in the workspace. Regardless of what people think of where gnome-shell's approach lands on that scale, there's a subtlety to the Plasma story that I fear may be being missed and it makes me simultaneously beam with pride and cry tears and sorrow. ;)

To be honest: I don't believe in revolutions, because revolutions don't exist except as a story telling mechanism. A "revolution" is a story about an evolutionary series of events with some careful editing: it starts at a random point in time which then gets called "the beginning", skips most of the middle bits and then ends at another point in time convenient to the storyteller that gets called "the exciting end!" If you track beyond the beginning and ends and include all of the middle bits too, it turns out all "revolutions" are actually evolutionary sequences presented in a much simpler (and fun to listen to) way. So maybe we should be talking about the value of different possible evolutionary tracks and what they can or will bring us; talking about revolutions can be left for people retelling our story far in the future?

In any case, several writers have noted that "Plasma" offers a pretty stock desktop with a whole bunch of nice improvements. I would agree there: we've improved the system tray, notifications, widget handling; we've removed a lot of assumptions like "this is the one and only KMenu" or "yes, you must have at least one panel!"; we've added things like a dashboard overlay and multiple widget layouts, extensive SVG based theming and the ability to extend your panels and desktop not only with C++ but also with HTML, JavaScript, Ruby, Python, GoogleGadgets, MacOS widgets and E17 widgets; we've improved workflows associated with device hotplug, application menus, etc. Those are certainly evolutionary and not revolutionary. (Which reminds me, I need to do a new "cool things you can do with KRunner" screencast..)

Beyond what's quite clearly evolutionary, we're introducing things like remote widgets which lets you share and move components over the network between devices without any difficult configuration or set up. A couple of clicks and away you go. We're finally merging Plasma's Activities (multiple widget layouts) with Nepomuk's store and beyond into applications and working on an improved Activities management system. These are a bit more than the usual breed of evolutionary features.

Even then, there's something much more critical to understand here: when I set out to tear apart kicker and kdesktop, the foundations of KDE 3's workspace, I did so with the idea in the mind that this should never need to be so painful to achieve again.

An epiphanous (is that word?) moment for me came in the realization that the current desktop metaphors and ideas are so deeply entrenched in today's users that they can not just be ripped out wholesale and replaced. At least not if you expect any great number of people to actually use it on their desktop or laptop computer. We can evolve it, but we can't just replace it wholesale. But it will evolve and our framework must be able to keep ahead of that curve. That means that even on the traditional form factors of laptop and desktop, the days of building a purpose-built "here's your workspace" system and expecting that to last for any extended period of time are over. The workspace needs to be flexible; it needs to be able to adapt to ideas we haven't had yet; it needs to be able to have a ninja drop into the middle of it and make lightening fast changes to one area to bring that one area forward to the next necessary stage of evolution without running into walls or causing problems elsewhere. It needs to be something completely different than what it is today ten years from now .. without ever being completely rewritten.

Another epiphanous moment (there's that word again!) came when I realized that laptops and desktops were not the only form factors we could target and expect to remain successful with. We needed to build a system that could be remolded with minimal effort and maximal flexibility to fit new places and fit them well. Plasma Netbook makes use of well over a 100,000 lines of code written as part of Plasma for the laptop/desktop space while, by adding a few thousand of its own, offering a user interface that is crafted specifically for the netbook form factor that offers very little in common workflow-wise with the desktop. That means we get compatibility with your desktop/laptop "for free" avoiding the separate silo effect, have invested minimal efforts by changing or adding only what we feel is needed or wanted and can provide something that is both familiar (due to having access to similar features as Plasma Desktop via widgets like microblogging or Google Gadgets) and specially crafted at the same time.

Being able to do this while also being able to deliver a nice and traditional desktop workspace, despite none of that being embedded in the DNA of Plasma itself (it's all in plasma-desktop and a few desktop-specific Plasma plugins), while keeping it all neat, tidy and sane (hacks-be-gone!) has not been the easiest thing to pull off. So I'm really proud when people look at plasma-desktop and observe that it's a nice evolution over what was there before. I also cry a little when people don't realize that there's more to the story. :)

Now, I don't know of a single other serious project out there (in terms of "shipping releases meant for actual production use some day") that is able to pull this same thing off. Do you? Every other workspace project I know is either hyperfocused on one form factor or follows the "here's a toolkit, now rewrite everything above the toolkit for every target application" concept, which is what we've always done in the past.

While designing the fundamental ideas that would later be built by myself and the amazing team of people I get to call my team-mates into this thing called "Plasma", an evolution that doesn't lead to dead ends and lets us sprawl with ubiquity across the computing landscape from device to desktop, from media application to multi-user interaction and wherever else we want to go.

So while we work on the implementation realizations, such as fancy desktop grid effects and what not, we are doing so as part of a big picture that is inclusive of where we've been, where we are and where we may want to go in the future.

Keeping an eye on others without becoming distracted

As a footnote to this entry, I thought I'd share something related but not strictly on this topic that we keep running into with Plasma. We do keep eyes on what others are doing, whether that's Microsoft, Apple, Google, Intel, Nokia, Enlightenment, GNOME or people doing purely academic research work. This helps give us some perspective and reality checks from time to time. It also helps us get some good ideas we may not have come up with on our own. At the same time, we're doing new things in new ways as well, and so while we watch others we also have to remain on guard that we don't end up becoming distracted from our own mission. There's a fine line between keeping tabs on the other cars in a race and chasing their light lights. It's interesting to observe how easy it is for the human mind to start doing the latter. Perhaps that's just part of being a social species?

Read More

KDE example code

When someone wants to learn the techniques and tricks of development with KDE libraries, they can head on over to Techbase. While we have a great amount of information there already with dozens and dozens of tutorials, we're still missing a lot of topics there. We really need to address that over time, but that's a different issue from the one this blog entry is about: example code.

There is a lot of example code scattered around in KDE's svn. Sometimes they are referenced from or even provide the entire basis for tutorials on Techbase. Getting them isn't very convenient or even easy for too many people.

Most of our third party developers do not build KDE's base libraries from source code, they just install the packages from their distribution which only include the binaries, development headers and text documentation. For those that do compile from source, the fact that there are examples hidden here and there is often not known to them. So despite all the work that has gone into those examples that are squirreled away in kdelibs, kdebase and elsewhere, they miss out on what is probably their most important audience.

Inspired by other projects out there, not least of which is Qt with it's inclusion of both an examples and a demos directory in its source tree, I suggested that we should have a "kdeexamples" module. This module would contain as many of our examples as possible and would be offered for download as a single tarball so developers can download them all at once and use them for current and future reference. They may even find a few technologies they didn't even know existed in the process, but more importantly they will have one place to check for examples.

Of course, KDE is a project that thrives because it is people doing rather than people just talking. With some help from the sys admin team (thanks, guys! :) we now have our very own kdeexamples module. You can find it here.

If you have example code that illustrates how to use KDE's various libraries and technologies effectively, please add them to the module. I'll be adding a top-level CMakeLists.txt in a moment for building the examples and examples included should be grouped by topic to make finding things reasonably easy.

A first tarball release will be made as soon as it makes sense to (e.g. there are a significant number of our examples in it) or 4.4 is released, whichever happens first. Personally, I'm hoping for the former. Also, although this is probably obvious: distributions should not package this module as the whole point is being able to study the source code directly. :)

Enjoy! :)

Read More

freedom services

The idea of integrating online services, especially the sort that are (poorly, IMHO) referred to as "cloud computing", is met with resistance by some. The reasons they offer are generally compelling, namely they are concerned about a loss in Freedom. Here we have spent all these years building freedom into our software and along come these online services as an end-run around that, they say.

I actually agree with them on that point: most online services today are not freedom enhancers but freedom eroders. This was equally true of the overwhelming majority of software produced in the 80s and 90s and even much of it that is produced today. Some who have seen the doors close on certain business models framed around proprietary software have tried to dodge this by creating online services instead. Still others have seen the potential of online services and in their excitement and hurry have not considered the implications to the rights and freedoms of those who will use and perhaps even come to rely on their service.

I do believe that there is answer for this, however: Freedom Services. Just as with Free software and its commitments to use, modification and redistribution we need a set of commitments for online services to meet. Then we need to create those services and get people using them.

For the last couple of years, I've been rolling around in my head the question of what those commitments would look like. As we work on exposing online services in our Free software products more and more this becomes a rather more pressing question. Here are my thoughts as they currently stand on what those commitments should be for a service to be considered "Free as in Freedom":

0. Specification: A full specification of the service's complete API must be freely available to all for reference. The specification must also be unencumbered so that anyone else may implement and extend it if they so choose without restriction.



1. Implementation: A reference implementation of the full specification must be made available under a Free software license so that others may study, use and extend it freely.



2. Privacy: A commitment must be made to all users of the service that privacy related issues, such as use or sharing of the user's information, is openly and clearly documented and that any privacy infringing action the service provider partakes in is opt-in by the user. This includes any actions taken by the service outside the scope of the Specification.



3. Data Integrity: A commitment must be made to all users of the service that the data they create is theirs. This means the user must have the ability to easily have their data exported at their request in a useful format to a location of the user's choosing (e.g. a local file or even another service) as well as have the ability to remove any and all information generated by the user of the service from the online service at their request. Should the service shut down for any reason, the user must have a reasonable opportunity to retrieve their data.

Is this even possible? identi.ca comes close, though there is no data export function. opendesktop.org comes close as well, though there is a missing Free software implementation of the specification. So we have gaps to fill and many services to erect beyond that.

A registry of services that match some or all of the above commitments could be quite useful to those of us who care and would like to educate others about the issues as well. It sounds like a job for the FSF or FSFE to me! :)

What would you add or subtract from the commitments listed above? What services would you most like to see completely opened up?

Read More

ah, stats

Cornelius posted a neat summary of the source code heft in KDE's main modules. It was also picked up by some of the general F/OSS community news sites.

Michael Meeks posted an blog entry showing other projects' line count next to KDE's while asking "the real question is not 'is KDE valuable' - of course it is; but how does it compare[?]" In a nicely concise table he shows that Ohloh pegs KDE at 5.5 million lines of code with GNOME at 15.7, Linux at 7.9 and OpenOffice at 8.5 respectively. That makes KDE's code base look smaller in comparison to these other projects, doesn't it?

Unfortunately, statistics are often hard to interpret when aggregated like that. Also unfortunately, Michael's blog doesn't accept comments to it (2000 called and it wants it's blogging software back? ;) so I figured I'd expand a bit on this here.

Cornelius's numbers, as well as the ones on Ohloh, only cover the modules we release as part of the periodic KDE Software Distribution. These are the modules that get known as "KDE x.y". What those numbers don't include is the rest of the code we work on under the KDE community umbrella. That would include all the apps in our Extra Gear repository such as Amarok (175,760 lines), Digikam (478,185 lines), K3B (101,320 lines) and Kaffeine (269,149 lines) to name the four largest. My checkout of Extra Gear contains 1,175,644 lines of code according to sloccount. Also missing from the numbers is the code in kdesupport for things like QCA, Nepomuk and Strigi, Akonadi, Phonon, taglib, KDE/Win utilities, etc. which combined represent some 433,208 lines of code according to sloccount.

Most significantly, however, is the omission of Qt itself. Ohloh weighs it in at 16,028,530 lines of code.

If we look at the Ohloh numbers for GNOME, Linux or OOo they are much more representative of the entire set of code associated with those projects. GNOME, for instance, includes Gtk+ and a comprehensive listing of applications worked on under the GNOME umbrella. That helps explain the 15.7 million number a bit more clearly.

With a similar amalgamation, KDE weighs in somewhere in excess of 23 million lines of code. Even then, nothing is said about code complexity, efficiency granted to applications by sophistication in the lower levels of the stack, etc. That just can't be reflected in such simple numbers as these. Still, it is an interesting data point to look at for what it is worth. (A sentiment that Cornelius shared in his blog entry as well.)

So does this tell us anything useful at all? Well, if nothing else it does show that there is a lot of F/OSS technology out there these days. Between the four projects mentioned here alone there are over 50 million lines of code, and those four projects, while large in their own rights, are hardly the bulk of F/OSS code. That's pretty amazing.

Read More

thanksgiving

Yesterday was Thanksgiving in Canada. (The Americans celebrate it on totally the wrong day. ;) Family and friends descended upon the house here and we commenced to cook up a storm in the kitchen. We used every pot, plate and bowl (and nearly all the cutlery) in the house at one point or another in the day. The result was a very delicious bunch of food: an organic free range turkey (most everyone in attendance was omnivorous), baked mashed yams and sweet potatoes, roasted beats, steamed brussel sprouts and leafy greens, a potato and carrot roast, gravies, stuffings and pumpkin pie. Yum!

Thanksgiving is about more than food, of course. It's about, well, giving thanks. (That and board games, conversation and sharing some drinks with friends. :) I'm thankful for so many things in my life, with my family and home at the front of that list. This is my KDE blog, though, so what am I thankful for right now when it comes to KDE? Here's my non-exhaustive list:

• Qt Development Frameworks for picking up Marco Martin to work on Plasma related technologies. Pure awesome! I really enjoy working with Marco, and I'm happy he now can devote his full attentions to this stuff. I do hope to find more such opportunities for Plasma folk in the future. As the project matures and generates more useful products for others to invest in, I'm hopeful this will happen fairly naturally.


• The KDE PIM folk are communicating more. I took some of them to task recently about the detriments of non-communication and where the responsibility for communicating might lay in a project that has commercial backing. Such dialogs are never the most fun thing one could imagine spending their time on, but several of them did just that, particularly Till. There's been a rolling parade of blog entries and stories that have made it onto community news sites in recent times. For that I'm very thankful to the KDE PIM team. Communication is awesome (and how else would I know how far along Akonadi for Qt, KDE and Gtk+ had come?), improving our processes around it is even more so. PIMsters, keep up the communication, because you rock and we should be able to keep up with that. :)


• User communication improvements are to be seen everywhere in KDE land. From KDE Brainstorm to Userbase to the new crash dialog that has noticeably improved the quality of bug reports since it debuted, these efforts have improved my life. Hopefully they have helped others even more so.


• Our community of contributors continues to do amazing things, and for that I'm very thankful as a user of our software and a member of that community. While the three previous points are more transitory in nature, this one is ongoing. Ever since I started contributing to KDE, the community has been here and been strong. It's the air we breath, and just as easy to take for granted. Thanksgiving is a great reminder for me to stop and take it un-for-granted.

Read More

managing time line mismatches

In a blog entry last week I talked about three challenges that arise as the number of individual groups participating in KDE has grown: time line mismatches, differentiation pressures and confidentiality requirements. I also said I'd write something about possible ways to address each of these issues to smooth out some of the wrinkles they can cause. Let's start with time line mismatches.

In describing this issue, I wrote:

"When a large number of diverse interests come together, each with their own release requirements, market goals and deadlines it becomes inevitable that time lines will not match up across every single participant in the community.

While perfect cadence would be lovely, reality is that different kinds of software and different business interests will have different requirements when it comes to time lines."

A concrete example might be a company working that has a private development contract with a third party that includes working on an upstream piece of KDE. This is actually fairly common and can be seen in Akonadi, Kontact, KOffice and Plasma to name just a few. This may sound like a great thing, but those contracts often come with delivery schedules attached to them. Those schedules may not coincide with KDE's upstream schedules, and diverting KDE's schedules just because company Foo signs a contract this year with government or company Bar doesn't make sense in the least. So what can we do?

Here are some of my thoughts on that question, some (all? :) of which are probably somewhat obvious. As usual, I don't have the definitive set of answers: there are certainly other approaches out there. Please share them with us if you know of some. :)

Communicate

This is the most basic part of any answer: if the larger community around the software knows when your schedules come to a close or when certain milestones must be met then the odds of the rest of the community working to accommodate, or at least not get in the way of, your schedule increases dramatically.

Due to confidentiality requirements, it may not always be possible to be overly detailed about some aspects of the schedule, but almost always it is possible to give at least a general outline of scheduling requirements.

The simple act of communicating has helped us in Plasma a few times, and the lack of such communication has also caused some real problems for us as well. It's amazing how important and useful just one small email can be.

Feature Branches

Sometimes it is necessary to work on features outside of the time windows alloted by the upstream project in which new features can be merged. Feature branches are a great way to work around this. By keeping such development away from the main development area it is often possible to keep feature development going without stepping on the toes of the upstream's schedule.

An important point is to commit to merging that feature branch as soon as it makes sense to do so. Also, as bugs elsewhere are often uncovered while adding new features, make sure that fixes to existing code are either made in mainline and merged back into the feature branch or that the fixes are merged immediately into mainline from the feature branch. This allows mainline to continue to benefit from your efforts and not to diverge too far from your branch when it comes to code not directly related to the new feature set.

Such a "diverge, but as little as possible" approach can accommodate multiple feature set efforts in parallel quite efficiently. Paired with a VCS like git that makes merging easier (than, say, svn *sigh*) features can develop and land fairly independently.

The downside to the feature branch approach is that it gets less testing and can end up conflicting with the design of other features. The more divergent and numerous feature branches get the harder it can be to track each of them and ensure each gets merged in a reliable manner.

In Plasma, when we have feature branches we track their progress fairly closely and try to merge them into mainline as early in the development cycle as possible. This, of course, means knowing when that feature will land, but we rarely have features that take more than two full cycles to implement or that can't be broken up along those lines. We have even taken to doing "merge fests" at our developer sprints, as doing big feature merges in person with a group can sometimes be easier and more efficient.

This helps us keep Plasma from becoming overly "branchy" while respecting the time lines of each developer without keeping the release cycle meaningful in terms of being when we land and integtrate features, test them and get user feedback on them.

Stabilization Branches

Stabilization branches represent the opposite case to feature branches. This happens when someone needs to ship a product around a given piece (or pieces) of KDE while the upstream project is still working on new features or features that are outside the contracted scope. The idea behind such branches is work on stabilization, optimization, etc. of the code in order to make the requirements set out by the schedule.

When the product to be shipped is based on a recent release of KDE this can be very easy: work in the stable branch (e.g. /branches/KDE/4.x/foo/) and forward port fixes into mainline. When the product to be shipped relies on work in mainline or includes features in a feature branch that hasn't yet been merged into mainline, then a new branch may be needed. Remember to merge changes back into mainline as appropriate as you go, however, so that everyone can benefit.

Some fixes aren't merge-able: they might be on a feature not in mainline yet or be an ugly short term work-around for something that is fixed in mainline in a way that can't be in the branch. Those are the exceptions, however, and should remain that way.

The KDE PIM folk have an "enterprise" branch and they regularly merge large sets of patches from that branch into the main line branch. This has proved pretty effective, at least by my observations, in the time they've been doing so. They tend to them in batches, and that seems to be an efficiency measure: they can sift through a number of changes all at once after they've been proven in the stabilization branch and discard the inappropriate ones leaving a batch of commits to process all at once.

I wonder how much of this is done by hand by them (KDE PIM people, any ideas?), and have often craved some nice tools for managing such things. Fiddling with the vcs directly is OK, but I can imagine much better workflows which could be aided with some purpose built tools.

Prevention

Perhaps the most obvious answer to conflicting time lines is to avoid them whenever possible. With one group I worked with this year, we actually pointed out the upstream schedule and the client adjusted their deployment schedule to fit that. This obviously isn't always possible, but it is possible more often than one might at first expect. Upstream doesn't always need to be the point of flexibility, and if the client group has flexibility in their schedule that can often be a much more natural and easy place to flex.

Finis; Now your thoughts?

What methods have you employed to deal with time line conflicts? How well did they work? What are the limitations of them?

The next entry on this topic (in a few days time) will be on the issue of differentiation pressures. It's tricker than time line issues in my experience, so I'm looking forward to writing about it. :)

Read More

walking

One of the great things about living here in Vancouver is that there is such great access to large natural spaces. Stanley Park is awesome, sure, but there are parks, trails, mountains, lakes, islands and beaches scattered all about within reasonable travel distances. You can just as easily make a day trip skiing as you can sailing or paddling as you can hiking in forests as you can laying on a sandy beach (weather permitting, of course :).

This weekend we went for a few hours walk through the woods in Capilano. We passed old growth fir trees towering hundreds of feet above us and walked across a hydro-electric dam and drinking water system that put us 90 meters above the canyon floor. The quiet, moist, chilly air of the forest is somewhere I feel more alive in than perhaps anywhere else. Being out on the ocean is perhaps the only other place that comes close for me.

We can see the mountains and downtown vancouver from the large arched window in our bedroom. The bed looks out through this window so when we wake up we get to see the sun arcing over the hills to pour down upon the high rises in the mid-ground and the mountains in the background. At night, we see the opposite dance. Unlike the forest, however, I'm not even close to alive when sleeping.

The other night S. woke me up to ask where something was downstairs that she wanted to go get. Apparently, I rolled over, sat up on my elbows with eyes wide open and suggested looking for the circular thing on top of the couch in the living room. There is nothing circular around the couch. In fact, I don't remember this conversation at all. Much confusion ensued.

Today I've been sketching out how I want to start tackling parts of the new overview system for Activities in plasma-desktop and working a bit on some business planning issues. Boring stuff, but perfect for my mood today. I'm not really feeling much of the code writing hunger today, which makes it perfect for taking on other tasks that need doing as well.

Read More

device notifier work for 4.4

It was interesting to read Johan Thelin's blog entry on moving to KDE 4, particularly how much he likes the device notifier. I say this because that Plasma widget has been seeing a flurry of activity for KDE 4.4 so the timing was pretty neat.

The device notifier debuted in KDE 4.0 and the primary goal was to make the announcement of devices that become available during a session feel more organic. As a starting point, we harmonized it with the desktop workspace by providing a Plasmoid for this functionality. In past releases these announcements were accomplished using a pop-up dialog using a window that looked like any other application window.

In KDE 4, we've tried to make a clear distinction between what is "application" (and therefore the use focus) and what is "workspace" (and therefore is perceived as part of the "system" and separate from the application). This separation allows the user to focus with clarity on the task at hand while allowing the workspace to both communicate with and provide opportunity for interaction in a clear fashion.

Having device announcements happen as part of the workspace user interface was therefore a natural decision, and Alexis made that idea a reality with the first version of the notifier. It was decided that device notifications have some similar but mostly different usage requirements than other system notifications, so a separate Plasmoid was created along with a couple of DataEngines (hotplug and soliddevices) for easy of re-use by other Plasmoids that may come along.

Although there were some nice improvements over time to the device notifier widget, there were several areas of potential improvement. For one, it never looked as visually continuous with other Plasmoids due to using a standard Qt list view rather than something on the canvas. For another, it fell back to using a pop-up dialog when there were multiple available actions for a given device.

The device notifier saw one full rewrite attempt but that effort didn't achieved a final production state. Recently, it saw another, this time thanks to the combined efforts of Giulio Camuffo and Jacopo De Simoi, with Marco Martin and I helping out with feedback and some patches. The new Plasmoid is in kdereview and will be a part of KDE 4.4. There are still a few areas of polish left (biggest remaining TODO is keyboard navigation) but given Johan's blog I figured it might be nice to share what we have now.

As you can see in the screencast (which has no audio) below, the new widget rather nicely addresses both of the major outstanding issues with the current device notifier. It also adds two new features: the ability to hide certain items and the ability to also display fixed devices. Both are optional and don't interfere with the primary interface and only one new item appears in the configuration dialog.

You can grab the OGG file here or watch the screencast via blip.tv below (though it is inexplicably enlarged; very odd):

Read More

managing change during KDE's evolution

KDE has gone through an impressive evolution of organizational, procedural and community related changes over its lifespan. What started out as a "in-our-spare-time" project became a critical component in many F/OSS operating systems. As the various KDE projects grew, matured and in some cases retired the number of distinct teams and sub-communities grew in both number and diversity. An ever growing number of companies from small to large grew out of or joined the KDE community along the way. Our non-profit, KDE e.V., has gone through a similar evolution in complexity, transparency and professionalism.

What I've always found intriguing and impressive with KDE's evolution is that as a community we have managed to find a good blend between openness, decentralization, oversight, corporate involvement, entrepreneurship, community, fun and seriousness. We have a fine balance between the community and the corporate, the adventurism and the professionalism. This has been achieved by keeping a shared alignment of our incentives and goals, regardless of who we are and why we are individually here. Such a balancing act of unity is not common in communities of our size.

Of course, success is often rewarded with challenges that spring up along the way, and the growth and rise of economic interests within and around KDE has brought with it new challenges for us to deal with. I have noticed three potential rift creators becoming more common and it would probably be good to discuss them openly as a community. By paying attention to these issues we can smooth off the rough edges and keep our unity intact for many more years to come.

What are these three fault line producers? In no particular order:

• Time line mismatches


• Differentiation pressures


• Confidentiality requirements

I don't want to discuss possible solutions in this blog entry, but rather just outline what these challenges often look like.

Time Line Mismatches

When a large number of diverse interests come together, each with their own release requirements, market goals and deadlines it becomes inevitable that time lines will not match up across every single participant in the community.

While perfect cadence would be lovely, reality is that different kinds of software and different business interests will have different requirements when it comes to time lines. We have a terrific melange of upstream projects, contract software developers who are beholden to client time lines, device manufacturers tracking the cycles of their target markets, operating systems vendors and deployment specialists that all have time lines that follow unique demands. It is natural that they all want, or even need, to see features land, stabilization goals met, etc according to their time lines.

Sometimes development is rushed forward or held back due to time lines being at odds with other. The question here is how best to accommodate differing time lines as best we can.

It's either that or figure out how to magically fix the world so everyone's deadlines fall on the same day. ;)

Differentiation Pressures

When it comes to monetizing and commercializing a F/OSS product, there is often the desire to offer differentiation through features or behavior in the software. This can lead to forking the software to various degrees or reinventing / replacing components or entire stacks.

There is no singular root cause for this, however, which makes it a really interesting issue. Sometimes the differentiation pressure comes from operating in an overly competitive space, sometimes from being in a market that has unique pressures or requirements and other times it comes from the desire to build brand identity. This leads to a situation where sometimes the differentiation is rather frivolous and other times more substantial and the result of a hard requirement.

The worst thing that can happen in all of this is that efforts get lost. Open source as a methodology has some inefficiencies baked into it compared to other methods, but it is made up for due to many people working together (lowering costs and increasing utility) and various results that come from freedom (such as consumer confidence in longevity or availability). When efforts become divided due to unreconciled efforts motivated by differentiation, some of that advantage is lost.

Finding ways to avoid unnecessary and gracefully accommodate necessary differentiation efforts is important to keep our efforts efficient and our community bound together as a whole rather than splinters.

Confidentiality Requirements

Right now I'm working on a couple of projects for which I've signed NDAs (non-disclosure agreements) with partner companies. In other cases, I've simply given my gentleman's word of honor to keep information under wraps. At the same time, I'm as open as possible about what I'm working on particularly when it touches projects I share with others, such as the Plasma Netbook initiative. Such confidentiality is very common, both amongst open source projects in incubation and (even more so) in corporate projects.

Privacy in projects isn't always an evil thing: sometimes a business deal isn't complete and nothing can be said until such time as it is. Sometimes confidentiality is actually not needed or not worth it given the impact on the health of the community.

The biggest risk in confidentiality is that it creates schisms between people in the same project or community and can easily lead to retrograde patterns such as different groups working at odds to each other without even knowing they are. Being able to identify when and where confidentiality is sensible or not and how to encourage and preserve an "openness first" mentality will remain a vital endeavor in keeping our communities well-formed and the process efficiency high.

Lions, Tigers and Bears!

Fortunately the three issues of time line conflicts, differentiation pressures and confidentiality requirements don't come up often in our community with negative results. However, as KDE continues towards greater scope and sophistication, an increasing incidence of these three patterns can be expected.

It is therefore a good time to discuss and determine our shared expectations openly together. So while I don't want to cause people to run around fearing the sky is falling in (it's not even close to doing so :), we may want to pause and share our thoughts on these things.

Over the next few weeks I'll be putting together some of my thoughts on possible approaches for each of the three issues, and I'm looking forward to hearing your thoughts and ideas on them as well. :)

Read More