Choosing a project for Hackweek 6

It's Hackweek again in SUSE land for the next five days. It's the sixth edition and there already is a nice list of projects in openFATE.

I haven't decided, what I'll work on, yet. There are four projects I'm thinking about. I entered all of them in openFATE for now, will sleep for a night, and then take a decision tomorrow morning, when I'll start hacking. If you have input, preferences, what you would like to see happen, or if you would like to join me in one of these projects, please let me know.

These are the projects I have in mind:

Developer sprint support tool

We have discussed this a couple of times in the KDE community, as there are happening a lot of sprints there, and it would be great to have a tool, which supports taking care of the administrative aspects, helps with reporting of results, and supports the productive process. This would be a nice one-week project, especially, if somebody else would like to join the fun and help developing it. It would certainly also benefit openSUSE and other communities.

Read more in openFATE #311141.

One-click appliance installer for SUSE Gallery

Once-click install works nicely in openSUSE for packages. But we don't have a comparable mechanism for appliances on SUSE Gallery yet. It would be great, if you could just click on a button on an appliance page in SUSE Gallery and the system would automatically take care of installing the appliance, so you could use it right away. This could simply be downloading it and running it in KVM or something different depending on the type and content of the appliance.

Read more in openFATE #311142.

Alternative configuration backend for KDE applications

This is a fun idea from the area of cross-desktop configuration. It wouldn't be the first attempt to come up with some cross-toolkit, cross-desktop, cross-platform configuration system for desktop application, but I'm not aware of any attempts from this angle so far. The idea would be to extend kconfig_compiler to support other configuration backends than just KConfig. This could be QSettings, or dconf, or something completely different. There probably are some practical obstacles I didn't consider yet, but it would be interesting to see, if it's possible to move KDE apps to use a GNOME configuration backend by a simple recompile.

Read more in openFATE #311144.

Humane address book for the cloud

This project goes back to some of my roots. Something like ten years ago I rewrote the KDE address book library and worked quite a bit on KAddressbook, the application to handle contacts in KDE. Back at that time I was deep into the vCard format, and thought it would be a good idea to give the user all the power the format provides. While a couple of good things came from that, I now think, that this approach was a bad idea.

Address book data should be handled in a way, which is more natural than assuming people are just a list of alphabetical ordered contacts with a lot of sophisticated data fields. Especially these days, where lots of personal data is stored in the cloud, there must be better ways how to make use of the technology we have at hand, and put it to use in a way, which puts people first, and the way how they think about dealing with their data, information about other people, and their relationships to them.

Read more in openFATE 311143.

A week in the life of a KDE e.V. board member

Did you ever want to know how life as a KDE e.V. board member is? From the questions I get I know that at least some of you do. So here you go. I took some notes last week to give you a brief impression of what I did in my role as board member of KDE e.V.

Saturday

Domains. As legal representative of the KDE community, KDE e.V. owns most of the central KDE domains, most prominently of course kde.org, but also a couple of other domains like the main KDE domains in some countries. This comes with a certain amount of administrative work, such as domain transfers and a bit of technical administration like updating of name servers. Today the domain of our wonderful Indian community needed some care. This also triggered a discussion with the sysadmin team and we came up with a way to simplify the domain handling by delegating the name server administration. Will make things easier in the future.

Diplomacy. The board of KDE e.V. is one of the few groups of people in KDE, which is formally elected. Thanks to German association law, which is the governing law for our organization, this is a very solid, well-founded, democratic process. So the board is well legitimated to represent KDE. This comes with responsibility, as sometimes the board is asked for official decisions and guidance. Today we had to deal with one of these requests. These issues are not always easy to handle. While they certainly are one of the more challenging parts of the board work, I think they are also one of the more important parts. Having the board to handle these issues allows the community to get things moving, where it would be much harder without officially legitimated people.

Administration. Running an organization like KDE e.V. with its 400 members, its 300k EUR budget, its responsibility to support a global community, comes with a good amount of administrative work. Fortunately we have Claudia, our business manager, in our Berlin office, to handle a good deal of it. But there always is something left for the members of the board, be it deciding about reimbursement requests, handling membership data, moderating the board mailing list, or something along these lines. This creates some steady inflow of work. I usually take some time on the weekend to handle at least some part of it.

Email. The board acts as a point of contact for KDE as a whole, and for KDE e.V. in particular. So we get a lot of email. Answering this is of course part of the daily routine of the job. We handle that as a team, and usually it works well. If you have to wait a little bit to get an answer from us from time to time, please bear with us. Sometimes it just happens that we are all busy. But we will get back to you, and in case it takes too long, please send us a gentle reminder.

