You might have heard about Kraft, a KDE application aimed to people who operate small enterprises and have to write an offer or invoice sometimes. Kraft version 0.32 was released recently, the last KDE 3 based version, the KDE4 port has finally started.

Kraft is one of the candidates for the KDE group for financial apps which is a consolidating idea and was encouraged in Alvaros article A group to bind them all recently.

Unfortunately it is still a bit tricky to set up. To make it easier to check it out Live Images were created featureing Kraft on an openSUSE distribution with all tools and  interesting demo data. That is perfect to try it out and give it to friends and colleagues and talk about.

Please check the download page of the Kraft Homepage for details.

Last week Cornelius and me spent two days in the office in Prague to practice two days Ruby on Rails with our czech colleagues.
It was not only fun as usual but we had chosen Hermes as a trainings project. Hermes, our openSUSE notification system where the user decides how she wants to be notified definetely can make use of work so it were great to discuss with ten developers about it, hear their opinions and get some patches finished which will improve the system.

All went to a branch in svn and I hope to find time soon to merge it back and put it into production.
Thanks to our colleagues for hosting us and work with us. Maybe YOU also want to train on something real? Hermes is your friend - send me a note and get a free svn account

Kraft 0.32 was released a few days ago. Kraft is KDE software for people who operate a small business and want to generate documents like invoices or offers for their customers. Kraft helps to do that in a very efficient way with template texts and a calculation module and of course integration in KDE. Very important is an excellent print out (that’s the face to the customer) which Kraft does via an PDF export of the document.

I say ’small business’ as a target group and I mean small shops doing crafts like carpenters or plumbers or landscaping working alone or with a few people. I think free software and especially KDE is very good for these kind of companies. Larger companies usually go for specialised software, which is available for nearly all kind of crafts in all levels of usefulness and quality.

When I talk in the community about Kraft (I am of course not as good as Tackat in his best Marble-times) I sometimes feel that the coolness factor of this kind of software is not so big. People seem to think “How can one do this kind of boring, already-there software?”. Well, yes. This kind of software exists. But as free software and on KDE, well integrated into the desktop? Not that I am aware of.

Here are some good reasons to work on Kraft for me personally:

1. I think it is important that this kind of software is available. Not only Kraft, but other stuff people need for their business, for example financial software like KMyMoney. Well integrated in KDE this can enable another huge group of users which now uses other systems.
2. It is serious. Kraft is software people use to get their money. If somebody has done work and wants to invoice it she loves a well working software that saves time for her. But if it does not work, it becomes a serious issue quickly because only written and sent out invoices are good invoices from that POV.
3. Especially because there is much competition from the commercial side, it is fun to try to create free software that is even better from for example the usability perspective. It is real challenging.
4. I am somehow addicted This year I work for twenty years on this kind f software. If you like you can check out an underground video which shows software running on an Atari ST, used for daily business in my brothers landscaping company. I released that version in 1991, I still have an earlier release from 1990 which I could not get to run anymore. I started to develop it in 1989.

But back to the new Kraft-release: Beside other things I did some change to the tax system which make Kraft now useable internationally (shame  on me that the earlier versions where tied to german taxing too much).

So please, tomorrow first thing knock at the door of your handcrafter neighbor and ask him if he has thought about invoicing with Linux - Kraft  is with you, when you support him. Chances to get very interesting insights on how non-geeks see the computer world.

openFATE is now up and running for a few days. openFATE is, in case you missed the announcement, the community accessible feature- and requirements tracking for the openSUSE distribution. We developed and used the FATE system (which has some more components than just openFATE) before internally, but since we want to really open up development it was a logical decision to find a good way to let the community participate.

openFATE is not a stand alone system. The openSUSE distribution is as you know the base for our enterprise products. That means that discussions we do around openSUSE features sometimes have impact on what happens in the enterprise products later on, or vice versa. If features become important for SLE that also might have importance for openSUSE.

That is implemented in openFATE. It is connected to a common database which holds all information about features for all products. A chain of tools filters out information that can not go public.

It is basically about the SUSE Linux product family, where the openSUSE distribution and the SLE products are part of. If a community member gives input on a feature which has a product context for the SLE product, the input
is seen by the SLE product- and project manager as well as the involved developers. I think it is important to realise that this is part of our understanding of open development. openSUSE is not cut off the things we’re doing for SLE, but can have a direct influence.

So far we nearly had 300 changes to existing features and a whole bunch of new feature requests from the community. That is a very good result for the first few days I think. Please keep on giving your input. We are happy to see people involved in product planing, eg. for openSUSE 11.2 .

