Was ist Open-Source, und warum?

Sie denken also über einen Sprung in die Open-Source-Welt nach? Herzlichen Glückwunsch, die Welt weiß Ihren Beitrag zu schätzen! Lassen Sie uns darüber sprechen, was Open-Source ist und warum sich Leute dafür engagieren.

Was genau bedeutet “Open-Source”?

Ein Open-Source-Projekt kann von jedem Menschen für jeden Zweck verwendet, inspiziert, modifiziert und weiterverbreitet werden. Diese Rechte werden mittels einer Open-Source-Lizenz durchgesetzt.

Open-Source ist so mächtig, weil es Barrieren für Nutzung und Zusammenarbeit senkt und Personen somit ermöglicht, Ideen schneller zu verbreiten und Dinge schneller zu verbessern. Zudem ermöglicht es den Benutzer*innen*n, ihr eigenes Computing besser unter Kontrolle zu behalten, als mit proprietären Lösungen. Ein Unternehmen, das Open-Source-Software verwendet, kann beispielsweise jemanden einstellen, um maßgeschneiderte Verbesserungen an der Software vorzunehmen, anstatt von den Produktentscheidungen des Anbieters abhängig zu sein.

Freie Software meint dieselbe Art von Projekten wie Open-Source. Der Begriff wird manchmal auch kombiniert mit “Freie/Libre und Open-Source-Software” (FOSS bzw. FLOSS). Frei und Libre meinen hierbei die Freiheit, nicht den Preis.

Warum veröffentlichen Menschen den Quellcode ihrer Software?

Es gibt viele Gründe warum eine Person oder Organisation ein Projekt open-sourcen wollen würde. Beispielsweise:

  • Zusammenarbeit: Open-Source-Projekte nehmen Beiträge aus der ganzen Welt an. Exercism beispielsweise ist eine Programmierübungsplatform mit über 350 Kontributor*innen.

  • Anpassungen: Open-Source-Projekte können von jedem Menschen für fast jeden Zweck benutzt werden. Leute können daraus sogar andere Dinge bauen. WordPress beispielsweise begann als ein Fork eines existierenden Projekts namens b2.

  • Transparenz: In einem Open-Source-Projekt können Fehler oder Ungereimtheiten von jedem behoben werden. Transparenz ist sowohl für Regierungen in Bulgarien oder den Vereinigten Staaten, für regulierte Industrien wie den Banken- oder Gesundheitssektor und für Sicherheitssoftware wie Let’s Encrypt gleichermaßen wichtig.

Open-Source ist nicht nur für Software, sondern auch für alle anderen Bereiche geeignet, von Datensätzen bis hin zu Büchern. Stöbern Sie durch GitHub Explore, um einen Eindruck der thematischen Breite von Open-Source-Projekten zu bekommen.

Bedeutet Open-Source auch “gratis”?

Einer der größten Vorteile von Open-Source ist, dass es kein Geld kostet. “Gratis” dagegen ist nur ein Nebenprodukt des Gesamtwertes.

Weil eine Open-Source-Lizenz bedingt, dass jeder die Software nutzen, modifizieren, und weiterverbreiten darf (für nahezu jeden Zweck), nehmen die Projekte selbst meist kein Geld dafür. Wenn sie es täten, könnte jeder ganz legal die Projekte kopieren und die dann freie Version nutzen.

Daher sind die meisten Open-Source-Projekte kostenlos, aber das ist kein Teil der Open-Source-Definition. Es gibt für Open-Source-Projekte Möglichkeiten, sich indirekt bezahlen zu lassen (z.B. über Doppel-Lizenzierung oder eingeschränkte Funktionen) und dabei trotzdem die offizielle Definition von Open-Source weiterhin einzuhalten.

Sollte ich mein eigenes Open-Source-Projekt starten?

Die kurze Antwort ist “Ja!”, denn egal wie das Ergebnis aussieht: Ein eigenes Projekt zu starten ist eine großartige Möglichkeit zu lernen, wie Open-Source funktioniert.

