Kommerz-Standpunkt

Volker Grabsch vog at notjusthosting.com
Mo Feb 22 09:31:29 UTC 2010


Reinhard Müller <mueller at fsfeurope.org> schrieb:
> Am Sonntag, den 21.02.2010, 22:32 +0100 schrieb Matthias-Christian Ott:
> > Diesen Aspekt greift, wenn auch aus anderem Blickwinkel und mit anderem
> > Hintergrund, auch Dirk Riehle auf, der zwischen "Community Open Source"
> > und "Commercial Open Source" unterscheidet
> 
> Ich halte eine solche Unterscheidung für nicht sinnvoll. Zum Einen ist
> gerade bei Freier Software in sehr vielen Fällen eine sehr produktive
> Zusammenarbeit zwischen Unternehmen und der Community zu finden, sodass
> sich gar kein Trennstrich ziehen lässt. Zum Anderen bestehen für den
> Anwender zwischen den beiden Varianten keine prinzipiellen Unterschiede,
> insbesondere nicht in der Freiheit.

Das ist zwar richtig, doch ich glaube, es geht eigentlich um eine
andere Unterscheidung:

    Wie schwer ist es für Außenstehende, an dem Projekt mitzuwirken?

Natürlich kann man immer einen Fork machen, oder jemanden für die
Programmierung eines solchen beauftragen. Aber der muss parallel
zum offiziellen Projekt mitgepflegt werden. Das ist ein Haufen
unnötiger Arbeit. Allgemeiner geht es um die Frage, wie generell
mit Kontributoren und potentiellen neuen Mithelfern umgegangen
wird, und auch wie mit Ideen und Verbesserungs-Vorschlägen von
Außenstehenden umgegangen wird. Man könnte die Frage daher auch
anders stellen:

    Wie offen ist das Projekt?

    ("offen" im organisatorischen Sinn, nicht zu verwechseln
     mit dem "offen" aus "Open Source".)

Ich persönlich bin immer heilfroh, wenn zumindest ein Großteil meiner
Änderungen auch wieder ins Hauptprojekt einfließt und dann automatisch
dort mitgepflegt wird. Dass dafür ein paar sachliche Diskussionen und
ggf. Verbesserungen meiner Zuarbeit nötig sind, versteht sich von
selbst. Doch wenn das Einbringen mehr mit Politik, Vitamin B, etc.
zu tun hat, dann ist das abschreckend, und in manchen Fällen ist diese
Abschreckung womöglich sogar gewollt.

> Einer Unterscheidung in "einfach frei" und "doppelt frei",
> je nachdem, ob der Entwickler für seine Arbeit bezahlt wird oder nicht,
> kann ich definitiv nichts abgewinnen.

Mit "einfach frei" und "doppelt frei" war ja auch etwas anderes
gemeint.

Doch ich stimme zu, dass die Eigenschaften kommerziell/nichtkommerziell
und offen/verschlossen getrennt behandelt werden sollten. Hier ein
paar Beispiele:


    verschlossen und kommerziell

        Gerüchtehalber soll MySQL seit Jahren ihre Kontributoren
        nicht besonders gut behandeln. (Sorry, hab leider keine
        Quelle parat.)
        
        Das ist wohl der Hauptgrund, warum PostgreSQL soviel
        Domain-Expertenwissen (im vgl. zu MySQL) bündelt. Man
        denke nur an PostGIS und die XML-Datentypen. Es hat einen
        Grund, warum solche Dinge bei MySQL noch in den Kinderschuhen
        stecken.

    offen und nichtkommerziell

        PostgreSQL, Linux-Kernel, ...

    offen und kommerziell

        Exiv2 macht das sehr gut. Der Autor fährt eine Doppellizenz-
        Strategie und bittet jeden Kontributor um eine entsprechende
        Übertragung der Rechte. Doch man kann super mit ihm reden und
        seine Bedenken gegenüber Zuarbeiten waren stets sachlicher /
        technischer Natur. Mit dieser Art von kommerziellen Projekten
        arbeitet man gern zusammen.

    verschlossen und nichtkommerziell

        Ja, das gibt es auch.  :-(
        
        Qmail ist der Klassiker. Dessen Autor hat es kurzerhand
        als Feature-Komplett deklariert, und nur noch Sicherheits-
        Patches eingepflegt, wobei er selbst dort nur kritische
        Fixes annahm.

        Firefox würde ich auch dazu zählen. Es gibt zwar AddOns,
        zu denen jeder war beisteuern kann, aber die werden bewusst
        vom Kernprojekt separiert. Es ist viel politische Arbeit
        nötig, um etwas in den eigentlichen Browser zu bekommen.
        Das hat natürlich auch Sicherheits-Gründe, aber in erster
        Linie ist es doch "Projekt-Politik", die qualitativ gute
        Zuarbeiten ablehnt. (auch hier: leider nur Hörensagen)


Meine Ansicht zu "Plugins" (oder "Extensions", "AddOns", ...) ist
übrigens, dass diese Schnittstellen an sich die Zuarbeit verbessern,
technisch gesehen. Doch einige Projekte distanzieren sich dann von
ihren Plugins, auch von den hochwertigen, statt sie standardmäßig
mit auszuliefern. Dann wird die Plugin-Architektur zu einer Fassade,
die einem verschlossenen Projekt den Anschein von Offenheit geben
soll.

Insbesondere weiß ich nicht, was ich z.B. von CMS-Plugins halten soll.
Typo3 hat sie gut integriert und macht z.T. auch Qualitäts-Checks.
Bei anderen Projekten wie Joomla und Drupal jedoch wirkt es eher
aufgesetzt.


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR



Mehr Informationen über die Mailingliste FSFE-de