Neben kommerzieller propriet\u00e4rer Software wie dem Betriebssystem und der Office-Suite von Microsoft oder der Adobe-Produktfamilie gibt es inzwischen eine Reihe von weit verbreiteter OpenSource-Software wie zum Beispiel den Linux-Kernel, Open-\/Libreoffice, Inkskape, WordPress, MySQL, Apache und viele mehr. Gemeinsam haben diese Projekte, dass der Quellcode unter einer freien Lizenz<\/em> stehen. Eine freie Lizenz<\/em> ist eine Lizenz, die es Dritten erlaubt, den Code zu beliebigen Zwecken zu verwenden und somit zum Beispiel das Projekt weiterzuentwickeln oder Einzelheiten anzupassen. Strengere Lizenzen wie die GPL erzwingen sogar, dass nach einer Anpassung der Code offen bleiben muss, also alle Verbesserungen den Benutzern der Software bereitgestellt werden m\u00fcssen. F\u00fcr den Anwender hat das den Vorteil, dass eine Software nicht “eingestellt” werden kann, sondern er notfalls die Software weiterpflegen kann. Ebenfalls macht man sich damit von einztelnen Herstellern unabh\u00e4ngig und kann Support von beliebigen Firmen, wie zum Beispiel bei der Softwareschmiede Launix<\/a> kaufen.<\/p>\n Doch wenn jeder an dem Code arbeiten kann, wie funktioniert dann die Zusammenarbeit? Ist es wie im Wiki, dass jeder dazuschreibt oder wegl\u00f6scht, wie er gerade Lust hat? Weit gefehlt! In der OpenSource-Welt wird Qualit\u00e4tskontrolle<\/b> ganz gro\u00df geschrieben. Die Grundpfeiler des OpenSource-Entwicklungsmodells<\/em> sind folgende:<\/p>\n Ein Versionskontrollsystem ist ein St\u00fcck Software, das es Entwicklern erlaubt, eine gemeinsame Sicht auf alle Dateien des Projekts zu haben. Ein Versionskontrollsystem ist zum Beispiel Mercurial<\/a>, welches in diesem Artikel<\/a> n\u00e4her erl\u00e4utert wird. Ein weiteres, beliebtes Versionskontrollsystem ist Git<\/a>.<\/p>\n Das Versionskontrollsystem unterst\u00fctzt die Entwickler bei der Verwaltung von Dateien, sowie dem Austauschen von \u00c4nderungen an dem Projekt und dem Code Review. Versionskontrollsysteme sind in heutigen Projekten nicht mehr wegzudenken. Ohne sie m\u00fcsste man sich ZIP-Dateien per E-Mail hin- und herschicken.<\/p>\n Eine Schl\u00fcsselrolle in einem OpenSource-Projekt spielt der Maintainer. Ein Maintainer ist entweder eine Einzelperson, eine Personengruppe, eine Firma oder ein Zusammenschluss von Firmen. Der Maintainer hat die Verantwortung f\u00fcr das Projekt. OpenSource basiert darauf, dass jeder mitmacht. Ohne eine Hierarchie funktioniert es allerdings nicht. Der Maintainer f\u00fchrt die Arbeit, die die einzelnen, verstreuten Mitarbeiter machen, zusammen. S\u00e4mtliche \u00c4nderungen an der Software, die von Mitarbeitern gemacht werden, m\u00fcssen vom Maintainer abgesegnet werden.<\/p>\n Im Linux-Kernel sieht das zum Beispiel so aus, dass Linus Torvalds der oberste Maintainer des Projektes ist. Die 3 Millionen Entwickler am Kernel allerdings unter einen Hut zu bekommen, ist f\u00fcr eine Person schlicht zu aufwendig. Aus diesem Grund gibt es weitere 100 Maintainer, die sich um einzelne Teilbereiche k\u00fcmmern. Diese Maintainer tragen dann die \u00c4nderungen an Linus Torvalds heran, der diese endg\u00fcltig absegnet.<\/p>\n Ein Maintainer ist eine Art “wohlwollender Diktator” – er hat volle Entscheidungsgewalt \u00fcber das Projekt und kann entscheiden, welche \u00c4nderungen aufgenommen werden und welche nicht. Es ist schon oft passiert, dass \u00c4nderungen aufgrund der Befindlichkeit des Maintainers nicht aufgenommen wurden. Aus diesem Grund gibt es noch die M\u00f6glichkeit des forkens<\/em>. Ein Fork (engl. Gabel) ist eine Abzweigung des Projekts. Eine Person oder eine Gruppe von Personen sind mit der Arbeit des Maintainers nicht zufrieden und entscheiden sich, das Projekt selbst weiterzuf\u00fchren. Dazu nehmen sie den Quellcode in der neuesten Version und ver\u00f6ffentlichen die Software anschlie\u00dfend auf eigene Faust und entwickeln sie weiter. Was auf den ersten Blick wie ein Diebstahl aussieht, ist aufgrund der verwendeten freien Lizenzen<\/b> eine legitime Aktion. Ein prominentes Beispiel ist das OpenOffice<\/em>-Projekt, f\u00fcr das Oracle der Maintainer ist. Die urspr\u00fcnglichen Entwickler von OpenOffice waren mit Oracle nicht mehr zufrieden und haben die Document Foundation<\/em> gegr\u00fcndet, die das Projekt nun unter dem Namen LibreOffice<\/em> herausgibt.<\/p>\n Durch Forking entstehen aus einem Projekt mehrere Projekte, von denen in der Regel das weniger aktive fr\u00fcher oder sp\u00e4ter aufgegeben wird oder beide Projekte sp\u00e4ter wieder fusionieren. Es kann sogar passieren, dass gewissen Anwendern eine \u00e4ltere Version der Software besser gef\u00e4llt und sie einen veralteten Stand der Software forken und anschlie\u00dfend nur noch Fehler beheben. Forks beleben die OpenSource-Szene, da sie eine stetige Weiterentwicklung garantieren, auch wenn sich gewisse Menschen in dem Prozess querstellen.<\/p>\n Die zwei Hauptaufgaben des Maintainers ist die Paketierung des Projekts (Anbieten von Downloads) und der Code Review. Beim Code Review geht es darum, \u00c4nderungen, die an den Maintainer herangetragen werden, zu akzeptieren oder abzulehnen. Die Plattform Github<\/a> beispielsweise unterst\u00fctzt diesen Prozess aktiv: Ein Entwickler kann das Projekt kopieren, weiterentwickeln und anschlie\u00dfend einen sogenannten Pull Request<\/em> schicken. Der Maintainer wird informiert, dass jemand das Projekt weiterentwickelt wollte. Er schaut sich die \u00c4nderungen an, die in sogenannten Changesets<\/em> angelegt sind. Changesets sagen genau, in welcher Datei welche Zeilen ge\u00e4ndert werden mussten, um zum Beispiel eine neue Funktion in das Programm einzubauen. Der Maintainer, der gleichzeitig ein erfahrener Programmierer ist, entscheidet dann, ob der Entwickler sauber gearbeitet hat. Macht der Bittsteller selbst kleinste Fehler, wird die Abnahme abgelehnt und er muss nachkorrigieren. Ein Grund f\u00fcr eine Ablehnung kann zum Beispiel sein, dass der Entwickler die Codezeilen falsch einger\u00fcckt hat oder einen Rechtschreibfehler gemacht hat. Doch auch b\u00f6sartige \u00c4nderungen, wie zum Beispiel eingeschleuste Viren, werden abgelehnt.<\/p>\n Sieht der Code gut aus, testet der Maintainer noch, ob der Code auch wirklich die Funktion erf\u00fcllt, die er verspricht. Er testet das Programm auch, ob es noch die urspr\u00fcngliche Funktion beh\u00e4lt. Eine \u00c4nderung, die zwar eine Verbesserung bringt, daf\u00fcr aber verschiedene Funktionen am Programm zerst\u00f6rt oder dort Fehler einschleust, wird ebenfalls abgelehnt. Ist die \u00c4nderung dann endg\u00fcltig getestet, wird sie in den Hauptzweig<\/em>, das Offizielle Projekt aufgenommen. Hat ein Entwickler eine gr\u00f6\u00dfere \u00c4nderung eingebracht, wird er meistens auch gebeten, diesen Code weiterhin zu pflegen. So m\u00fcssen zum Beispiel im Linux-Kernel die Hardware-Hersteller auf Probleme mit ihren beigesteuerten Treibern per E-Mail erreichbar sein, ansonsten wird ihr Beitrag zum Kernel wieder entfernt.<\/p>\n Eine weitere, untergeordnete Rolle spielen die Distributoren. Sie laden sich den Quellcode der Projekte regelm\u00e4\u00dfig herunter, erstellen daraus Softwarepakete und \u00fcberpr\u00fcfen, dass die Software noch mit anderer Software zusammenarbeitet und verteilt Updates an Anwender. Ein sehr erfolgreicher Distributor ist Canonical<\/em>, welcher die Linux-Distribution Ubuntu<\/em> betreut. Distributoren sind im losen Kontakt mit den Maintainern und tauschen sich dar\u00fcber aus, wann wie oft neue Versionen der Software ver\u00f6ffentlicht werden sollen. Auch sammelt meist der Distributor Informationen \u00fcber Fehler in den Programmen und reicht sie an den Maintainer weiter. K\u00fcmmert sich der Maintainer nicht schnell genug um die Behebung eines Fehlers, kann es auch passieren, dass der Distributor den Fehler selbst behebt und die korrigierte Version an den Maintainer einreicht. Manchmal ver\u00f6ffentlicht der Distributor die fehlerbereinigte Version sogar eher als der Maintainer, da die Kunden des Distributors den Fehler meist so schnell wie m\u00f6glich behoben haben wollen.<\/p>\n Zu guter letzt darf man die Anwender der Software nicht vergessen. Sie sind der Grund, weshalb die Software \u00fcberhaupt existiert. Sie benutzen die Software f\u00fcr ihre t\u00e4gliche Arbeit und ihnen wird als erstes ein Fehler in der Software auffallen. Die Anwender haben im OpenSource-Bereich auch eine Aufgabe. Sie m\u00fcssen Fehler, die sie an der Software entdecken, an ihren Distributor oder den Maintainer melden. Nur so besteht eine Chance, dass Fehler auch behoben werden. Au\u00dferdem entscheiden die Anwender bei Forks, welcher Fork der beliebtere ist und zwingen so einen ungeeigneten oder restriktiven Maintainer zur Aufgabe.<\/p>\n OpenSource-Software bietet aufgrund des fortschrittlichen Entwicklungsmodells einen Qualit\u00e4tsvorsprung gegen\u00fcber propriet\u00e4rer Software. Durch die M\u00f6glichkeit, dass jeder mitentwickeln darf, wird genauer auf die Bed\u00fcrfnisse der (meist programmierf\u00e4higen) Anwender eingegangen. Propriet\u00e4re Softwareschmieden sollten ihre Entwicklungsprozesse anpassen und die Methoden, die sich in der OpenSource-Szene etabliert haben, kopieren. An die endg\u00fcltige Bandbreite eines Projektes wie des Linux-Kernels wird allerdings kein propriet\u00e4rer Hersteller herankommen. Die beste L\u00f6sung f\u00fcr Anwender ist immer noch, freie Software zu benutzen und bei Bedarf selbst anzupassen und die Verbesserung an den Maintainer einzureichen, damit jeder etwas davon hat.<\/p>\n","protected":false},"excerpt":{"rendered":" Propriet\u00e4r oder OpenSource? Neben kommerzieller propriet\u00e4rer Software wie dem Betriebssystem und der Office-Suite von Microsoft oder der Adobe-Produktfamilie gibt es inzwischen eine Reihe von weit verbreiteter OpenSource-Software wie zum Beispiel den Linux-Kernel, Open-\/Libreoffice, Inkskape, WordPress, MySQL, Apache und viele mehr. Gemeinsam haben diese Projekte, dass der Quellcode unter einer freien Lizenz stehen. Eine freie Lizenz…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_editorskit_title_hidden":false,"_editorskit_reading_time":0,"_editorskit_is_block_options_detached":false,"_editorskit_block_options_position":"{}","_uag_custom_page_level_css":"","footnotes":""},"categories":[1],"tags":[69,72],"class_list":["post-1004","post","type-post","status-publish","format-standard","hentry","category-allgemein","tag-offtopic","tag-programmieren","single-item"],"featured_image_urls_v2":{"full":"","thumbnail":"","medium":"","medium_large":"","large":"","1536x1536":"","2048x2048":"","trp-custom-language-flag":"","xs-thumb":"","appku-shop-single":""},"post_excerpt_stackable_v2":" Propriet\u00e4r oder OpenSource? Neben kommerzieller propriet\u00e4rer Software wie dem Betriebssystem und der Office-Suite von Microsoft oder der Adobe-Produktfamilie gibt es inzwischen eine Reihe von weit verbreiteter OpenSource-Software wie zum Beispiel den Linux-Kernel, Open-\/Libreoffice, Inkskape, WordPress, MySQL, Apache und viele mehr. Gemeinsam haben diese Projekte, dass der Quellcode unter einer freien Lizenz stehen. Eine freie Lizenz ist eine Lizenz, die es Dritten erlaubt, den Code zu beliebigen Zwecken zu verwenden und somit zum Beispiel das Projekt weiterzuentwickeln oder Einzelheiten anzupassen. Strengere Lizenzen wie die GPL erzwingen sogar, dass nach einer Anpassung der Code offen bleiben muss, also alle Verbesserungen den Benutzern…<\/p>\n","category_list_v2":"Allgemein<\/a>","author_info_v2":{"name":"Carl-Philip H\u00e4nsch","url":"https:\/\/launix.de\/launix\/author\/carli\/"},"comments_num_v2":"0 comments","uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false,"trp-custom-language-flag":false,"xs-thumb":false,"appku-shop-single":false},"uagb_author_info":{"display_name":"Carl-Philip H\u00e4nsch","author_link":"https:\/\/launix.de\/launix\/author\/carli\/"},"uagb_comment_info":0,"uagb_excerpt":"Propriet\u00e4r oder OpenSource? Neben kommerzieller propriet\u00e4rer Software wie dem Betriebssystem und der Office-Suite von Microsoft oder der Adobe-Produktfamilie gibt es inzwischen eine Reihe von weit verbreiteter OpenSource-Software wie zum Beispiel den Linux-Kernel, Open-\/Libreoffice, Inkskape, WordPress, MySQL, Apache und viele mehr. Gemeinsam haben diese Projekte, dass der Quellcode unter einer freien Lizenz stehen. Eine freie Lizenz...","_links":{"self":[{"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/posts\/1004","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/comments?post=1004"}],"version-history":[{"count":1,"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/posts\/1004\/revisions"}],"predecessor-version":[{"id":1005,"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/posts\/1004\/revisions\/1005"}],"wp:attachment":[{"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/media?parent=1004"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/categories?post=1004"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/launix.de\/launix\/wp-json\/wp\/v2\/tags?post=1004"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Prinzipien<\/h2>\n
\n
Benutzung eines Versionskontrollsystems<\/h2>\n
Maintainer und Forks<\/h2>\n
Code Review<\/h2>\n
Distributoren<\/h2>\n
Anwender<\/h2>\n
Fazit<\/h2>\n