Wenn Sie noch nie den Quellcode eines Projektes geöffnet haben, werden Sie vielleicht nervös darüber sein, was die Leute sagen werden, oder ob es jemandem auffallen wird. Mit diesen Bedenken sind Sie nicht allein!

Open-Source-Arbeit ist eine kreative Aktivität wie Schreiben oder Malen, oder anderes. Es kann beängstigend sein, seine Arbeit mit der Welt zu teilen. Jedoch ist Übung der einzige Weg besser zu werden, auch wenn man kein Publikum hat.

Wenn Sie noch nicht überzeugt sind, nehmen Sie sich einen Moment Zeit, um darüber nachzudenken, was Ihre Ziele sein könnten.

Ihre Ziele definieren

Ziele können Ihnen helfen, herauszufinden, woran Sie arbeiten sollen, was Sie ablehnen sollten und wo Sie Hilfe von anderen brauchen. Fragen Sie sich zuerst: Warum starte ich dieses Projekt?

Es gibt keine richtige Antwort auf diese Frage. Vielleicht haben Sie mehrere Ziele für ein einzelnes Projekt oder verschiedene Projekte mit unterschiedlichen Zielen.

Wenn es Ihr einziges Ziel ist, Ihre Arbeit zu zeigen, wollen Sie vielleicht nicht einmal Beiträge und sagen dies sogar in Ihrer README. Andererseits, wenn Sie sich Beiträge wünschen: Investieren Sie Zeit in eine klare Dokumentation, damit sich Neuankömmlinge willkommen fühlen.

Wenn Ihr Projekt wächst, braucht Ihre Community mehr als nur Code von Ihnen. Die Reaktion auf Probleme, die Überprüfung von Code und das Anpreisen Ihres Projekts sind alles wichtige Aufgaben in einem Open-Source-Projekt.

Während die Zeit, die Sie für nicht-Programmieraufgaben aufwenden, von der Größe und dem Umfang Ihres Projekts abhängt, sollten Sie als Betreuer*in darauf vorbereitet sein, diese selbst anzugehen oder jemanden zu finden, der Ihnen hilft.

Wenn Sie Teil eines Unternehmens sind, das ein Projekt startet, stellen Sie sicher, dass Ihr Projekt über die internen Ressourcen verfügt, die es braucht, um zu gedeihen: Sie wollen klarstellen, wer für die Wartung des Projekts nach dem Start verantwortlich ist und wie Sie diese Aufgaben mit Ihrer Community teilen.

Wenn Sie ein dediziertes Budget oder Personal für Werbung, Betrieb und Wartung des Projekts benötigen, planen Sie dies frühzeitig.

Zu anderen Projekten beitragen

Ist Ihr Ziel zu lernen, wie man mit anderen zusammenarbeitet oder wie Open-Source funktioniert, sollten Sie in Erwägung ziehen zu einem bestehenden Projekt beizutragen. Dies kann so einfach sein wie die Korrektur von Tippfehlern oder das Aktualisieren der Dokumentation.

Wenn Sie sich nicht sicher sind, wie Sie als Mitwirkende*r anfangen können, schauen Sie sich unseren Artikel “Wie zu Open-Source beitragen?” an.

Ein eigenes Open-Source-Projekt starten

Es gibt keine perfekte Zeit, um Ihre Arbeit zu veröffentlichen. Sie können eine Idee, ein in Arbeit befindliches Projekt, oder ein Jahre altes Closed-Source-Projekt öffnen.

Im Allgemeinen können Sie sich für Open-Source entscheiden, wenn Sie möchten, dass andere Ihre Arbeit sehen sollen und bereit sind, Feedback zu akzeptieren.

Unabhängig davon, in welcher Phase Sie sich für Open-Source entscheiden, sollte jedes Projekt die folgende Dokumentation enthalten:

Als Maintainer*in helfen Ihnen diese Komponenten, Erwartungen zu kommunizieren, Beiträge zu verwalten und die gesetzlichen Rechte aller (einschließlich Ihrer eigenen) zu schützen. Sie tragen zudem zu einer positiven Erfahrung in Ihrem Projekt bei.

