A task manager for the Plasma Wayland session

Plasma 5.7 will ship with a new taskmanager library. One of the reasons to implement a new taskmanager library is the port to Wayland. Our old code base was heavily relying on X11 and didn’t support the concept of multiple windowing systems. You can read more on that in Eike’s blog post about the new task manager. In this blog post I want to focus a little bit on the Wayland side of a task manager.

Architectural difference to X11

On X11 every application is able to read every aspect of every other window. This allows to implement a task manager. The task manager can get notified when a window is added, when a window is removed and install event filters for the changes of the window properties. That’s the basics for a task manager.

On Wayland the world is different. An application is not able to see the windows of other applications. This means by default Plasma is not able to see what windows exists, the taskmanager would be empty. The only application which knows about the existing windows is the Wayland compositor.

Merging Desktop Shell and Wayland compositor?

A possible solution to this problem could be to merge the desktop shell and the compositor into one process. This is the architecture used in e.g. Unity and GNOME Shell on X11.

But such an architecture has also disadvantages. It violates the concept of separating concerns and of “doing one thing and do it right”. We have an excellent task manager, an excellent window manager and an excellent desktop shell.

Also it would make code sharing between platforms more difficult. A task manager for Wayland would be very different from a task manager on X11. All the business logic and presentation should be the same. No matter which windowing system is used.

By merging the code bases together we would also make the code less reusable. One couldn’t use KWin/Wayland in another desktop environment (e.g. LXQt) nor could one use Plasma/Wayland with another compositor (e.g. sway). While we of course recommend to use KWin as the Wayland (and X11) compositor we don’t enforce it and also don’t want to enforce it.

Protocols, protocols

So a different solution is needed and that is done through a custom Wayland protocol which is called org_kde_plasma_windowmanagement. We have a few interfaces prefixed with Plasma. This does not mean that it can only be used by Plasma. It just means that the interface was first designed and developed for Plasma’s needs. We are happy to share the interface with other desktop environments.

The protocol is provided by KWin and it announces whenever a new window gets created. Once a new window gets created a bound client can bind an org_kde_plasma_window interface and get notified about all the states of the window.

The protocol exposes pretty much all the information KWin has about the window and it gets updated automatically whenever the state in KWin changes. In addition the protocol has requests the task manager needs, like “close the window”, “minimize it”, “maximize it”, etc. etc. KWin also listens to these requests and honors them.

Although the protocol is added to Wayland, it is windowing system agnostic. The created Plasma Window does not expose the actual windowing system resource (after all on Wayland another client cannot get access to it). KWin exposes a Plasma Window for both X11 managed windows and Wayland windows. By that the task manager is able to manage tasks from multiple windowing systems without knowing that it does so.

Evolution of the protocol

We added the Plasma window protocol initially for the work on the Plasma phone about a year ago. Also on the Plasma phone we had the use case of switching windows and using the X11 based task manager was just no option on a Wayland only device 😉

While the protocol worked fine for our initial needs, it was not yet sufficient for the use in the desktop task manager. So over the last weeks we introduced further support and improved the API to make it work more reliable. Also quite some changes went into KWin to ensure that only “interesting” windows are exposed. E.g. a context menu should not be shown in the task manager.

Our KWayland library of course has support for this protocol through the classes PlasmaWindowManagement and PlasmaWindow on client side. In addition there is a model exposed as PlasmaWindowModel.

Future work

The work on the interface is not done yet. There are still changes to the API needed and the upcoming KDE Frameworks 5.23 release will include new API calls in PlasmaWindow. As well we have already the first change scheduled for KDE Frameworks 5.24. And we also know that we need to expose a few more data elements in the protocol to get the task manager to the same level as on X11.

There is also an interesting idea floating around to use the – windowing system agnostic – Wayland implementation on both X11 and Wayland. For this KWin (on X11) would need to create a dummy Wayland server for the task manager to connect to. It’s an idea which we might or might not implement.

Security considerations

Currently every Wayland client is able to bind this interface, which means that some of the security improvements of Wayland are not available in Plasma/Wayland. We are fully aware of that and were also fully aware of the consequence when we added the interface. I do have ideas on how to address this and this will be implemented before we will recommend the Plasma/Wayland session for daily usage. The design allows to add security checks in these areas. Unfortunately my priority list did not allow me to implement this for Plasma 5.7, next chance 5.8.

Tragt Fahrradhelme

Mein Fahrrad hat heute morgen gemeint, mich nicht mehr zu mögen. Das Vorderrad hat blockiert und mich vornĂŒber geworfen. Wie man merkt, geht es mir ganz gut und bin mit einer Platzwunde am Kinn davon gekommen. Ich möchte aber nicht wissen, wie es mir gehen wĂŒrde, wenn ich keinen Helm getragen hĂ€tte, denn ich bin auf den Kopf gestĂŒrzt.

