Tuesday, July 28, 2009

SUSE Studio Launch

Today we launched SUSE Studio as part of Novell's SUSE Appliance Program. This is an exciting event, as it marks a major milestone for the work we did in the Studio team for the last two years. With SUSE Studio you can build your own Linux, fast and easy. You only need a web browser. To achieve this, a lot of code was written, a lot of feedback from users was collected, and a lot of work was done to deliver a great user experience. At Linuxtag 2008 we presented Studio to the public for the first time, followed by an Alpha and a Beta period where we invited more and more users. We talked at FOSDEM and Linuxtag 2009 about Studio and presented the Studio Kiosk at various trade shows. All this comes together now in the launch of SUSE Studio as part of the SUSE appliance program. If you would like to give it a try yourself, sign up at susestudio.com, and we'll send you an invitation.

The major features of Studio, such as building appliances and testing them in the web browser, are pretty well known now, not least thanks to an amazing community, which has created walkthroughs, screencasts, reviews, and tutorials. But there are also some lesser known features, for example the API, testdrive networking, public download URLs, or the MySQL configuration. I'll try to find some time to write a bit more about these features later.

For my personal work Studio has become an important tool. I used it for example to create the Marble Live CD, or for my hackweek project, the KDE SDK. It's also a nice way to try out software or create an updated openSUSE version, for example with the latest KDE. But many other people are using Studio for interesting projects as well. Some of these are collected on the SUSE Studio appliances page in the openSUSE Wiki. If you have created something with Studio, please don't hesitate to add your project there.

One of the most interesting aspects of working on SUSE Studio is the technology side of things. It's a complex and demanding system, so it was an exciting challenge to actually build it. When we started as the SUSE incubation team, our mission was to explore new technology and foster innovation, and we learned a lot while applying this mission to the work on Studio. As a base we use Kiwi, the SUSE command line imaging tool, and we basically put it on Rails, with the web interface you can see on susestudio.com written in Ruby on Rails. Rails is a fantastic framework for doing web applications, and we use it not only for the UI itself, but also for internal HTTP APIs. SUSE Studio even made it to the list of amazing applications on the Rails web site. Another area where we learned a lot is deployment. It took us a while to find the right combination of procedures based on git, Webistrano, and system administration tools. But now we have a three-layered weekly release process, which works pretty well, and enables us to get fixes out to our users in a quick and reliable way.

All that said, from my personal point of view the best feature of SUSE Studio is the team which created it. It's an honor and a pleasure for me to work with people who bring together such an enormous amount of talent, experience, and passion. I really enjoyed the last two years, and I'm looking forward to a lot of other great stuff coming from this team. Guys, you rock.

Monday, July 20, 2009

Creating a KDE SDK

Last week I had written about my ideas for the fourth openSUSE Hackweek. I got quite some feedback and most people seem to think that the KDE SDK is the most useful idea. So I'm going to work on this for the hack week.

My goal is to create a software development kit for KDE, which makes it as easy as possible to write KDE applications. The main target audience are third party developers, who want to create desktop applications. The entry barrier should be as low as possible. There should no special knowledge about KDE, development processes on Linux, or familiarity with the community be required.

I thought a bit about how to best approach the creation of a KDE SDK. This lead me to the following design decisions:
  • The SDK will be delivered as a sofware appliance. I'll probably make a VMware image and a live CD for a start. This makes it easy to use it everywhere, independent of operating system or other system constraints. It also makes it easy to set up a very well-defined environment for the SDK, so that all components play well together and don't interfere with other parts of an existing system.
  • As a base for the appliance I'll use openSUSE, because this provides not only a great base system, but with the openSUSE Build Service and SUSE Studio it also provides excellent tools for creating and distributing appliances.
  • The UI of the KDE SDK will be based on Qt Creator. The main reasons for this choice are that it provides a pretty clean and simple UI, and that it's easy to hack, as the code is pretty straightforward and it's conveniently hosted in git on gitorious.org.
  • Application programming language will be C++. Some of the script languages might be easier to grasp, especially for beginners, but for KDE and Qt C++ really is the native language. Documentation, examples, and most code is in C++, so it's most easy to get help how to do things. It also avoids the complication of having the extra level of a language binding.
  • Integrated documentation. There is lots of documentation floating around in various places. The SDK needs to integrate that in some way and provide pointers to what's relevant and helpful.
  • Integration of online services. There are lots of online resources and services, for example documentation in Wikis and other web sites, mailing lists, IRC channels, web sites like kde-apps.org, or web services for development like gitorious, the openSUSE Build Service, or SUSE Studio. The SDK should integrate these as far as possible, so that the user gets the full benefit of all these community supported services. Maybe the SDK could even be basically stateless, so that all data is held online, and it doesn't matter with which instance of the SDK and from where you are using it.
  • Full software life cycle support. Developing applications is not only about writing the code. The code has also to be packaged and deployed to the user. There is a rich infrastructure to do all that, so the SDK should make use of it and support stuff like creating packages of the application, and publishing them at the places, where they can be found and used by end users.
  • Version control is essential. So the SDK will support git and gitorious.org out of the box. This should be done in an as transparent way as possible, which guides the user through a defined workflow, so the user gets the benefits of version control, but doesn't suffer from complexities of the underlying system.