Sunday

Preparing board call. We have a bi-weekly conference call with the board and Claudia every second Monday. This is the place where we discuss our daily business and handle stuff, which is not as easy to handle on the mailing list. It also helps to align us as a team. Today I prepared the agenda for the next call, quite packed this time.

Writing dot story. KDE is a partner in the EU research project ALERT. We were looking for a few community members who work on this project and bring in their KDE expertise. So I wrote a dot story announcing the open positions.

Monday

Board call. Today we had our bi-weekly board call. It's not always easy to find a date and time for that which suits all board members with their different requirements in terms of other things to do and taking into account the different time zones in which we are. But we found a 45 minute slot in the early European afternoon, which seems to work quite well. The meeting minutes are sent to the members after the meeting. Amongst other topics we discussed the quarterly reports. We have a new design, which is coming along nicely. Should be ready to be published really soon now.

Reviewing dot story. Our promo team does a marvelous job with making dot stories ready for publishing and getting them out of the door. I reviewed a few iterations of the ALERT story until it was ready to go out.

Tuesday

Call with startup company. Today I had a call with the managing director of a German startup company. They are creating a product based on KDE, and I helped them to find their way into the community. This is one of the nice aspects about being one of the central points of contact, you learn about exciting projects first-hand. This particular one is interesting. You'll hear more about that in the next time.

Wednesday

Taking a break. Board work is volunteer work, and all board members have a day job, family, and whatever else real life provides for us. I took a break from KDE e.V. work today, and dealt with some of these other things I'm doing.

Thursday

Desktop summit program committee. I'm part of the program committee for the Berlin Desktop Summit conference. It's not directly part of my board job, but it comes close, as organizing Akademy or the desktop summit as joint event with the GNOME community, is one of the most important activities of KDE e.V. So I spent some time on getting the KDE members for the joint program committee together and get this going. We have a great selection of people from the two communities, and I'm really looking forward to create a great conference program for the desktop summit.

Friday

Reviewing applications. As response to the dot story a couple of applications for the ALERT jobs came in. I reviewed them and prepared them for further selection in the hiring committee of the ALERT consortium. We got good response, high quality resumes, so we'll be able to fill the positions with competent community people.

Discussion on membership mailing list. Luckily our community is an active bunch of people, who enjoys some good discussion from time to day. So today one of these discussions came up on the membership mailing list. I felt inclined to chime in. But there already were a lot of good contributions to the discussion. Usually I'm pretty impressed by the quality of the communication in the membership. It shows that we are a mature community.

Call with Claudia. KDE e.V. has one full-time employee, that's Claudia Rauch, our business manager. She is responsible for interacting with our partners, organizing Akademy, handling KDE sprints, running the KDE office, and much more. It's a bit of an unusual situation, as with the board she has five volunteers as bosses, which are all remote. So this is not the usual management situation. We handle that by distributing the related tasks relatedin the board. One part of it is having a call from time to time to make sure things work well, issues are resolved, and to keep in touch.

So that's my notes for now. It turned out to be a relatively typical week. But I have to say that no two weeks are the same. That's part of the fun, and one of the reasons, why I'm doing this for more than five years now. If you have more questions about the work of a KDE e.V. board member, please feel free to contact me. I'm always happy to tell you more.

Finally, if you are a member of KDE e.V. or the wider community and would like to get involved with some of the tasks, don't hesitate to get in contact with the board. We can't delegate everything, as some things have to be done by the actual board, but there certainly are tasks where help is possible and very much appreciated.

The role of KDE e.V.

I wrote this article for KDE e.V.'s quarterly report Q2 2010. I'll reproduce it here in case you haven't seen it yet.

From time to time we hear the question, what actually is KDE e.V., what's its role in the KDE community? Let me try to answer this question here.

In short, KDE e.V. is the organization, which represents, supports, and provides governance to the KDE community. It gives the community a legal body so it can participate in activities which require a legal representation, somebody handling money, or a way to legitimize individuals to speak and act for the community.

Before I go into some more details of this threefold role of representation, support, and governance, here is a brief explanation of how KDE e.V. is set up organizationally.

KDE e.V. is incorporated as a non-profit association according to German law. The e.V. actually stands for "eingetragener Verein", which means "registered association". This is a very common legal form in Germany, which is used by hundreds of thousands of associations covering all kind of different activities from sports to animal rights to free software. This organizational form provides a very solid legal framework, which makes sure that questions about who can be a member, how decisions are made, how representatives are elected, how budgets are handled, and many other things all have well-defined answers. It also ensures that members are in control of what's happening in the organization.