Daher einfach an alle: tragt bitte einen Fahrradhelm. Egal wie sicher ihr euch auf dem Fahrrad fĂŒhlt – es gibt immer auch unaufmerksame Autofahrer oder nachlassendes Material, wie in meinem Fall. Ach und auch wichtig: neuen Fahrradhelm kaufen nach jedem Sturz (ich lasse jetzt mein Fahrrad stehen bis ich einen neuen habe (das Fahrrad mit dem ich gestĂŒrzt bin, wird verschrottet)).

=-=-=-=-=
Powered by Blogilo

Studium Vorbei

Heute war das letzte große Ereignis meines Studiums: Abschlussvortrag mit anschließender mĂŒndlicher PrĂŒfung. Nun warte ich nur noch auf die Note fĂŒr die Masterarbeit :-) Zumindest gibt es nur noch zwei Möglichkeiten fĂŒr die Endnote, wer wissen will, welche darf gerne persönlich nachfragen 😉

Nun ist also das schöne Studentenleben vorbei und nach Ostern beginnt der Ernst des Lebens. Bin ja mal gespannt

=-=-=-=-=
Powered by Blogilo

Abklappern der Copyshops

Woran merkt man, dass man mit der Abschlussarbeit fast fertig ist? Man holt Samstags KostenvoranschlĂ€ge fĂŒr den Druck der fĂŒnf Exemplare ein. Die Preise waren so heftig, dass ich den Anhang komplett noch einmal in schwarz/weiß generiert habe. Am Montag werde ich das Werk dann wohl in den Druck geben, so dass ich entweder am Dienstag oder Mittwoch die Arbeit abgeben kann. MĂŒsste erst am Mittwoch, aber mittlerweile hab ich einfach keine Lust mehr daran zu arbeiten und fĂŒrchte, dass ich entweder verkorrigiere oder das Layout zerstöre.

Insgesamt 183 Seiten habe ich zu Papier gebracht, ohne den bloat (Verzeichnisse, Anhang) immer noch 106 Seiten. Darunter sind 39 Abbildungen, 11 Tabellen und 26 Listings. Insgesamt fast 6 Monate hab ich daran gearbeitet, seit Anfang Januar aber keinen Quellcode mehr geschrieben und meine Implementierung im Produktiveinsatz getestet. Allein im Januar hat der Filter 416 Spammails rausgeholt – im Februar deutlich mehr (zumindest zeigte die Tendenz bis zum 15.02. dies an – der Vallentinstag).

Neben den 41.000 Wörtern (laut wc) im Dokument, hab ich laut sloccount etwa 8.000 Zeilen Code geschrieben (UI nicht mitgezĂ€hlt). Sloccount meint, man brĂ€uchte dafĂŒr etwa 1,5 Personenjahre und die Entwicklung wĂŒrde mehr als USD 200.000 in kommerzieller Entwicklung kosten. Naja das Tool liefert komische Werte 😉 Meine EinschĂ€tzung vor der Arbeit war, dass ich zwischen 5.000 und 10.000 Zeilen Code schreiben kann in der kurzen Zeit. Das hab ich dann doch ziemlich genau getroffen. Gut war einfach hochzurechnen, da ich ja weiß wieviel ich fĂŒr KDE geschrieben habe in vergleichbaren Zeitspannen (Alt+Tab hat 2,6 KSLOC, Aurorae hat 1,9 KSLOC, Cube hat 3,2 KSLOC).

=-=-=-=-=
Powered by Blogilo

How to write a KWin effect

This blog post has been in my drafts folder for weeks and I just thought it’s time to publish it – ready for Akademy :-) And if somebody is really interested we could have a BOF session at Akademy. I think Plasma devs want us to write a slide effect to replace their custom popup animation. That would be a perfect example to get your hands dirty.

I wrote a new Kwin effect and thought this is the ideal effect for writing a small howto. It is an effect which helps resizing windows by colouring the changed geometry. I was told that resizing is not optimal in KWin, that is if the window content is shown while resizing it is slow and if the window content is not shown it is ugly. This effect should fill the gap. Unfortunately the current code will only work with the slow show window content while resizing (the API has to be changed). Nevertheless I decided to show the code in this tutorial.

Von KWin

The effect has been committed to trunk. So you can have a look at it and if you’re running trunk you can even try it. The effect which we will write has the name “Resize”. It will support both backends: XRender and OpenGL. Each effect has an own directory in kwin/effects so we create a new directory resize. There we create the following files:

  • CMakeLists.txt
  • resize.h
  • resize.cpp
  • resize.desktop

We have to include this directory into the build, so we edit the CMakeLists.txt in the effects directory. We just add the following line to the section marked as “Common effects”:

include( resize/CMakeLists.txt )

If it were an OpenGL only effect we would place this line in the section marked as “OpenGL-specific effects”.

So at this point we are finished with the preparation. So let’s start looking at the files. First the desktop file:

[Desktop Entry]
Name=Resize Window
Icon=preferences-system-windows-effect-resize
Comment=Effect to outline geometry while resizing a window