I'm willing and plan to revisit every single of these decisions later, but to get started I will follow this path for now. For detailed progress updates about how the KDE SDK development goes see my hack week blog.

If you are interested in helping with creating a KDE SDK, let me know. I would be happy to team up with others to get this project done.

Tuesday, July 14, 2009

Hackweek IV

From July 20 to July 25 there is the fourth openSUSE Hackweek. Past hackweeks have been a blast. So many great projects have emerged from it. One of the latest example is the social desktop, which was one of the award-winning projects of Hackweek III. Ideas for hackweek projects are collected in openFATE. Browse for the Hackweek IV product to get an overview.

I'm pondering what to do for this hackweek. I have a couple of ideas:
  • GUI client for SUSE Studio. Studio is a fantastic web app, but sometimes it would still be more convenient to have a native client, for example when dealing with lots of overlay files, or to manage writing downloaded appliances to physical media or running and controlling them in a virtual machine. The Studio API makes it possible to write a native client.
  • Xing client lib. Xing is said to have some API to access the data about your social network. It would be great to have a client lib, which allows to get hold of this data for further usage on the desktop, e.g. putting it in your addressbook, or connecting it to the data of other social networks.
  • Grand Unified Social Network. Many sites let you manage your social network in its own way, Facebook, Xing, Linkedin, OpenDesktop. Even Twitter and sites like Gitorious provide some of these functionality. It would be great to put all this info together on the desktop and integrate it in some unified scheme, which merges and connects all your different social networks you have build on the web. This certainly would be a UI challenge, but it has quite some potential.
  • KDE SDK. Developing KDE application is not hard, but involves quite a bit of machinery. You have to get in place the development environment, tools, documentation for all involved components. Creating a KDE SDK appliance, which puts all this together in a pre-configured and easily accessible way, could make it even easier to get started with KDE development.
  • Krest. I have worked on some infrastructure for creating C++ bindings for REST services in the context of the Kode project. kxml_compiler already supports creating data model classes from XML examples. The missing piece is a tool to guide creation of these classes and associated transport bindings according to the needs of the developer. The goal would be to implement a guided binding creation by example in contrast to the usual approach of taking a full formal spec of transport and format.
  • Clubwagon. This is the dormant project to write a web tool for managing associations. In Germany there are hundreds of thousands of them (e.V.), and all have to manage members, budgets, meetings, etc. This would be straight-forward Rails programming, so in a week quite a bit could be accomplished.
  • Todoodle. This is my award winning notes taking application, which I use for my private needs, but which hasn't seen much development over the last time. It would be nice to give it some more polish and do a proper release for the public.
  • Package magician. I would love to have a UI for the build service for rapid package creation. Ideally this would cover RPMs and Debian packages for all supported distributions under an interface which is simple to use and hides all the nasty packaging details an upstream developer doesn't want to know about.
  • Plutimikation. My math learning application for children could need some love. It works, but it could have some more motivational features.
If you have input on the projects, would like to join, or just have a preference for one of them being done, let me know. You can also view the projects in openFATE and vote and comment there.

Thursday, July 9, 2009

Fixing freedesktop.org

After all the discussions and meetings we had about freedesktop.org during the Gran Canaria Desktop Summit and on the xdg mailing list, I have now written down a more formal version of the process we talked about, so we can sort out all the details and decide on a final procedure how to document specifications and define what is an accepted freedesktop.org specification. This hopefully will fix freedesktop.org.

To bootstrap the process I wrote it down as a freedesktop.org specification for the freedesktop.org Specification Process.

The next step is to get comments and incorporate them into the document. So if you have comments please let me know, respond to the thread on the xdg mailing list, or provide a patch to the document.

