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.


  1. looks like you have more good ideas than time to implement them ;-)

    Personally I like the KDE SDK best, I think such a thing would make it much easier for new devs to join. Same for the packaging magician, btw.

    But the unified social network stuff - whaaa that would rock too!

  2. openFATE needs login, so I am leaving my comment here. KDE SDK sounds great. I have been struggling for a month to get my dev setup working and wondering why KDE / Gnome have a simple "One Stop" starting place.

    ** Dont feed me the fish, teach me how to fish **, an SDK is like a fishing rod.

  3. I also think that the KDE SDK is the "best" in terms of what it can mean for new/casual developers who want to contribute. It is all about lowering the barrier. Nice to see shuch an effort beeing made. Wow! Thanks!