Type=Service
X-KDE-ServiceTypes=KWin/Effect
X-KDE-PluginInfo-Author=Martin GrĂ€ĂŸlin
X-KDE-PluginInfo-Email=kde@martin-graesslin.com
X-KDE-PluginInfo-Name=kwin4_effect_resize
X-KDE-PluginInfo-Version=0.1.0
X-KDE-PluginInfo-Category=Window Management
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=false
X-KDE-Library=kwin4_effect_builtins
X-KDE-Ordering=60

Most of it is self explaining and just needed for the “All effects” tab in the compositing kcm. The most important value is the “X-KDE-PluginInfo-Name”. This is the name used to load the effect and has to start with “kwin4_effect_” followed by your custom effect name. This last part will be needed in the source code.

Each effect is a subclass of class Effect defined in kwineffects.h and implements some of the virtual methods provided by Effect. There are methods for almost everything the window manager does. So by implementing those methods you can react on change of desktop or on opened/closed windows. In this effect we are interested in resize events so we have to implement method “windowUserMovedResized( EffectWindow *w, bool first, bool last )”. This method is called whenever a user moves or resizes the given window. The two boolean values indicate if it is the first, last or an intermediate resize event.

But there are more methods we have to implement. The effect should paint the changed geometry while resizing. So we have to implement the methods required for custom painting. KWin’s painting pass consists of three stages:

  1. pre paint
  2. paint
  3. post paint

These stages are executed once for the complete screen and once for every window. All effects are chained and each effect calls the stage for the next effect. How this works we will see when looking at the implementation. You can find a good documentation in the comments of scene.cpp

Now it’s time to have a look at the header file:

#ifndef KWIN_RESIZE_H
#define KWIN_RESIZE_H

#include <kwineffects.h>

namespace KWin
{

class ResizeEffect
    : public Effect
    {
    public:
        ResizeEffect();
        ~ResizeEffect();
        virtual void prePaintScreen( ScreenPrePaintData& data, int time );
        virtual void paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData& data );
        virtual void windowUserMovedResized( EffectWindow *w, bool first, bool last );

    private:
        bool m_active;
        EffectWindow* m_resizeWindow;
        QRegion m_originalWindowRect;
    };

}

#endif

We see that there are three member variables. The boolean is used to indicate if there is a window being resized, that is if we have to do some painting. The EffectWindow is a pointer on the window being resized and the QRegion stores the windows’s geometry before the start of resizing.

So now we can have a look at the implementation. I will split the code in small parts and explain the code. So first let’s look at the includes:

#include "resize.h"

#ifdef KWIN_HAVE_OPENGL_COMPOSITING
#include <GL/gl.h>
#endif                                               
#ifdef KWIN_HAVE_XRENDER_COMPOSITING                 
#include <X11/Xlib.h>
#include <X11/extensions/Xrender.h>
#endif                                                                

#include <KColorScheme>

As our effect should support both XRender and OpenGL we have to include the headers for both. As it is possible that the effect is compiled on a system which does not support one of both we use ifdef. We can be sure that at least one of both is available or the effects wouldn’t be compiled at all. If you write an OpenGL only effect you do not have to bother about such things. Also if you only use KWin’s high level API you don’t need to include those headers. But we want to paint on the screen using OpenGL or XRender directly.

So let’s have a look at the next part:

namespace KWin
{                    

KWIN_EFFECT( resize, ResizeEffect )                                                                                                                                                            

ResizeEffect::ResizeEffect()
    : m_active( false )                                                                                                                                    
    , m_resizeWindow( 0 )                                                                                                                                         
    {                                                                                                                           
    reconfigure( ReconfigureAll );                             
    }                                                                                                                           

ResizeEffect::~ResizeEffect()
    {                                                                                         
    }

Here we see the use of a macro. This has to be included or your effect will not load (it took me ten minutes to notice I forgot to add this line). The first value is the second part of X-KDE-PluginInfo-Name – I told you we will need it again. The second value is the class name. Following is constructor and deconstructor.

So let’s look at the pre paint screen stage:

void ResizeEffect::prePaintScreen( ScreenPrePaintData& data, int time )
    {                                                                                                                           
    if( m_active )                                             
        {                                                                                                                       
        data.mask |= PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS;           
        }                                                                                                                       
    effects->prePaintScreen( data, time );                                                                                                                     
    }

Here we extend the mask to say that we paint the screen with transformed windows when the effect is active. That’s not completely true – we don’t transform a window. But this flag indicates that the complete screen will be repainted, so we eliminate the risk of artefacts. We could also track the parts which have to be repainted manually but this would probably be more work for the CPU than the complete repaint for the GPU. At this point we see the chaining for the first time. The effects->prePaintScreen( data, time ); will call the next effect in the chain. effects is a pointer on the EffectsHandler and a very useful helper.

So now we start looking at the heart of the effect:

void ResizeEffect::paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData& data )              
    {                                                                                                                           
    effects->paintWindow( w, mask, region, data );                                                   
    if( m_active && w == m_resizeWindow )                                                                                                                 
        {                                                                                                                       
        QRegion intersection = m_originalWindowRect.intersected( w->geometry() );                                                                                                                
        QRegion paintRegion = m_originalWindowRect.united( w->geometry() ).subtracted( intersection );                                                                                                                                                          
        float alpha = 0.8f;                                                                                                                                              
        QColor color = KColorScheme( QPalette::Normal, KColorScheme::Selection ).background().color();

We first continue the paint window effect chain – this will paint the window on the screen. Now we check if we are in resizing mode (m_active) and if the currently painted window is the window which is repainted. In that case we calculate the region which has to be painted. We just subtract the intersection of current geometry with saved geometry from the union of those two. The next two lines are for the color definition. We use the background color of a selection with 80 % opacity.

Now we have to do a little bit OpenGL. In most effects where you just transform windows you don’t have to write OpenGL at all. There is a nice high level API which allows you to translate, scale and rotate windows or the complete screen. Also transforming single quads can be completely done without knowing anything about OpenGL.

#ifdef KWIN_HAVE_OPENGL_COMPOSITING
        if( effects->compositingType() == OpenGLCompositing)                                  
            {                                                                                                                   
            glPushAttrib( GL_CURRENT_BIT | GL_ENABLE_BIT );                                                                                                                                    
            glEnable( GL_BLEND );                              
            glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );                                                                                                                               
            glColor4f( color.red() / 255.0f, color.green() / 255.0f, color.blue() / 255.0f, alpha );                                                                                                                      
            glBegin( GL_QUADS );                               
            foreach( const QRect &r, paintRegion.rects() )                                                                                                  
                {                                                                                                               
                glVertex2i( r.x(), r.y() );                                                                                                                                                  
                glVertex2i( r.x() + r.width(), r.y() );           
                glVertex2i( r.x() + r.width(), r.y() + r.height() );                                
                glVertex2i( r.x(), r.y() + r.height() );          
                }                                                                                                               
            glEnd();                                                                        
            glPopAttrib();                                                                  
            }                                                                                                                   
#endif

We check if KWin uses OpenGL as a backend. We enable blending in the OpenGL state machine (needed to have translucent colors) and set the color for our rects. OpenGL clamps colors in the range [0,1] that’s why we can’t use the values from QColor directly. Last but not least we just paint one quads for each rect of our regin.

Now just the XRender part is missing. This part is taken from show paint effect – I don’t know anything about XRender 😉

#ifdef KWIN_HAVE_XRENDER_COMPOSITING
        if( effects->compositingType() == XRenderCompositing)                                 
            {                                                                                                                   
            XRenderColor col;                                                                      
            col.alpha = int( alpha * 0xffff );                                                                 
            col.red = int( alpha * 0xffff * color.red() / 255 );                       
            col.green = int( alpha * 0xffff * color.green() / 255 );                   
            col.blue= int( alpha * 0xffff * color.blue() / 255 );                      
            foreach( const QRect &r, paintRegion.rects() )                                                                                                  
                XRenderFillRectangle( display(), PictOpOver, effects->xrenderBufferPicture(),                                                                                                                          
                    &col, r.x(), r.y(), r.width(), r.height());
            }
#endif
        }
    }

This does the same as the OpenGL part just with XRender.

Last but not least we have to track the window resizing:

void ResizeEffect::windowUserMovedResized( EffectWindow* w, bool first, bool last )
    {
    if( first && last )
        {
        // not interested in maximized
        return;
        }
    if( first && w->isUserResize() && !w->isUserMove() )
        {
        m_active = true;
        m_resizeWindow = w;
        m_originalWindowRect = w->geometry();
        w->addRepaintFull();
        }
    if( m_active && w == m_resizeWindow && last )
        {
        m_active = false;
        m_resizeWindow = NULL;
        effects->addRepaintFull();
        }
    }

} // namespace

So and that’s all. When a resize event is started we activate the effect and trigger a repaint of the window (probably not needed, but doesn’t hurt). And when the resizing is finished we deactivate the effect and trigger another repaint of the complete screen just to make sure that there are no artefacts left.

The CMakeLists.txt could just be taken from any other effect and be adjusted. So here’s the example:

#######################################
# Effect

# Source files
set( kwin4_effect_builtins_sources ${kwin4_effect_builtins_sources}
    resize/resize.cpp
    )

# .desktop files
install( FILES
    resize/resize.desktop
    DESTINATION ${SERVICES_INSTALL_DIR}/kwin )

#######################################
# Config

Now you can compile and try your new effect.

Urlaub und Semesterbeginn

Letzte Woche hatte ich endlich – nach vier Jahren – mal wieder eine Woche Urlaub. Bin mit ein paar Freunden/Bekannten nach Paris gefahren. War sehr schön und sehr erholend. Leider war das Wetter nicht ganz so toll mit der Auswirkung, dass ich mir einen leichten Schnupfen eingefangen habe.