motivated by Aaron’s blog post More downstream fun I was thinking about how Fate could be a more important part of infrastructure in the Linux landscape. Fate is now an important part of the Novell/SUSE infrastructure and we are currently in the process to open it up for the openSUSE community. But could Fate also be useful for upstream integration? To let you participate in the discussion I think I should start with some explanations what Fate is and in which environment we are with it.

Fate is a system developed at SUSE over the last few years to track features and requirements for Novell Linux products.  The term “feature” is already is a topic for scientific papers, but how we understand a feature is a functionality  that is not yet in the product but required or wanted. It references future products, in most cases more than one such as SLE and openSUSE.

The little sketch illustrates the dilemma in which we are when it comes to product planning. Basically it is all about one  thing: decision taking. Decisions have to be taken about the new functionality  that goes into a product and the tasks internal people work on. This is based on the decision how the product should look alike from a high level point of view. To make a solid decision about the high level product it needs to be clear what we are actually able to put into the product at a given time. That is only a part of what is really going on but let’s leave it with that for simplicity.

You see that lots of the base information which is needed to make
good decisions comes from different people: Product managers have a strong idea of how products should be, the technical project manager knows about dates and technical possibilities and can plan with the engineering managers how that can be achieved with the given amount of people in a given time frame. Technical feasibility is worked out with the developers as they’re the experts. The colored arrows try to visualize the communication ways, different colors mark different topics.

Since we work with the communities we have more input of information: The user community tells what is needed and the upstream communities announce what they plan to do by when.

The part with the internal decision taking is very much based on Fate in the Linux part of Novell and that is working fine. Features come in by a requester and all involved parts can give their thoughts in  a discussion forum. The key functionalities add their priority for the feature and finally PM and TPM come to a decision. Features with a high priority have to make it into the product. Engineering managers can assign developers and they can mark features as finished. All the processes are covered by a set of configurable rules. The Fate system is integrated into other infrastructure parts. There are several clients for different needs, the most mature is the KDE fat client.

What is not yet optimal are two things: There is no good way yet for the user community to community their wishes for upcoming products. We are facing that with opening up a new web based openSUSE Fate client soon. That will involve the user community not only in testing and using the product but already in its planing in a defined way.

A more tricky part is how to involve the upstream communities. It would be great for a Product Manager of a Linux distribution to see the feature plans for upcoming releases of big upstream projects, maybe somehow integrated into the Fate for his product. Would the Fate model as described here in a nutshell suitable for upstream projects?

For example, could KDE or GNOME make use of parts of the process for them internally and provide a structured interface to the downstream parties? If so, that could add a lot of transparency. Transparency is the precondition for flexibility and trust and as a result for better collaboration which would benefit all.

I hope that helps for a basic understanding and would love to hear your opinion. I promise to come up with more information about the Fate system and improve my drawing skills

This morning I realised that openSUSE appears on the hardware database smolt the first time. We are introducing smolt with openSUSE 11.1 in the installation workflow. People can choose to send up their data to the smolt database. All that is of course done anonymously, the data is stored under a unique UUID which can not be tracked back to the submitter (Privacy Policy here.)

Smolt is a project started by Fedora to collect information about the hardware that is used with computers running Linux. We at (open-)SUSE were seeing this demand as well and also were discussing a solution. But it became clear quite quickly that it does not make sense to have a per-distro solution for that - if we want to have momentum with a hardware database a combined effort promisses the most.

On Linuxtag 2007 I was first time involved in meetings were people from the Fedora project offered us to participate in smolt. It became clear that the idea behind smolt is what we also wanted. The working athmosphere was (and still is) open, friendly and productive and thus we decided to join in. With openSUSE 11.0 we first time shipped a smolt client, but not in the installation workflow.

Smolt isn’t finished yet. While it is a stable infrastructure thanks to Mike McGrath and friends who work on it there are still some things that could be improved. Maybe there is somebody in the openSUSE community interesting in joining the smolt community and help? That would be great because the contributions from our side are still limited and I think it would be great if everybody would bring something to the party.

Smolt is not limited to Fedora and openSUSE btw. Other distros are invited to participate as well. With that I think smolt is a great thing for Linux overall. Hopefully some time in the future it will help us to convince more hardware manufacturers that supporting Linux is important for them.

An interesting read is also http://www.linux.com/feature/118322

Ah - yes, of course you should not forget to actually use smolt and send up your hardware data when installing openSUSE - we can still climb up in the OS list on http://smolts.org/static/stats/stats.html

Yesterday afternoon, Hackweek III was running on full throttle, suddenly Jeff Jaffe, the CTO of Novell, stepped into our office. No meeting appointment, no big words, just a “What are you guys working on in Hackweek?”. Well, everybody who ever was working as an employee might understand that having the boss of the boss of the boss stepping into the office spontanously can be a bit exiting, but that is just the first two seconds. I think it is cool if executives do that.