When comments are incorporated we can merge the specification back into the main specification repository and get acceptance by the desktop communities.

Wednesday, July 8, 2009

Signals from the Gran Canaria Desktop Summit

It's the sixth day of the Gran Canaria Desktop Summit. I finally have a little bit of time to collect some of the things which I found personally interesting.

It's an intriguing event, lots of stuff going on, lots of people, and the local team is doing a fantastic job with the organization. It's fascinating to see how Akademy and GUADEC happen in an intertwined way. There are many specific sessions dedicated to all the rocking technology our desktops are based on, but there is also lots of room for getting together and mix, so everybody can individually decide about how big the dose of collaboration and cross-desktop pollination is he is going to take.

View on the sea from the symphonic hall of the Alfredo Kraus Auditorium, where keynotes and lightning talks took place on Saturday

There was quite some talk about how to move KDE to git. The proposal which seems to be most attractive is to use gitorious.org to host the KDE repositories, which would give us a common space with Qt and some other projects. It was great that Johan and Marius, two of the guys behind Gitorious were at the Desktop Summit, so we could pepper them with questions about Gitorious and discuss how to best make the move. Today was a BoF session about KDE and git, which was so crazily crowded that I decided to look for a quieter place. While doing this I met Vincent, who had the same idea and we talked a bit about the GNOME migration to git. They have creates some good git help and documentation about the move itself. Later I heard that the BoF session was a good success, and that there is a team of people who will take care of what needs to be done. That's great. I'm really looking forward to the move and being able to use git for KDE development.

We also managed to get two sessions about freedesktop.org together. There have been some problems with it because of administrational issues and a lack of transparency and criteria about what actually warrants a freedesktop,org acceptance. Aaron has proposed a solution, this could be a good base for an implementation. The sessions were attended by a wide range of people including developers from KDE, GNOME, and admins of freedesktop.org. There was a broad consensus that we need to fix the admin issues in some way, but that the real issue is one of governance, and we need a better and more transparent way how to express what specifications on freedesktop.org have which state, which are generally adopted and which are just in an incubator state and not yet a real cross-desktop solution and so shouldn't have the freedesktop.org label yet. In the end we came up with a solution. The basic idea is to only accept specifications on freedesktop.org, if they are accepted by two major desktop projects GNOME and KDE represented by their release teams. Details certainly have to be fleshed out, and their also is a need for some more discussion, but in general this feels like the right direction.

An unexpected but very interesting encounter was to meet Jan Lehnhardt and learn something about CouchDB. This is a document-centered database based on JSON with built-in replication. There are all kind of interesting uses cases for it, and the Ubuntu guys seem to plan to rely on it pretty heavily. Worth looking into it. There already is an Akonadi agent for CouchDB. Unfortunately there don't seem to be any openSUSE packages yet.

Yesterday there was the annual membership meeting of KDE e.V.. One of the main topics of the meeting was the election of the board. We had five great candidates for three open positions. This is an encouraging sign that KDE e.V. is in a pretty healthy state and the work we do in supporting the community is accepted and bearing fruit. In the end we elected Frank and Celeste as replacements for Aaron and Klaas. Adriaan, Sebas and me stay in the board. We prepared this for some time to have a smooth succession providing some fresh blood to the board, but also having some continuity. This seems to work out pretty well.

Finally I came across a report by Glyn Moody about the summit. He held the first keynote of Akademy, and presented an interesting line of thoughts there, explaining how hackers will save the world by bringing their culture of sharing to the greater society.

One paragraph of his text Gran Canaria Desktop Summit: a Study in Contrasts stroke my special attention:

Although it was great to see the large numbers of hackers from the GNOME and KDE communities coming together at this joint conference, I think it's vitally important that they continue to go their separate ways, each convinced that their approach is best, but each ready to be stimulated by and learn from what their colleagues and rivals are up to.

I think that nicely summarizes the atmosphere of the event. There certainly is some competition, but in the end it's motivating and stimulating for both communities and leads to better solutions for all of us.

Thursday, July 2, 2009

Blog moved

I finally decided to move my blog. kdedevelopers.org has served me well, but now I want some more features. Blogger provides some killer features, such as using my own domain, blogging by email, or the powerful comment system. So from now on you'll find my blog at blog.cornelius-schumacher.de. See you there.

Team Profile

What makes a great team? One important factor is that you have a balanced set of skills and personalities in the team. A team which only con...