Einige Empfhelungen/Erfahrungen, die ich gemacht habe:

  • Auf den Eifelturm kurz vor der DĂ€mmerung hochfahren. So sieht man die Stadt sowohl im Hellen als auch im Dunkeln und das ist einfach nur schön.
  • Wenn man bei den Tuilerien den Triumphbogen sieht und denkt, so weit ist das nicht, sollte man daran denken, dass der Bogen 50 m hoch ist und ja die Straße ist lang
  • Die Mona Lisa ist etwas enttĂ€uschend. Man kommt nicht wirklich nah dran und im Panzerglas vor dem Bild spiegeln sich die Lampen. Abgesehen davon hat der Louvre ein schönes CafĂ©, in dem sich die nicht Kunstinteressierten verstecken können, bis der Zeitpunkt zum Treffen mit der Gruppe erreicht ist.
  • Louvre und auch Versaille erschienen mir vom GebĂ€ude her kleiner als das Mannheimer Schloß (Architektonisch definitiv: das Mannheimer Schloß hat ein Fenster mehr als das Versailler). Zumindest von außen finde ich persönlich das Mannheimer Schloß auch schöner. Von innen kenne ich in Mannheim halt nur die VorlesungssĂ€ale und die sind nicht mit Gold verzirt. Muss jetzt doch mal das Schloßmuseum besuchen.
  • Geht einer in das Restaurant und fragt nach PlĂ€tzen fĂŒr sieben Personen und ruft den Rest danach mit “Allez les enfantes”, dann muss man sich nicht wundern, wenn der Tisch zu einem Kindertisch verwandelt wird.
  • Wenn am Bahnhof sich eine Person von der Gruppe entfernt und das GepĂ€ck stehen lĂ€sst, wĂ€hrend der Rest der Gruppe sich gemeinschaftlich zum Zug begibt, dann muss man sich nicht wundern, dass das nun herrenlose GepĂ€ck von Soldaten umstellt wird (nein ich hatte nicht mein GepĂ€ck stehen lassen).
  • Man kann mit Latein doch mehr Französich lesen als ich erwartet hatte.
  • Wenn Martin Hunger hat, sollte er essen. Warten fĂŒhrt zu dem unangenehmen Effekt, dass der Magen sich irgendwie weigert Essen aufzunehmen. Man hat dann gleichzeitig Hunger und SĂ€ttigungsgefĂŒhl beim Essen. Macht die ganze Sache dann nur noch schlimmer.
  • Ein Internettablet dabei zu haben ist ganz praktisch. Vor allem OpenStreet Map mit GPS macht sich gut 😉

Da der Urlaub nun vorbei ist, hat man wieder Zeit zum Studieren. Heute war Vorlesungsbeginn in Mannheim und wie es sich fĂŒr gute Studenten gehört, hatte ich heute keine Vorlesungen. Ändert sich leider sobald in Heidelberg das Semester beginnt. Insgesamt ist mein Vorlesungsplan doch etwas voll geworden. Muss mich jeden Tag an die eine oder die ander Uni quĂ€len. Neues Semester heißt auch, dass ich jetzt wieder mit Lernen beginnen muss, da ich Ende des Monats noch eine PrĂŒfung zum letzten Semester habe.

Das ewige gehupe – oder warum mich die EM solangsam annervt

Wie einige wohl wissen, wohne ich in der Mannheimer Innenstadt. Wie allgemein auch bekannt ist, gibt es in Mannheim sehr viele MitbĂŒrger, die aus anderen europĂ€ischen LĂ€ndern stammen oder aus LĂ€ndern, die man bei bestimmten Wettbewerben zu Europa dazu zĂ€hlt. Wie auch bekannt, findet zur Zeit solch ein bestimmter Wettbewerb, die Euro 2008, statt.

Nachdem sich die Vorrunde nun zu Ende neigt, beginnen die Spiele um 20:45 Uhr. Also enden sie gegen 22:40 Uhr mit der obligatorischen Nachspielzeit. Der ideale Zeitpunkt um die Autos zu besteigen in die Innenstadt zu fahren und krĂ€ftig auf die Hupe zu drĂŒcken. Man hat auch Ausdauer: eine halbe Stunde? eine Stunde? zwei Stunden? Alles kein Problem. Interessiert es mich, dass es in Mannheim auch Menschen gibt, die um 01:00 Uhr Nachts schlafen und nicht gehupe hören wollen? Vielleicht, aber unsere Mannschaft hat doch gewonnen!

Angefangen hat alles mit dem Spiel Schweiz gegen TĂŒrkei. In der Nachspielzeit erzielen die TĂŒrken den Siegtreffer: das ist ein Nationalereignis: “Ja wir haben einen Sieg”. Hat man zu dem Zeitpunkt schon etwas erreicht? Nein – ein Sieg im zweiten Spiel, noch nicht fĂŒr das Viertelfinale qualifiziert. Trotzdem das muss gefeiert werden.