Wenn sich Ihr Projekt auf GitHub befindet, können Sie diese Dateien mit den empfohlenen Dateinamen in Ihrem Stammverzeichnis ablegen, damit GitHub sie erkennt und automatisch an Ihre Leser*innen weitergeben kann.

Eine Lizenz auswählen

Eine Open-Source-Lizenz garantiert, dass andere Ihr Projekt ohne Nebenwirkungen nutzen, kopieren, modifizieren und wieder einbringen können. Außerdem schützt sie Sie vor unangenehmen rechtlichen Situationen. Wenn Sie ein Open-Source-Projekt starten, müssen Sie eine Lizenz angeben.

Rechtsangelegenheiten sind kein Spaß. Die gute Nachricht ist, dass Sie eine bestehende Lizenz kopieren und in Ihr Repository einfügen können. Es dauert also nur eine Minute, Ihre harte Arbeit zu schützen.

MIT, Apache 2.0, und GPLv3 sind die populärsten Open-Source-Lizenzen, aber es gibt viele andere zur Auswahl.

Wenn Sie ein neues Projekt auf GitHub erstellen, haben Sie die Möglichkeit, eine Lizenz auszuwählen. Mit einer Open-Source-Lizenz wird Ihr GitHub-Projekt auch wirklich zum Open-Source-Projekt.

Eine Lizenz auswählen

Wenn Sie weitere Fragen oder Bedenken bezüglich der rechtlichen Aspekte der Verwaltung eines Open-Source-Projekts haben, können Sie sich an uns wenden.

Eine README schreiben

READMEs erklären nicht nur, wie Sie Ihr Projekt verwenden, sondern auch, warum Ihr Projekt wichtig ist und was Ihre Benutzer*innen damit machen können.

Versuchen Sie in Ihrer README folgende Fragen zu beantworten:

  • Was macht dieses Projekt?
  • Warum ist es nützlich?
  • Wie kann ich es nutzen oder dazu etwas beitragen?
  • Wo wird mir geholfen, wenn ich Hilfe benötige?

Sie können Ihre README verwenden, um andere Fragen zu beantworten: z.B. wie Sie mit Beiträgen handhaben, welche Ziele das Projekt verfolgt, oder wie es um Lizenzen und Zuschreibungen steht. Wenn Sie keine Beiträge annehmen wollen oder Ihr Projekt noch nicht produktionsreif ist, schreiben Sie auch diese Informationen auf.

Manchmal vermeiden es Leute, eine README zu schreiben, weil sie das Gefühl haben, das Projekt sei unvollendet, oder weil sie keine Beiträge wollen. Aber auch dies sind gute Gründe, eine zu schreiben.

Weitere Inspirationen zum Schreiben einer README finden Sie in @dguo’s “Make a README”-Anleitung oder in @PurpleBooth’s README-Vorlage.

Wenn Sie eine README-Datei im Hauptordner Ihres Projektes anlegen, zeigt GitHub diese automatisch auf der Homepage des Repos an.

Ihre Beitragsrichtlinien aufschreiben

Eine CONTRIBUTING-Datei erklärt Ihrem Publikum, wie es zu Ihrem Projekt beitragen kann. Folgende Informationen können darin beispielsweise enthalten sein:

  • Wie eine Fehlerbericht eingereicht werden kann (probieren Sie hierfür die Issue- und Pull-Request-Vorlagen)
  • Wie neue Funktionen vorgeschlagen werden sollten
  • Wie die Entwicklungsumgebung eingerichtet wird
  • Wie getestet wird

Neben thematischen Details präsentiert die CONTRIBUTING-Datei auch Ihre Erwartungen an Beiträge, z.B:

  • Wie Sie möchten, dass andere beitragen
  • Ihre Pläne und Ziele für das Projekt
  • Wie Mitwirkende Sie kontaktieren sollten (oder auch nicht)

Mit einem warmen, freundlichen Ton und spezifischen Vorschlägen für Beiträge (wie z.B. “Dokumentationen verfassen” oder “eine Website erstellen”) können Sie dazu beitragen, dass sich Neuankömmlinge willkommen und wohlfühlen.