Many other free software organizations have foundations as representing organizations similar to how KDE e.V. represents KDE. KDE e.V. is also recognized as tax exempt by the German financial authorities as its goals and activities are targeted at the public good. This also means that at least in Germany donations and membership fees provide tax benefits for donors and members.

The membership of KDE e.V. consists of the core of the KDE community. New members are voted in by the existing membership and the goal is to have a good representation of the overall community as members. Currently there are 165 members which are elegible to vote about KDE e.V. decisions.

But now back to the three roles of KDE e.V. in the KDE community; representation, support, and governance.

Representation is the most formal aspect of KDE e.V. A community like KDE - dynamic, distributed, mostly made of volunteers - has no natural way to handle situations where it's required that someone officially speaks for the community, signs contracts, or accepts money. This gap is filled by KDE e.V. Because its members are representing the core of the community, and because KDE e.V. owns some of the central assets of the community like the trademark and the domains, it can act on behalf of the community. The legal structure of its incorporation makes sure that this is handled properly and KDE e.V.'s activities actually represent the intention of its members.

So whenever a formal representation of the KDE community is needed KDE e.V. becomes active. This can mean signing contracts in the name of the community, it can mean accepting transfer of rights, e.g. with the Fiduciary License Agreement, or it can mean providing a way to give money to the KDE community.

The second important role of KDE e.V. is supporting the KDE community in creating free software. Because KDE e.V. acts as central broker of resources, it's able to provide financial support for a lot of activities. This shows in developer sprints, the annual Akademy conference, travel support for community members to all kind of community events, and the people we employ in our office, who provide organizational and administrational capabilities to the community in all kinds of different ways. This support would not be possible without the many donors and supporting members of KDE e.V., help which is very much appreciated.

In addition to the material support, KDE e.V. also provides other support. It provides a forum for the core of the community to discuss and make decisions. It also acts as a central point of contact, and is of course also an important part of the identity of the KDE community.

Last, but not least, there is the governance part. This is dominated by one important decision KDE e.V. has made, which is the decision to not control the process of creating the KDE software. KDE e.V. explicitly leaves that to the proven open source development processes, with its focus on peer interaction, deciding by doing, and all the other meritocratic elements, which found the huge success of this model. So KDE e.V. does not decide about technical questions, release schedules, what software to include, or how the community is organized in terms of software development.

Sometimes it's still needed to have a way to legitimize individuals or groups of community members to act in some official capacity. That's where KDE e.V. takes on a certain degree of governance. One example of this are the working groups of KDE e.V. which include, the community working group, the marketing working group, the sysadmin team, or the board. They are endorsed by KDE e.V. and so are able to act for the community and sometimes make decisions in the areas where this is needed. This mostly boils down to a question of representation of support again, which somehow closes the circle.

The value of KDE e.V. for the KDE community can't be underestimated. A community of this size couldn't work effectively without a mechanism to bring together representation, support, and governance roles. KDE e.V. has grown and is still growing together with the community from its inception in 1997 to these days of 2010, and a lot of this common growth can be attributed to the healthy and effective relationship between the KDE community and KDE e.V. as organization behind it.

Archibald

Almost five years ago, at the traditional KDE PIM meeting at Osnabrück, I drew the first version of the Akonadi architecture on a whiteboard. It felt appropriate to put the server into the center and arrange the different layers of the system around it in circles. The result was a beautiful diagram.

Trouble stroke, when I tried to create a digital version of the diagram. Putting texts on rounded shapes and arranging partial circle sections in a nice way was too much for all vector and diagram drawing applications I tried. So as a hacker, how do you solve problems? Right, you do it in software. So I wrote an editor for the diagram in Qt.

The mission was accomplished, the diagram up on our web pages. So the code for the diagram tool got buried under a pile of other stuff on my harddisk. But last winter, again at the traditional KDE PIM meeting at Onsbrück Steve reminded me of the tool by showing me an updated version with the then current state of the diagram, and a bit later at FOSDEM Paul complained that Kolab didn't show up in the first version. So there clearly was a need for an updated version of my tool.

After a little bit of hacking the tool is now able to handle multiple versions of the diagram, and here is a view of Kolab in the Akonadi architecture.

While hacking on the tool I also moved it into a git repository and published it on github. So if you want to have look, or if you feel inclined to play around with the Akonadi architecture, go ahead and clone Archibald. Let me know, if you do something interesting with it. I'm curious.

ownCloud in a box