Dank des italienischen Unentschieden und der deutschen Niederlage hatte man in Mannheim erst mal wieder Ruhe. Bis, nun ja, bis die TĂŒrken wieder spielten. Sie lagen bereits 2:0 zurĂŒck gegen stark spielende Tschechen. Man freute sich auf eine ruhige Nacht… und was passiert: der tschechische Torwart greift daneben und die TĂŒrkei dreht das Spiel und qualifiziert sich fĂŒr das Viertelfinale. An dem Punkt etwas erreicht? Den Titel gewonnen? Trotzdem ein Grund zu feiern – wieder eine schlaflose Nacht.

NĂ€chster Abend: Deutschland gegen Österreich. Deutschland spielt schlecht, schwach. Das Highlight der Rausschmiss der Trainer auf die TribĂŒne. Deutschland gewinnt und qualifiziert sich auch fĂŒr das Viertelfinale. Stellt das Erreichen des Viertelfinales wirklich ein fĂŒr Deutschland bereits angemessenes Ziel da? Ist alles unter Erreichen (falls Deutschland nicht weiter kommt) des Finales nicht eine Niederlage? Gibt es also einen Grund zu hupen? Dennoch – man muss ja zeigen, dass die deutsche Bevölkerung mit den TĂŒrken es aufnehmen kann. Die Herausforderung wurde angenommen – auch wenn beim LautstĂ€rkeduell klar die TĂŒrken (noch) vorne sind.

Dienstag: Man freut sich – heute gibt es fĂŒr keine MinoritĂ€t einen Grund zu feiern. Holland wird schön brav verlieren (sind ja sicher Gruppensieger) und Italien und Frankreich fahren nach Hause. Tja Rechnung geht nicht auf: Holland gewinnt, Italien gewinnt. Italien qualifiziert sich ebenfalls fĂŒr das Viertelfinale. Ist das Erreichen des Viertelfinales wirklich ein Grund zu feiern, wenn man von Holland abgeschlachtet wurde (im ersten Spiel) und man amtierender Weltmeister ist? Offensichtlich ja: es wurde wieder gehupt.

Heute: ja heute: Es spielt Griechenland, Spanien, Rußland und Schweden. Meine Hoffnung liegt darin, dass die MinoritĂ€ten zu klein sind um mich wach zu halten…

Und die Zukunft: Morgen spielt Deutschland. Übermorgen die TĂŒrkei. Hoffnung: der tĂŒrkische Torwart ist gesperrt – er war gegen Tschechien klar der beste Mann. Ja die Hoffnung stirbt zu Letzt. Liebe Kroaten schmeißt die TĂŒrken raus – ich möchte schlafen. Am Sonntag spielt Italien gegen Spanien. Auch hier gibt es Hoffnung – ĂŒberzeugen konnte ja Italien bei dieser EM noch nicht.

Zum GlĂŒck ist am Dienstag – am Tag vor einer Klausur – spielfrei. Da werde ich also schlafen können. Und dann nur noch drei Partien… Es gibt Hoffnung auf ruhige NĂ€chte – und wenn Deutschland gewinnt: dann muss ich auch nicht schlafen 😉

Martin ist zu dumm…

… auf Worpress 2.5 upzugraden :-(
Ich hab wp-content anstatt vom backup ins neue WordPress, vom neuen ins backup kopiert. Daher fehlen nun einige Bilder, etc. Ich hoffe noch ein altes Backup zu finden und werde in Zukunft auch das WordPress Verzeichnis in mein Backup Skript miteinschließen 😉

Also hier lÀuft jetzt auch WordPress 2.5. Fehler, die sich nicht aus obigem erklÀren, bitte melden.

Ich sehe grau

Ich habe einen neuen Monitor gekauft und kann endlich Graustufen erkennen :-) Es war fĂŒrchterlich. Gerade in KDE 4 konnte ich ĂŒberhaupt keine ÜbergĂ€nge erkennen. Jetzt kann ich es richtig genießen.

