Submit your proposal now.
Thursday, March 24, 2011
Show us your work on the free desktop
The deadline for the Call for Participation of the Berlin Desktop Summit is approaching. The deadline for submitting proposals for presentations and lightning talks is tomorrow. So you still have the chance to submit a presentation and talk about your work on the free desktop at the wonderful event in Berlin that the desktop summit promises to be. It takes place from 6th to 12th August this year and combines the annual conferences of the KDE and GNOME communities.
Some of you might think that your contributions to the free desktop to the event are not relevant enough to warrant submitting a talk. That often is not true. While we will have well-known speakers who have done ground-breaking things on the free desktop, we all have started small, and sometimes especially the small projects, which are still young, are the most interesting ones to hear about. So please don't hesitate to try it, submit a presentation, talk about the projects you are passionate about, share the love for the free desktop with the community. Berlin is the right place for this.
Submit your proposal now.
Submit your proposal now.
Monday, March 14, 2011
It's not an address book
It began about ten years ago, when I rewrote the KDE address book library. I implemented a nice API, vCard parsing, and a representation of something I called an Addressee back then, a contact, the data belonging to a person or any other entity, closely modelled after the fields of vCard, which is a fine standard for storing and exchanging address book data.
We wrote KAddressBook as an application to manage contact data on top of the address book library, and while it's a nice and useful application, in some ways it still follows to some degree the technical thinking coming from the structure of the underlying implementation. This shows in the user interface, and makes it less useful, attractive, and intuitive as it could be.
So I thought it would be a good idea to experiment a bit and approach the task of handling people data from the other direction. Ignoring technical aspects of the implementation, or constraints of underlying technology, but thinking from a user's point of view, thinking about what's a natural way how to deal with this kind of data. I started to think and code a bit, and during Hackweek 6 I went on and got the application I started to a level where I think it's time now to share it and gather some more feedback.
But before I come to the application itself, here is some of the motives and concepts behind it.
Mental model of people
The first thing I did was trying to come up with an idea of what the mental model is how people think about people. The way address books usually present this data is practical in some ways, but when you think about other people, do you have an alphabetically ordered list of names in your mind? Probably not. So I collected a list of concepts, which better address the mental model of people.
Groups. People usually belong to some groups. There are colleagues, friends, familiy, the weird group of hackers you hang around with on IRC. These groups are often used to classify people, and provide a pretty solid way to structure how you organize people, the KDE guy you met at last year's Akademy, the colleague who used to study with you at university. People often belong to multiple groups, and sometimes there is no clear mapping.
Pictures. When thinking of people you usually have some kind of picture in mind. You would recognize most persons you know on a photo without effort. Pictures are widely used to identify people, and pictures of people, especially of people you have a closer relation with are easily available from various sources now.
Fuzzy information. In many cases the information you have about other people is somewhat fuzzy. You might not know the exact address, just a city. You might only know a nickname, or the date of the birthday, but not the year, or you might have trouble assigning the parts of a foreign name to the fields of a technical address book. Is it a middle name or is it part of the given name? Is this the surname, or maybe a suffix? While it's nice from a technical view, to have this exact classification of fields of a record, in practice and from a human point of view, it often just is neither possible nor important. Humans deal with fuzzy information pretty well, especially when dealing with other people.
Time. An important factor to classify information is time. You remember that you met a person at a certain time. When having multiple phone numbers available, the time, when you got them, will give an important hint about which one is more likely to work. In general, knowing when something changes, helps a lot with navigating information.
Space. Another important factor is space. You think of people being close to each other, either physical, as in neighbors, or in a logical way, as in family. A family tree is a great example how space is used to organize and structure people. There are also numerous other ways how to relate people in a spacial configuration. How they appear on a photo, a seating order for a celebration, and many more.
It's not paper
In addition to coming up with a way how to meet the mental model of how people think about people, I also wanted to take benefit of having available the power of managing the data on a computer. There are many address book applications which resemble paper address books, going as far as mimicking the texture of the leather cover. But being able to manage the data electronically without the restrictions of paper, leather, and spiral binders, gives some unique freedom and potential in a couple of areas.
Ubiquity. As it's so easy to store, transmit, and distribute data electronically, data can be ubiquitous, it can be available at work as well as at home, or when being on the road, on your laptop, phone, tablet. It can live in the cloud, easily accessible from everywhere.
History. Without the restrictions of paper, there is no reason to ever delete data. You can keep an unlimited history, which gives you the safety to always being able to go back, if you have changed something you later realize you didn't want to change, or if a need to access old data arises. This all can be done in a way, which hides old data from the current view, to not clutter the most recent view you normally use.
Low-cost editing. With electronic data, the cost of editing, rearranging, duplicating, and deleting data is very low. You can easily duplicate a set of entries about people to do some rearrangements, and then delete it again after a few minutes without loosing anything. No striked through entries, no wasted pieces of paper, no mess of failed attempts to get something done. This provides the opportunity for ad-hoc editing, especially if combined with some kind of history.
Connect to the cloud. A ton of personal data lives in the cloud, on various web sites, in structured and not so structured ways. With Facebook, Google, Linkedin, your corporate directory server, the data on your private mail account and much more, you have access to a lot of data from the people you usually deal with. By putting an application at the right place, you can connect all this to represent your personal social network.
Unconstrained user interface
Finally I wanted to go beyond the standard user interface of current address book applications. There is much value in standardized interfaces, taking into account style guides, using standard components, and all the other good stuff of working in a nicely defined, consistent, and integrated environment. But I wanted to experiment with leaving this behind and trying some non-standard concepts.
So I decided to not care much about standard widgets, to get rid of everything, which was non-essential to the actual application, to use animations gratiously to make the interface dynamic and support the user in understanding transitions. I also decided to try a new kind of menu, which isn't seen much on desktop applications, but could give more direct access to the actions the user needs. Finally I also decided to create a UI, which is not limited to a specific form factor, but can deal with a variety of devices, not only classical desktops, but also stuff like tablets, or maybe even phones.
Polka
Now that you know where I came from let me introduce you to my experiment. I call it Polka. It's an application for dealing with people data based on the concepts I described, thinking from a user's point of view, matching the mental model of how we think about people, and not caring too much about the current status quo in terms of address book applications. I summarized that in the FATE entry for my hackweek project, where I called it the humane address book for the cloud. The title came from the idea to approach an address book not from the technical point of view, but from what is relevant for human users, and to tie it to all the data and functionality which is available in the cloud.
I started to think about this quite some time ago, and did write some code here and there, but during last hackweek I made the effort to actually put it all together and polish it so that it hopefully adequately illustrates the concepts I wanted to experiment with.
Let me explain some of the main elements of Polka.
Group view
The central part of Polka is the group view. It shows a group of people and possibly some sub groups. The display is based on people's pictures and makes use of the view as a kind of canvas, where the members of the groups can freely be arranged. Names are shown for entries where no picture is set, and they are shown for all entries, when hovering over with the mouse pointer, so it's easy to identify people.
By default all people are shown in a compact regular arrangement, but you can simply move all entries around to create a different arrangement. The next screenshot shows an example. It's the group of people, who attended the Osnabrück 8 meeting. The arrangement reflects where people were on the group photo.
That's just one application for arranging people freely. You could also reflect breakout groups, seating orders, a family tree, or any other relations between people. The basic idea is that you use space to naturally reflect how you are thinking of people. People can be added to as many groups as needed, and any group can contain other groups with the same or different people. The arrangement of people is specific to the view of the group, but the entries of people are always the same, they are just links, so a person can appear in multiple groups, but the data is only there once.
Menus
For menus and getting access to actions in general I wanted to experiment with something different than the classical menu bars and context menus, and see if I could find a way to make it more natural and direct to work with the elements shown in the user interface. So I got rid of all traditional menus, no menu bar, no status bar, no right clicks.
In the previous screen shot you can see how you get access to actions for a person. If you hover over a person, there is shown a fan-like menu, where you can select some person-related options. For general options there is the "main" menu disk at the top right, which also shows actions on hover. You can also click on the canvas to get options which are related to a certain location like adding a label.
This all is pretty simple, and you don't even have to be very exact, when hitting a menu, so it probably would also work with a touch screen, although I didn't try it, so take this with a grain of salt.
Person view
When you click on the "show" menu item, a detailed view of the person is shown. It includes all the data you store about this person. This is the usual contact information, but most of it is stored in a relatively free form. You don't have to identify components of the name or the address for example. They are just text fields. You can also easily add free form text by adding comments to every field of the person's data. The speech bubble indicates where a comment is there, and you can add general comments to the person's entry. All this helps dealing with the fuzziness which data about people often has.
When you hover over a data field, some editor controls are shown to comment, edit or remove the field, and the information is shown when the fields was modified the last time. This way you can judge, which fields are relevant, and which ones might be outdated, and it also can help with putting the entry in the perspective of time, they might be related to something which happened at a certain time you remember.
An important element are the pictures of the person. Polka collects pictures from different sources on the web, e.g. from your Twitter profile, and you can easily add more pictures by using a built in screenshot function. So if you see a picture of a person on a web site, in your mail client or any other place, you can just capture it directly from the display without having to deal with saving image files or getting URLs.
What the screenshots don't show is how the views transition. It's all done dynamically with animations converting between views of different groups or when the details of a person are shown. This makes it easier to keep track of what belongs where, and also is fun, because it looks and feels nice and smooth.
History
Polka takes care of saving data in the background. The user doesn't need to know or think of that at all. All changes are saved and the complete history of changes is preserved, so data is never lost, and there is no need for confirmation dialogs or anything like that.
The data can also be shared via a server, including the full history. So all your people's data is always available and shown in the same way, no matter where you are.
Storing the history also makes it possible to have unlimited undo, even across different computers. But I haven't implemented any user interface for that yet.
Technology
So much about what Polka does and how the user interface looks and behaves. Although the implementation is not that important, it is working code, so some technical details might still be interesting.
The data is stored in an application-specific XML format, including all the meta data like comments, when something changed, the position of objects in the views. So everything is in one place and can easily be versioned and shared. The interface to the XML is generated via kxml_compiler from an example XML file. So there is a native API to access the data without having to maintain the code to read and write the XML and represent it in C++ objects.
To store history and for sharing the data across machines, everything is stored in a git repository. Every change is recorded, so the full history is available in the git history. Git is amazing as a storage backend. As it's so fast, it's not really noticable that storing data is more than just writing a file, and by using git's distributed nature, sharing the data and its history with a server and across different machines comes almost for free.
The UI is implement with QGraphicsView and the Qt animation framework. I thought about using QML, but as C++ is my native language, using QGraphicsView directly seemed like the more straight-forward way to me. The implementation separates models handling the data and the views reasonable well, though, so adding a QML based view should be possible without too much hassle.
For the person's view I use Webkit. The data is rendered as HTML and CSS and shown in Webkit. This gives some more flexibility and power than a widgets or QGraphicsView based view, and also opens a path towards the web. I tried again to write a small library to make it convenient to generate HTML and CSS. It's better than some of Spaghetti code I wrote in the past for this purpose, but it still doesn't match the elegange of for example some of the Ruby based solutions for this. It's a pretty tough problem in C++.
Other than that it's a pretty much standard KDE application. It doesn't make too much use of the platform, though, as I consciously didn't use many of the standard UI elements.
Code
The code for Polka is available at git://anongit.kde.org/scratch/cschumac/polka.git. It's still experimental, so use with care, although by the use of git as a storage backend your data is pretty safe.
I don't have specific plans for making a release or making it a more official part of KDE right now, but will continue to use it as a playground for trying out concepts and maybe provide some inspiration for other projects.
I am interested in feedback and comments. So don't hesitate to contact me, if you have questions, ideas, comments, or suggestions.
So I'm at the end with this blog post, and while it is a very long post, there is still a lot to tell. For now I'll let the code speak, and maybe I'll blog again later to discuss some more details about specific aspects of Polka.
We wrote KAddressBook as an application to manage contact data on top of the address book library, and while it's a nice and useful application, in some ways it still follows to some degree the technical thinking coming from the structure of the underlying implementation. This shows in the user interface, and makes it less useful, attractive, and intuitive as it could be.
So I thought it would be a good idea to experiment a bit and approach the task of handling people data from the other direction. Ignoring technical aspects of the implementation, or constraints of underlying technology, but thinking from a user's point of view, thinking about what's a natural way how to deal with this kind of data. I started to think and code a bit, and during Hackweek 6 I went on and got the application I started to a level where I think it's time now to share it and gather some more feedback.
But before I come to the application itself, here is some of the motives and concepts behind it.
Mental model of people
The first thing I did was trying to come up with an idea of what the mental model is how people think about people. The way address books usually present this data is practical in some ways, but when you think about other people, do you have an alphabetically ordered list of names in your mind? Probably not. So I collected a list of concepts, which better address the mental model of people.
Groups. People usually belong to some groups. There are colleagues, friends, familiy, the weird group of hackers you hang around with on IRC. These groups are often used to classify people, and provide a pretty solid way to structure how you organize people, the KDE guy you met at last year's Akademy, the colleague who used to study with you at university. People often belong to multiple groups, and sometimes there is no clear mapping.
Pictures. When thinking of people you usually have some kind of picture in mind. You would recognize most persons you know on a photo without effort. Pictures are widely used to identify people, and pictures of people, especially of people you have a closer relation with are easily available from various sources now.
Fuzzy information. In many cases the information you have about other people is somewhat fuzzy. You might not know the exact address, just a city. You might only know a nickname, or the date of the birthday, but not the year, or you might have trouble assigning the parts of a foreign name to the fields of a technical address book. Is it a middle name or is it part of the given name? Is this the surname, or maybe a suffix? While it's nice from a technical view, to have this exact classification of fields of a record, in practice and from a human point of view, it often just is neither possible nor important. Humans deal with fuzzy information pretty well, especially when dealing with other people.
Time. An important factor to classify information is time. You remember that you met a person at a certain time. When having multiple phone numbers available, the time, when you got them, will give an important hint about which one is more likely to work. In general, knowing when something changes, helps a lot with navigating information.
Space. Another important factor is space. You think of people being close to each other, either physical, as in neighbors, or in a logical way, as in family. A family tree is a great example how space is used to organize and structure people. There are also numerous other ways how to relate people in a spacial configuration. How they appear on a photo, a seating order for a celebration, and many more.
It's not paper
In addition to coming up with a way how to meet the mental model of how people think about people, I also wanted to take benefit of having available the power of managing the data on a computer. There are many address book applications which resemble paper address books, going as far as mimicking the texture of the leather cover. But being able to manage the data electronically without the restrictions of paper, leather, and spiral binders, gives some unique freedom and potential in a couple of areas.
Ubiquity. As it's so easy to store, transmit, and distribute data electronically, data can be ubiquitous, it can be available at work as well as at home, or when being on the road, on your laptop, phone, tablet. It can live in the cloud, easily accessible from everywhere.
History. Without the restrictions of paper, there is no reason to ever delete data. You can keep an unlimited history, which gives you the safety to always being able to go back, if you have changed something you later realize you didn't want to change, or if a need to access old data arises. This all can be done in a way, which hides old data from the current view, to not clutter the most recent view you normally use.
Low-cost editing. With electronic data, the cost of editing, rearranging, duplicating, and deleting data is very low. You can easily duplicate a set of entries about people to do some rearrangements, and then delete it again after a few minutes without loosing anything. No striked through entries, no wasted pieces of paper, no mess of failed attempts to get something done. This provides the opportunity for ad-hoc editing, especially if combined with some kind of history.
Connect to the cloud. A ton of personal data lives in the cloud, on various web sites, in structured and not so structured ways. With Facebook, Google, Linkedin, your corporate directory server, the data on your private mail account and much more, you have access to a lot of data from the people you usually deal with. By putting an application at the right place, you can connect all this to represent your personal social network.
Unconstrained user interface
Finally I wanted to go beyond the standard user interface of current address book applications. There is much value in standardized interfaces, taking into account style guides, using standard components, and all the other good stuff of working in a nicely defined, consistent, and integrated environment. But I wanted to experiment with leaving this behind and trying some non-standard concepts.
So I decided to not care much about standard widgets, to get rid of everything, which was non-essential to the actual application, to use animations gratiously to make the interface dynamic and support the user in understanding transitions. I also decided to try a new kind of menu, which isn't seen much on desktop applications, but could give more direct access to the actions the user needs. Finally I also decided to create a UI, which is not limited to a specific form factor, but can deal with a variety of devices, not only classical desktops, but also stuff like tablets, or maybe even phones.
Polka
Now that you know where I came from let me introduce you to my experiment. I call it Polka. It's an application for dealing with people data based on the concepts I described, thinking from a user's point of view, matching the mental model of how we think about people, and not caring too much about the current status quo in terms of address book applications. I summarized that in the FATE entry for my hackweek project, where I called it the humane address book for the cloud. The title came from the idea to approach an address book not from the technical point of view, but from what is relevant for human users, and to tie it to all the data and functionality which is available in the cloud.
I started to think about this quite some time ago, and did write some code here and there, but during last hackweek I made the effort to actually put it all together and polish it so that it hopefully adequately illustrates the concepts I wanted to experiment with.
Let me explain some of the main elements of Polka.
Group view
The central part of Polka is the group view. It shows a group of people and possibly some sub groups. The display is based on people's pictures and makes use of the view as a kind of canvas, where the members of the groups can freely be arranged. Names are shown for entries where no picture is set, and they are shown for all entries, when hovering over with the mouse pointer, so it's easy to identify people.
By default all people are shown in a compact regular arrangement, but you can simply move all entries around to create a different arrangement. The next screenshot shows an example. It's the group of people, who attended the Osnabrück 8 meeting. The arrangement reflects where people were on the group photo.
That's just one application for arranging people freely. You could also reflect breakout groups, seating orders, a family tree, or any other relations between people. The basic idea is that you use space to naturally reflect how you are thinking of people. People can be added to as many groups as needed, and any group can contain other groups with the same or different people. The arrangement of people is specific to the view of the group, but the entries of people are always the same, they are just links, so a person can appear in multiple groups, but the data is only there once.
Menus
For menus and getting access to actions in general I wanted to experiment with something different than the classical menu bars and context menus, and see if I could find a way to make it more natural and direct to work with the elements shown in the user interface. So I got rid of all traditional menus, no menu bar, no status bar, no right clicks.
In the previous screen shot you can see how you get access to actions for a person. If you hover over a person, there is shown a fan-like menu, where you can select some person-related options. For general options there is the "main" menu disk at the top right, which also shows actions on hover. You can also click on the canvas to get options which are related to a certain location like adding a label.
This all is pretty simple, and you don't even have to be very exact, when hitting a menu, so it probably would also work with a touch screen, although I didn't try it, so take this with a grain of salt.
Person view
When you click on the "show" menu item, a detailed view of the person is shown. It includes all the data you store about this person. This is the usual contact information, but most of it is stored in a relatively free form. You don't have to identify components of the name or the address for example. They are just text fields. You can also easily add free form text by adding comments to every field of the person's data. The speech bubble indicates where a comment is there, and you can add general comments to the person's entry. All this helps dealing with the fuzziness which data about people often has.
When you hover over a data field, some editor controls are shown to comment, edit or remove the field, and the information is shown when the fields was modified the last time. This way you can judge, which fields are relevant, and which ones might be outdated, and it also can help with putting the entry in the perspective of time, they might be related to something which happened at a certain time you remember.
An important element are the pictures of the person. Polka collects pictures from different sources on the web, e.g. from your Twitter profile, and you can easily add more pictures by using a built in screenshot function. So if you see a picture of a person on a web site, in your mail client or any other place, you can just capture it directly from the display without having to deal with saving image files or getting URLs.
What the screenshots don't show is how the views transition. It's all done dynamically with animations converting between views of different groups or when the details of a person are shown. This makes it easier to keep track of what belongs where, and also is fun, because it looks and feels nice and smooth.
History
Polka takes care of saving data in the background. The user doesn't need to know or think of that at all. All changes are saved and the complete history of changes is preserved, so data is never lost, and there is no need for confirmation dialogs or anything like that.
The data can also be shared via a server, including the full history. So all your people's data is always available and shown in the same way, no matter where you are.
Storing the history also makes it possible to have unlimited undo, even across different computers. But I haven't implemented any user interface for that yet.
Technology
So much about what Polka does and how the user interface looks and behaves. Although the implementation is not that important, it is working code, so some technical details might still be interesting.
The data is stored in an application-specific XML format, including all the meta data like comments, when something changed, the position of objects in the views. So everything is in one place and can easily be versioned and shared. The interface to the XML is generated via kxml_compiler from an example XML file. So there is a native API to access the data without having to maintain the code to read and write the XML and represent it in C++ objects.
To store history and for sharing the data across machines, everything is stored in a git repository. Every change is recorded, so the full history is available in the git history. Git is amazing as a storage backend. As it's so fast, it's not really noticable that storing data is more than just writing a file, and by using git's distributed nature, sharing the data and its history with a server and across different machines comes almost for free.
The UI is implement with QGraphicsView and the Qt animation framework. I thought about using QML, but as C++ is my native language, using QGraphicsView directly seemed like the more straight-forward way to me. The implementation separates models handling the data and the views reasonable well, though, so adding a QML based view should be possible without too much hassle.
For the person's view I use Webkit. The data is rendered as HTML and CSS and shown in Webkit. This gives some more flexibility and power than a widgets or QGraphicsView based view, and also opens a path towards the web. I tried again to write a small library to make it convenient to generate HTML and CSS. It's better than some of Spaghetti code I wrote in the past for this purpose, but it still doesn't match the elegange of for example some of the Ruby based solutions for this. It's a pretty tough problem in C++.
Other than that it's a pretty much standard KDE application. It doesn't make too much use of the platform, though, as I consciously didn't use many of the standard UI elements.
Code
The code for Polka is available at git://anongit.kde.org/scratch/cschumac/polka.git. It's still experimental, so use with care, although by the use of git as a storage backend your data is pretty safe.
I don't have specific plans for making a release or making it a more official part of KDE right now, but will continue to use it as a playground for trying out concepts and maybe provide some inspiration for other projects.
I am interested in feedback and comments. So don't hesitate to contact me, if you have questions, ideas, comments, or suggestions.
So I'm at the end with this blog post, and while it is a very long post, there is still a lot to tell. For now I'll let the code speak, and maybe I'll blog again later to discuss some more details about specific aspects of Polka.
Monday, February 14, 2011
I love Free Software
Free Software is the foundation for a lot of what we are doing. It provides the base, on which our community can operate with autonomy and passion. Especially in times when landscapes are shifting it's reassuring to know that the freedoms of Free Software guarantee us and the rest of the world that we can use and develop our software following our purpose and to the benefit of the millions of users out there.
For me the Free Software community always has been a welcoming, rewarding, and enriching place. I would like to take the opportunity to say thank you to all the users and developers, students and professionals, volunteers and commercial contributors, who spend their time and passion on making the world a better place through software.
I love Free Software!
For me the Free Software community always has been a welcoming, rewarding, and enriching place. I would like to take the opportunity to say thank you to all the users and developers, students and professionals, volunteers and commercial contributors, who spend their time and passion on making the world a better place through software.
I love Free Software!
Monday, January 24, 2011
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.
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.
Monday, December 6, 2010
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.
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.
Sunday, October 3, 2010
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.
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.
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.
Sunday, September 26, 2010
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.
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.
Subscribe to:
Posts (Atom)
55,041,902 Lines of Code
I did some exploration on KDE's code base . It's amazing what you can find when you have almost 30 years of public history in git. I...