I had some free minutes today at Akademy, so I decided to build an ownCloud appliance. I did a few iterations in SUSE Studio and there you go: ownCloud in a box.

The screenshot shows the ownCloud web interface running in a testdrive on SUSE Studio. The appliances is available as live CD, USB image, virtual image for VMware, VirtualBox or KVM, or as disk image. This should make it really easy to run your own ownCloud server for just having a look or for quickly getting an instance up on some computer.

It's a first version, so don't be too surprised, if there are still some issues. Feedback is welcome as always.

Akademy 2010

I'm on my way to Tampere for Akademy 2010. It's my seventh Akademy, not counting Kastle in 2003, the first KDE conference, which became the predecessor for all the Akademy events following afterwards. I'm especially looking forward to Akademy this year, because there are so many interesting topics to discuss, which could make a big difference for KDE in the future. So here are a couple of the things, which I'm particularly interested in this year:

Conference: The conference program is excellent as always. It's great that there is a strong mobile track. This is a still uderused potential for KDE, and I would love to see KDE expand much more in this area. Many years ago I wrote KOrganizer/Embedded which ran on a PDA, but I'm still waiting for the moment where I have a device running KDE software, which I actually want to have with me all the time.

BoFs: The BoF sessions are always a very important part of the Akademy experience. This is where actual work gets done, and where plans are forged. I'm involved in running three BoFs this year about KDE documentation, one about the supporting membership program, and a session about KDE e.V., which the board would like to use to answer questions about KDE e.V. and discuss what people expect from KDE e.V., and how we can improve and excel. They all will be interesting and I'm of course looking forward to attend some other BoFs as well.

Meeting old and new friends: KDE is an amazing community. Akademy and other meetings always feel like meeting friends, even if you haven't ever seen the other people before, and maybe just exchanged a couple of emails. So I'm looking forward to meet older gentlemen as well as the young and wild new members of the community.

Thinking future: Akademy always is a place to think about the future of KDE, of our community, our software. This year this is particularly interesting. There are a lot of interesting developments, be it on the hardware side, where devices which could run KDE software are becoming much more diverse, or be it on the software side, where web applications and the associated technologies, or new platforms like MeeGo or Android are having lots of momentum. So I hope we can have some serious and creative discussions about how and where KDE can find its place in this universe today, and in the coming years. Our potential is huge, bit we also have to make use of it.

There certainly is lots more exciting stuff happening and going on at Akademy. Let's see what it brings. And now...

Hackweek V: Graphical SUSE Studio Client

Hackweek V is over and I can happily report success. My graphical SUSE Studio client is functional and has the first cool features implemented. The focus of the client is not to duplicate the functionality of the SUSE Studio web interface, but to provide those features, which are hard or not possible to do on the server. This is stuff like managing downloads, running and deploying appliances locally, or native access to testdrive. From this list I got the native testdrive done. On the click of a button, the client starts a testdrive on the SUSE Studio servers and then connects with an embedded native client. This gives great performance and a very smooth and integrated experience.


The client uses the HTTP API of SUSE Studio to talk to the server. This way it gets the list of appliances and builds of a user and can operate on this data. It does some local caching of results of HTTP request in order to provide a very responsive user interface. The client is implemented using the KDE development platform, which provides all the bits and pieces to do the UI, to perform the HTTP communication, and also the embedded VNC viewer. It's pretty much standard technology, but I'm still amazed of how well all these pieces fit together and how easy it is to write such a client, which allows to move into areas, which aren't covered by the web application.


One detail of the implementation is particularly interesting, that's the XML parsing part. The REST-like API, which uses XML over HTTP, obviously involves quite a bit of XML parsing. Usually this is tedious code to write. This always annoyed me, so I wrote a tool to generate the parsing code, KXML Compiler. It's one of my hobby projects I work on from time to time since a couple of years now. It takes an example XML file and generates C++ classes from that, which represent the data, including parsers and writers from and to XML. So the application developer gets a nice native API to the data represented in XML without having to write any code. The tool works well for my use cases, but of course there are quite some situations, where it could produce better results or where it doesn't cover everything, so it sometimes needs fixes and improvements when taking on new data. It's an ongoing project and quite some fun as it involves some mind-twisting metaprogramming. The code is hosted as part of the Kode repository on github.

The code for the client is hosted in the Studiosus repository on gitorious.org. Some more information about the development during this hackweek can be found in my Hackweek blog.


Hackweek was fun. I'm happy about the progress I made. It also was great to see some of the other exciting projects which were done during this week. This is a fantastic way to stimulate innovation. I'm really looking forward to see more of what came out of this week and what future hackweeks will bring.