Und nie wieder kaufe ich irgendetwas technisches bei einem Discounter :-(

Open Source GeschÀftsmodell

Ich hatte vor einiger Zeit mal eine ausfĂŒhrliche Diskussion mit einem VWL-Studenten ĂŒber das Open Source GeschĂ€ftsmodell. Ich hatte versprochen, dass ich mal in meinem Blog meine Sicht zu Open Source in der Wirtschaft niederschreibe und warum das Ganze ĂŒberhaupt funktioniert. NatĂŒrlich habe ich keine Ahnung von VWL, BWL und keinen Einblick in die Firmen, kann also nicht wissen, wie gut oder schlecht die verschiedenen Open Source Firmen dastehen.

Was ist Open Source?
Open Source ist eine seit 10 Jahren (Freie Software ~20 Jahre) in der Informatik existierende Bewegung, die ein konkurrierendes GeschĂ€ftsmodell zur klassischen Lizensierung von Software (ProprietĂ€re Software) darstellt. Bei proprietĂ€rer Software erhĂ€lt der KĂ€ufer (Anwender) nur eine eingeschrĂ€nkte Benutzungslizenz. Es gibt verschiedene Bezahlungsmodelle. So ist es durchaus ĂŒblich fĂŒr jede Version einmalig zu zahlen oder aber fĂŒr die mit der Software erbrachte Rechenleistung (pro Jahr, pro Anzahl Prozessoren, etc.). Der Quellcode ist jedoch nicht in der Lizenz erhalten, der KĂ€ufer erhĂ€lt meistens nur eine vorkompilierte, zum Teil angepasste BinĂ€rversion.

Bei Open Source liegt der Quelltext offen, wobei der Verkauf der Software nicht ausgeschlossen ist. So ist es durchaus möglich fĂŒr die Bereitstellung der Open Source Software als DatentrĂ€ger oder als Download Geld zu verlangen, jedoch mĂŒssen dem Nutzer bzw. KĂ€ufer einige grundlegende durch eine spezielle Softwarelizenz garantierte Freiheiten eingerĂ€umt werden. Dazu gehört die Bereitstellung des Quellcodes und das Recht diesen zu verĂ€ndern oder einfach nur weiterzugeben. Ein KĂ€ufer einer kostenpflichtigen Open Source Software hat also das Recht diese kostenfrei weiterzugeben. Daher ist in der Regel Open Source Software kostenlos erhĂ€ltlich, die anfallenden Bereitstellungskosten werden anderweitig (z.B. Werbung) finanziert. Im Allgemeinen haben sich zwei Lizenzen in der Freien und Open Source Welt durchgesetzt: die GPL und Apache Lizenz. Die GPL ist die bedeutend striktere. Sie garantiert dem Benutzer, dass die Software auch in jeder zukĂŒnftigen Version unter der gleichen Lizenz stehen wird. Die Apache Lizenz ist pragmatischer und erlaubt auch den Einsatz in proprietĂ€rer Software oder in Verbindung mit anderen Lizenzen und ist daher im unternehmerischen Bereich beliebter.

Die Community
Um die meisten Open Source Projekte has sich eine sogenannte Community entwickelt. Diese entwickelt und supportet die Software. Die Community besteht meistens sowohl aus Firmen als auch aus freiwilligen Entwicklern, die ihre Freizeit dafĂŒr opfern. Warum Firmen dabei mitarbeiten, schauen wir uns spĂ€ter an. FĂŒr die Freiwilligen gibt es verschiedene MotivationsgrĂŒnde:

  • Sie haben lange von der Software profitiert und wollen aus “Dankbarkeit” etwas zurĂŒckgeben
  • Sie wollen mithelfen das Produkt noch weiter zu verbessern, eigene Ideen einzubringen
  • Eine Möglichkeit die eigenen Kenntnisse im Rahmen eines professionellen Projekts zu verbessern
  • Durch die offene Mitarbeit sich selber profilieren und bessere Jobaussichten zu bekommen
  • viele weitere

FĂŒr mich als KDE Entwickler trifft eigentlich jeder der oberen Punkte zu. Der erste ist sicherlich der wichtigste, jedoch angesicht meines in absehbarer Zeit endendes Studiums ist auch der letzte Punkt durchaus ein wichtiger Motivationsfaktor.

Software, die in einem Community-Prozess entwickelt wird, ist von den Entwicklungskosten her bedeutend billiger als proprietĂ€re Software. Trotzdem können “Nice-to-have” Features implementiert werden, da die Entwicklung der Software nicht das GeschĂ€ftsziel ist. Community Software enthĂ€lt somit meistens mehr Features, ist in mehr Sprachen ĂŒbersetzt, mehr usable als vergleichbare konkurrierende proprietĂ€re Software. Dazu kommt, dass quelloffene Software von konkurrierenden quelloffenen Projekten durchaus profitieren kann, da es Code einfach austauschen kann.

Nun wollen wir uns den verschiedenen GeschÀftsmodellen widmen.

Dual Lizensierung
Die Dual Lizensierung ist sicherlich das interessanteste und erfolgreichste Open Source GeschĂ€ftsmodell. Das vorzeige Projekt ist Suns MySQL. Die Software wird nicht in einem Community Prozess entwickelt, sondern ausschließlich von einer Firma. Das Copyright des Quelltextes liegt somit in der Hand der Firma und diese kann die Software unter verschiedene Lizenzen stellen (Änderungen durch die Community fließen nicht in die Software ein). Im Falle von MySQL wird eine proprietĂ€re Lizenz angeboten und die GPL. Die GPL erzwingt, dass MySQL nur in Verbindung mit GPL-lizensierten Projekten verwendet werden kann. FĂŒr den einfachen Anwender (wie die vielen Webseiten) völlig ausreichend. FĂŒr große Open Source Projekte ebenfalls. So verwendet MediaWiki (die Engine der Wikipedia) MySQL, genauso wie die bekannte Blog-Software WordPress. FĂŒr Firmen ist dies jedoch nicht geeignet. Sie wollen in der Regel nicht die GPL und erwerben nun bei – in Zukunft – Sun eine Lizenz fĂŒr MySQL. Der Vorteil dieses Modells ist, dass durch die kostenlose Variante die Software schnell zum Einsatz gelangen kann und auch bei Prototypen durchaus zum Einsatz kommt. Eine proprietĂ€re Lizenz kann im Nachhinein immer noch gekauft werden. Dieser Ansatz ist so erfolgreich, dass im Januar Sun die Firma MySQL AB fĂŒr $ 1 Mrd. gekauft hat. Im Februar hat Sun auch noch die Firma Innotek gekauft, und im Januar Nokia Trolltech. Ebenfalls zwei Firmen, die dieses Lizensierungsmodell verfolgen.

Support
Das zweite bekannte Modell ist das Support Modell. Firmen bieten kostenpflichtigen Support fĂŒr Open Source Software an. So garantieren sie zum Beispiel Sicherheitsupdates bereitzustellen und helfen bei der Installation. Das Geld, das mit der Erbringung von Support erwirtschaftet wird, fließt in die Entwicklung der Open Source Software. Wir haben somit eine Trennung von Produkt und Finanzierung des Produkts. Das Produkt wird kostenfrei angeboten und dies wird ĂŒber Support finanziert. Dazu kommt, dass die Software auch von der Community entwickelt wird. Die Firma also nicht so viel Entwicklungszeit finanzieren muss und einfach nur professionell leitend eingreifen muss. FĂŒr die Community stellt das keinen Konflikt da, da die Firmen nicht mit ihrem Quellcode Geld verdienen sondern mit einem Zusatzprodukt. Die UnterstĂŒtzung durch die Firmen ist daher durchaus willkommen und auch gefordert. Prominente Beispiele dieses Modells sind RedHat und Canonical.

“Nebenprodukt”
Bei vielen großen IT-Firmen fĂ€llt Software im Rahmen eines internen Projekts als “Nebenprodukt” an. Ein klassisches Beispiel ist die Java Entwicklungsumgebung Eclipse, die von IBM entwickelt wurde. Die Firmen geben diese Produkte als Open Source frei um durch die Community eine weitere Verbesserung zu erhalten, wovon sie auch profitieren. Die Software betrifft nicht ihre Kernkompetenz und es ließe sich ohne die Community und viel Geld kein konkurrenzfĂ€higes Produkt entwickeln. Somit ist Open Source hier ideal. Es ist somit nicht wirklich ein GeschĂ€ftsmodell 😉

Der Pakt mit dem Teufel
Dies ist das letzte von mir vorgestellte GeschĂ€ftsmodell. Es ist das neuste und am wenigsten Erfolg versprechende GeschĂ€ftsmodell. Mehrere Linux Distributoren haben einen Deal mit einer konkurrierenden Firma geschlossen, der sie und zahlende Kunden vor Patentklagen schĂŒtzen soll und dafĂŒr Geld erhalten. All diese Distributionen sind entweder unbedeutend oder haben in den letzten Jahren massiv User verloren. Die Deals dĂŒrften die Firmen kurzfristig retten, jedoch langfristig besteht keine Chance fĂŒr sie. Anwender und freie Entwickler verlassen die Distributionen und wenden sich garantiert freien Distributionen zu. Dazu kommt, dass der diskriminierende Ausschluss per GPLv3 verboten ist. Die Distributionen verlieren beim Einsatz derartig lizensierter Software die Vorteile des Deals oder können die Software nicht einsezten. Langfristig werden sie dadurch keine aktuelle Software anbieten können und somit verschwinden.

Zusammenfassung
Open Source insgesammt stellt eine komplett neue wirtschaftliche Entwicklung dar. Manche wĂŒrden es sicherlich als funktionierenden Kommunismus bezeichnen, wovon ich mich jedoch distanziere. Bei Open Source geht es um sehr viel Geld – es ist also ein kapitalistisches System. Bei Open Source erfolgt eine Trennung zwischen Anbieten einer Ware und deren Finanzierung. Ein Ansatz der sich wahrscheinlich auf viele weitere Wirtschaftsbereiche ausbreiten ließe. Das Prinzip Google basiert zum Beispiel darauf (Finanzierung ĂŒber Werbung). Aber auch im Wissensbereich sehen wir zur Zeit eine klare Öffnung. Wissen ist kostenlos geworden und in Zukunft wird es den Brockhaus nur noch online geben, kostenfrei und quersubventioniert. Ich denke, dass sich das Modell der Öffnung weiter verbreiten wird und auch in anderen Bereichen zum Einsatz kommt. Warum nicht freie BauplĂ€ne, kostenlose Kaffeemaschinen, etc.? All dies ließe sich wohl quersubventionieren. Jedoch solange Open Source in kritischen Bereichen (Desktop) so eine Nischenstellung hat, werden wir es wohl kaum erleben, dass BWLer davon etwas mitbekommen. Jedoch wer weiß – vielleicht in 50 Jahren…