Beispielsweise leitet Active Admin ihre Beitragsrichtlinien ein mit:

Zuerst einmal vielen Dank, dass Sie überlegt haben, einen Beitrag zu Active Admin zu leisten, denn es sind Menschen wie Sie, die Active Admin so großartig machen.

First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.

In der Anfangsphase Ihres Projekts kann Ihre CONTRIBUTING-Datei einfach sein. Sie sollten immer erklären, wie Fehler oder Probleme gemeldet werden können und welche technischen Anforderungen (z.B. Tests) Leute erfüllen müssen, um einen Beitrag zu leisten.

Im Laufe der Zeit können Sie weitere häufig gestellte Fragen zu Ihrer CONTRIBUTING-Datei hinzufügen. Diese Informationen aufzuschreiben verhindert, dass weniger Leute die immer wieder gleichen Fragen stellen werden.

@nayafia’s CONTRIBUTING-Vorlage oder @mozilla’s “How to Build a CONTRIBUTING.md” helfen Ihnen, Ihre Beitragsrichtlinien zu entwerfen.

Verlinken Sie Ihre CONTRIBUTING-Datei in Ihrer README, damit sie gleich bemerkt wird. Wenn Sie sie zudem in Ihr Repo einchecken, wird GitHub automatisch auf sie aufmerksam machen, wenn jemand ein Issue oder Pull Request erstellt.

Beitragsrichtlinien

Einen Verhaltenskodex etablieren

Letztendlich hilft ein Verhaltenskodex, Grundregeln für das Verhalten der Projektbeteiligten festzulegen - insbesondere wenn Sie ein Open-Source-Projekt für eine Community oder ein Unternehmen starten. Ein Verhaltenskodex hilft Ihnen, ein gesundes, konstruktives Gemeinschaftsverhalten zu fördern, das Ihnen als Maintainer*in Stress erspart.

Weitere Information finden Sie in unserer Anleitung für Verhaltenskodizes.

Neben der Klarstellung, welches Verhalten Sie von den Mitwirkenden erwarten, beschreibt ein Verhaltenskodex auch, auf wen sich diese Erwartungen beziehen, wann sie gelten und was zu tun ist, wenn ein Verstoß vorliegt.

Ähnlich zu Open-Source-Lizenzen, kommen auch Standards für Verhaltenskodizes auf, sodass Sie keinen komplett eigenen schreiben müssen. Der Contributor Covenant ist ein einsatzbereiter Verhaltenskodex, der von über 40’000 Open-Source-Projekten verwendet wird, einschließlich Kubernetes, Rails und Swift. Egal welchen Text Sie nutzen, Sie sollten vorbereitet sein, ihn wenn nötig auch durchzusetzen.

Fügen Sie den Text direkt in eine CODE_OF_CONDUCT-Datei in Ihrem Repository ein. Halten Sie die Datei im Stammverzeichnis Ihres Projekts, damit sie leicht zu finden ist, und verlinken Sie sie von Ihrer README.

Ihr Projekt benennen und zur Marke machen

Eine Marke besteht aus mehr als einem auffälligen Logo oder einem einprägsamen Projektnamen. Es geht darum, wie Sie über Ihr Projekt sprechen und wen Sie mit Ihrer Botschaft erreichen.

Den richtigen Namen auswählen

Wählen Sie einen Namen, der leicht zu merken ist und im Idealfall eine Vorstellung davon vermittelt, was das Projekt bewirkt. Beispielsweise:

  • Sentry überwacht Apps und meldet Abstürze
  • Thin ist ein schneller, einfacher Web-Server in Ruby

Wenn Sie auf einem bestehenden Projekt aufbauen, kann die Verwendung des Namens als Präfix helfen, zu klären, was Ihr Projekt tut (node-fetch z.B. implementiert window.fetch für Node.js).

Denken Sie vor allem an die Klarheit. Wortspiele machen Spaß, aber denken Sie daran, dass manche Witze nicht in andere Kulturen oder für Menschen mit anderen Erfahrungen als Ihren, übersetzt werden können. Einige Ihrer potenziellen Nutzer*innen könnten Mitarbeiter*innen in Unternehmen sein: Sie wollen es ihnen nicht unangenehm machen, wenn sie Ihr Projekt bei der Arbeit erklären müssen!

