Desktop-API-Client Yaak wird Open Source

• Vor 3 Monaten wurde der Beitrag „Why Not Open Source“ veröffentlicht, in dem erklärt wurde, warum Yaak nicht Open Source werden sollte
• Da in der Vergangenheit Burnout mit einem Open-Source-Projekt erlebt wurde, wurde dies geteilt in der Annahme, dass der Entscheidungsprozess auch für andere hilfreich sein könnte
• Die meisten Yaak-Nutzer stimmten zu, doch in der breiteren Open-Source-Community gab es starken Widerspruch gegen den Großteil der Inhalte

Reaktionen aus der Open-Source-Community

• „Verwechsle Open Source/Freie Software nicht mit einem bestimmten sozialen Modell auf GitHub oder mit Beiträgen.“ - lobste.rs

• „Aber all das trifft ebenso auf Closed-Source-Software zu.“ - ycombinator.com

• „Die Behauptungen in diesem Beitrag sind kompletter Unsinn. Ich weiß nicht einmal, was diese ‚App‘ sein soll. Braucht niemand. Ab in den Mülleimer der Geschichte damit.“ - reddit.com

• Die meisten Antworten waren nicht konstruktiv, aber ein 500 Wörter langer Kommentar auf lobste.rs war wirklich hervorragend. Dadurch kam der Gedanke auf, dass ich vielleicht falschlag

Vorteile von Open Source

• Open Source bedeutet nicht zwangsläufig Open Contribution
• Schon allein durch die Offenlegung des Codes lassen sich die meisten Vorteile erzielen:
  • offen für Sicherheitsaudits
  • transparente Funktionen (nichts Verdächtiges)
  • Flexibilität (kann geforkt und angepasst werden)
  • bleibt lauffähig, auch wenn der Entwickler geht

Wechsel zu Open Source mit eingeschränkten Beiträgen

• Es gibt Projekte wie SQLite, die Open Source sind, aber keine externen Beiträge annehmen
• Litestream erlaubte anfangs keine Beiträge, änderte das später jedoch so, dass nur Bugfixes akzeptiert werden
• Auch Yaak übernimmt dieses Modell, wird unter der MIT-Lizenz Open Source und akzeptiert Beiträge nur für Bugfixes

[rmekdma]

Ich war beeindruckt, dass so viele Kommentare gelesen und die konstruktiven Punkte herausgefiltert und angenommen wurden. Das zeigt, dass die Person offen ist.

[savvykang]

Konstruktive Kommentare sind ebenfalls wirklich großartig.

[xguru]

Dies ist eine Zusammenfassung des 500-Zeichen-langen lobster.rs-Kommentars, der im Artikel enthalten ist.
Dieser Kommentar bezieht sich auf den Originalbeitrag Why Not Open Source ?.

• Kurz gesagt: Verwechselt „Open Source“ / „Freie Software“ nicht mit dem spezifischen sozialen Modell von GitHub, nämlich Drive-by-Contributions, oder mit Contributions an sich.
• Der Erklärung, warum Open Source nicht funktionieren soll, ist schwer zuzustimmen.
• Viele der vorgebrachten Punkte sind falsche Dichotomien. Zum Beispiel: „Das Hinzufügen von Funktionen ist in der Praxis schwierig, und oft ist es schneller, wenn die Maintainer sie selbst implementieren.“
• Bei Closed Source muss man es zwar immer selbst machen, aber auch bei Open Source kann man sich dafür entscheiden. Es gibt keine Pflicht, Beiträge anderer anzunehmen.

Gegenargumente zu den einzelnen Punkten

Funktionen können hinzugefügt werden - 🟥 In der Praxis schwierig

• Man muss nicht alles annehmen, was irgendjemand einreicht, nur um Open Source zu sein.

Mehr Transparenz - 🟧 Für Transparenz ist Open Source nicht notwendig. Das geht auch über eine öffentliche Roadmap statt nur über den Code.

• Guter Punkt. Aber es geht nicht darum, nur Code zu haben, sondern auch Code zu haben. Man kann transparenten Code und eine transparente Roadmap zugleich haben.

Die Sicherheit wird verbessert - 🟧 Kommt auf den Fall an. Nutzer können den Code eines Open-Source-Projekts prüfen und Probleme offenlegen.

• Selbst wenn man es Open Source macht, wird es dadurch nicht schlechter. Vielleicht verbessert es sich nicht, aber es hat zumindest keinen Nachteil.

Die Community wird wachsen - 🟧 Das klappt nur mit investierter Arbeit. Das ist nicht auf Open Source beschränkt.

• Auch hier wird es nicht schlechter, aber der Autor räumt ebenfalls ein, dass das nicht stark damit zusammenhängt.

Gegenargumente zu den Nachteilen

Mit unhöflichem Feedback umzugehen ist schwierig

• Feedback bekommt man auch bei Closed Source. In beiden Fällen muss man es nicht annehmen.

Lange Feedback-Zyklen sind schwer zu managen

• Dann nimmt man eben keine Feedback-/Änderungseinreichungen an. Damit verschwindet auch der Verbesserungszyklus.

Es ist schwer, unaufgefordert eingereichte Beiträge abzulehnen

• Man kann ins README schreiben, dass keine Beiträge angenommen werden, und alle PRs automatisch schließen.

Wenn das Projekt reift, wird es schwer, das meiste abzulehnen

• Auch bei Closed Source werden Nutzer weiterhin Anfragen stellen.

Wenn gute Mitwirkende gehen, wird es schwierig

• Dann nimmt man eben keine weiteren Mitwirkenden auf. Da gibt es keinen Unterschied zwischen Open und Closed Source.

Es ist schwer zu akzeptieren, dass Menschen unbezahlt arbeiten

• Freie Software bedeutet nicht kostenlos. Kommerzielle freie Software ist ebenfalls möglich, und man muss nicht akzeptieren, dass andere unbezahlt arbeiten.

Es ist nicht gut, mehr als 1000 ungelöste Issues zu haben

• Dann schließt man sie eben automatisch.

Dass es kein Ende gibt, ist schwierig

• Das gilt genauso, wenn man bei Closed Source Nutzer/Kunden hat.