In the company I worked before S.u.S.E. the owner always visited us on friday afternoons and sat on the developers desk. He was somehow geeky and was simply interested in tech talk. That made me nervous in the beginning, but later it was fun and informing. It was a great opportunity to present good ideas or concerns and on the other hand he gave a lot of first hand information what customers say, how the fairs went etc. In this kind of situation we convinced him finally that our under-cover Linux port of our solaris based product was way better for all customers than the Windows version most customers (and thus the executives) asked for.

I was hacking on my KDE application Kraft when Jeff asked, which is certainly not for the enterprise market. But given that applications are the key to pull people to linux we agreed that it is a cool Hackweek project I forgot to ask him what he is hacking on

This is about what I did yesterday in the first day of hackweek:

It is a hello world program. No, the interesting thing about that is not that I am finally able to write a hello-world (which I copied from the internet anyway) but the system on which it is running is unusual for me. It is another system than Linux, it is Windows.

Still somehow boring to let run a hello world on Windows? Yes, but I did not build it on Windows. I build it on Linux on a free software stack. I yesterday set up a mingw compiler ready for cross compiling Windows binaries on Linux. Maybe this can be the first little step towards a Windows build target in the Buildservice.

What do you think?

In Sint-Katelijne-Waver, Belgium currently Akademy, the annual conference of the KDE project takes place. More than 300 people had a nice weekend listening to a whole bunch of very interesting talks of various topics around KDE. Over the week there will be special topics and BOFs and Hacking

While most of the topics were technically or very much related to KDE such as talks in the community track, on sunday there was a keynote from Cliff Schmidt from literacybridge.org with the title Digital Audio to Reduce Illiteracy, Poverty and Disease. Danny has already blogged about it. It was a real mind opener that a lot of our efforts are useless to people who simply can not read. Cliff and the literacybridge project has a deep insight of how that can be improved. It was a real impressing talk and hope that the success for that project continues. Please check the project out.

On monday we had the general assembly of the KDE e.V. where Cornelius and Aaron Seigo were reelected into the board of the KDE e.V. Furthermore it was decided about a Community Code of Conduct for KDE that gives some hints how to behave in our community which seems to be needed these days and some other interesting and important stuff.

Today there is the “Embedded and Mobile Day” on Akademy which started with a talk around the Maemo platform where now Qt4 is available and everybody is invited to port interesting (KDE)  applications to it. Nokia was nice enough to give lots of N810 devices to KDE developers. Very motivating

openSUSE is also very present on Akademy, not only as a sponsor. Coincidentially most of the conference speakers were standing very near to the openSUSE poster and as a result it was very prominent, but more important is that openSUSE is running on many desktops I saw…  Some people approached me and mentioned things like openSUSE 11.0 is really cool, KDE 4.1 is most easily installable with one-click-install, zypper rocks and other cool things. Nice.

Akademy is great and I enjoy some hacking on Kraft now

These days some people from various teams spent a lot of time the last days discussing topics around L3. L3 means Level-3 support and is one of the services that we offer for our enterprise product series. It is about bugs which are not solvable through our support organisation but require developer eyes to stroll through source code.

What that has to do with openSUSE you might wonder. Well, since we’re currently working on switching our internal build process to a Buildservice based solution, L3 comes into play as well as other parts that are hardly visible for the community but important for the business.

L3 is a really tough game: Customers are paying money for the service and if they call they expect premium service quickly. Often enough enterprise operations are endangered by L3 bugs (or it is said that it is and clearification is needed quickly to relax the situation.

For the brave guys offering this service that means that they need to replay the customer situation quickly, debug, find the bug and if needed provide a fix for the customer.

The customer of course can tell more or less accurate which system he is running on which hardware. But than it’s getting rough for us: Finding the correct source for this constellation might sound easy, but if one adds up the amount of products that we maintain, it’s subflavours and service packs and also considers the lots of maintenance updates that the customer is expected to install, it becomes clearer that there are lots of possibilities and huge hard drives with content ;-).
Having found the correct source debugging (often together with the customer under time preasure), fixing and providing a fixed package begins.

L3 is an impressive bussiness for me, done by courageous guys.

Even more nice that the Buildservice helps a lot here because it makes at least building of debug info packages and fixes easy. A well thought through project structure in the Buildservice linked together with sourcelinks and aggregrations (which is a science for itself which one where eases (at least) the source organisation a lot. Other things also sound promising.

There is still some work to do until all peaces fit together but we are looking forward to helping the L3 collegues to improve their processes with the Buildservice and maybe some other tools.
I know, this is not exactly related to community questions but I thought it might be interesting to read about these things from time to time as well…