Namenskonflikte vermeiden

Prüfen Sie, ob es Open-Source-Projekte mit ähnlichem Namen gibt, insbesondere in derselben Sprache oder demselben Ökosystem. Wenn Ihr Projektname mit einem existierenden, populären Projekt überlappt, könnte das Ihr Publikum verwirren.

Wenn Sie möchten, dass eine Website, ein Twitter-Handle, o.Ä. Ihr Projekt repräsentieren, stellen Sie sicher, dass Sie die von Ihnen gewünschten Namen erhalten können. Um auf Nummer sicher zu gehen, können Sie diese Namen jetzt reservieren, auch wenn Sie sie noch nicht verwenden möchten.

Achten Sie darauf, dass der Name Ihres Projekts keine Marken verletzt, denn ein Unternehmen könnte Sie auffordern, Ihr Projekt zu einem späteren Zeitpunkt abzubrechen. Im schlimmsten Fall leitet ein Unternehmen sogar rechtliche Schritte gegen Sie ein. Dieses Risiko einzugehen, ist es einfach nicht wert.

Nutzen Sie die WIPO Global Brand Database, um auf Namenskonflikte zu prüfen. Wenn Sie in einer Firma sind, ist dies eine der Aufgaben, bei denen Ihr Justiziariat Sie unterstützen kann.

Zum Schluss noch eine schnelle Google-Suche nach Ihrem Projektnamen: Werden die Leute Ihr Projekt leicht finden können, oder erscheint etwas anderes in den Suchergebnissen, das Sie nicht sehen möchten?

Auch der Schreib- und Programmierstil beeinflussen Ihre Marke!

Während Sie an dem Projekt arbeiten, werden Sie eine Menge schreiben: README, Anleitungen, Dokumentation, Antworten auf Anfragen, vielleicht sogar Newsletter an eine Mailingliste.

Egal ob offizielle Dokumentation oder informelle E-Mail: Ihr Schreibstil ist ein Markenzeichen Ihres Projektes. Bedenken Sie, wie er bei Ihrem Publikum ankommt, und ob dies dem Tonfall entspricht, den Sie herüberbringen möchten.

Freundliche, inklusive Sprache kann Ihr Projekt einladender für neue Mitwirkende machen. Bleiben Sie auch bei einfacher/leichter Sprache, denn nicht alle Ihrer Leser*innen haben die Fähigkeit, komplizierte Formulierungen sofort zu verstehen.

Neben Wortwahl und Schreibstil wird auch Ihr Programmierstil Teil der Marke Ihres Projekts. Angular und jQuery beispielsweise haben strenge Richtlinien dafür.

Eine Stilrichtlinie ist nicht sofort zum Start Ihres Projekts nötig, und vielleicht genießen Sie es auch, unterschiedliche Programmierstile in Ihr Projekt zu integrieren. Allerdings sollten Sie davon ausgehen, dass verschiedene Schreib- und Programmierstile verschiedene Leute anziehen oder abstoßen. Die Weichen für die Gemeinschaft, die Sie letztendlich aufbauen möchten, werden schon in frühen Projektphasen gestellt.

Ihre Checkliste zur Startvorbreitung

Bereit für den Start Ihres Open-Source-Projektes? Diese Checkliste hilft Ihnen dabei. Alle Stationen bereit? Dann los! Klicken Sie auf “publish” und klopfen Sie sich auf die Schulter.

Dokumentation

Code

Menschen

Wenn Sie als Einzelperson arbeiten:

Wenn Sie als Firma oder Organisation arbeiten:

Geschafft!

Herzlichen Glückwunsch zu Ihrem ersten Open-Source-Projekt! Egal was dabei rauskommt, öffentlich zu arbeiten, ist es ein Geschenk an die Gemeinschaft. Sie erschaffen mit jedem Commit, jedem Kommentar und jedem Pull Request eine Gelegenheit für sich selbst und andere, etwas zu lernen und intellektuell zu wachsen.