Open Source Software zu früh veröffentlichen [geschlossen]

37

Was ist die moralische Verantwortung, wenn Open Source-Software zu früh veröffentlicht wird? Zum Beispiel ein nahezu vollständiges Produkt, das noch nicht vollständig getestet wurde.

Was ist die Erwartung des Programmierers? Warten Sie, bis es vollständig getestet wurde, oder veröffentlichen Sie es als Open Source-Version, und fahren Sie dann mit der Weiterentwicklung, dem Testen und den Weiterentwicklungen fort?

Die Befürchtung ist, dass Software Open Source ist und potenziell zu Problemen für die Verbraucher führen könnte.

Ist das eine unbegründete Angst?

Thomas Stringer
quelle
10
Fügen Sie einen Haftungsausschluss hinzu, wenn Sie besorgt sind. :)
Vaughan Hilts
18
Ein Nachteil einer zu frühen Veröffentlichung wäre, dass der Werbeschub, den Sie bei der Veröffentlichung erhalten, möglicherweise verloren geht, wenn die Software unbrauchbar wird. Dann, nachfolgende Veröffentlichungen "ja, ich habe das versucht, es hat gesaugt". Es hängt natürlich davon ab, wie viel mehr Sie benötigen, um sich in Form zu bringen, und von der Zielgruppe.
Davidmh
@VaughanHilts Ich mache mir keine Sorgen, dass jemand wütend wird. Die Sorge liegt ausschließlich im Wunsch nach einer Verbesserung der Softwareverteilung und des Softwareverbrauchs. Letzteres möchte ich nicht leiden, weil ich zu sehr auf eine Veröffentlichung gespannt bin.
Thomas Stringer
@ Davidmh: Das wäre auch mein Hauptanliegen, "einmal verbrannt, zweimal schüchtern".
Matthieu M.
8
Die Freigabe des Quellcodes, jedoch nicht der Binärdateien, ist möglicherweise eine gute Möglichkeit, um zu verhindern, dass Personen mit falschen Erwartungen Ihre Software verwenden, bevor sie fertig ist.
Setzen Sie Monica am

Antworten:

56

Ich glaube im Gegenteil, dass Sie so schnell wie möglich eine Open-Source-Software veröffentlichen sollten. Es gibt kein "zu früh" dafür (aber es sollte kompilieren).

Oder veröffentlichen Sie den Quellcode zumindest sehr früh und kontinuierlich (z. B. durch häufiges Drücken von github ), ohne formelle Veröffentlichungen vorzunehmen .

Es ist jedoch sehr wichtig, es als Alpha- oder Betastufe zu kennzeichnen und wenn möglich zu sagen (z. B. in einer Datei READMEoder in einem TODOBlog usw.), was fehlt, nicht getestet oder in schlechtem Zustand ist. Sie sollten auch die Versionsnummer verwenden , um solche Informationen zu übermitteln.

Bei freier Software sollte das Beste sein, dass jemand einen Blick in den Quellcode wirft und Ihnen einen kleinen Patch zur Verbesserung vorschlägt. Deshalb machen Sie Ihre Software kostenlos!

Daher müssen Sie Ihre tägliche Arbeit an Ihrer freien Software sichtbar machen! Externe Mitwirkende wären sauer, wenn ihr Patch nicht mit Ihrem aktuellen Software-Quellcode funktioniert oder ein Duplikat davon ist.

Was Sie befürchten sollten, ist, dass sich niemand für Ihre Software interessiert (und dazu beiträgt). Es ist ein langer Weg, Interesse von außen für eine freie Software zu wecken (insbesondere externe Mitarbeiter zu gewinnen).

Basile Starynkevitch
quelle
33

TL; DR:

Vorzeitig freigeben. Oft loslassen.

Persönliche Anekdote:

Ich war sehr aufgeregt über das Projekt, an dem ich arbeitete. Sehr aufgeregt. Ich konnte nachts nicht aufgeregt schlafen. Also habe ich meinen Co-Entwickler dazu gebracht, v1.0 schneller zu veröffentlichen, als er wollte.

Es war schrecklich. Nichts funktionierte so, wie es sein sollte. Es gab Bugs in jeder Runde, aber wir haben sie protokolliert und behoben. Wir haben sogar ein paar Early Adopters dazu gebracht, Fehler einzureichen, die wir möglicherweise nicht gefunden haben. Ein oder zwei Wochen später veröffentlichten wir eine neue Version, die viele der Probleme behebt, und fingen dann wieder an, neue Funktionen zu entwickeln.

Eine frühe Veröffentlichung war das Beste, was wir tun konnten. Es stellte unser Produkt vor reale Benutzer. Durch diese aufgedeckten Fehler haben wir möglicherweise unser Projekt gefunden und verbessert. Außerdem haben diese Early Adopters erfahren, dass wir dieses Projekt ernst nehmen. Es wird mehr Releases und eine aktive Entwicklung geben.

Es hätte aber auch leicht in die andere Richtung gehen können. Wir hätten diese Fehlerberichte ignorieren können. Oder wir hätten nicht schnell reagieren können. Es könnte eine andere Geschichte gewesen sein, wenn wir 3 Monate statt ein paar Wochen gebraucht hätten, um v1.1 zu veröffentlichen.

Badeente
quelle
9
Es hört sich so an, als ob Ihr einziger großer Fehler darin bestand, es "v1.0" zu nennen. Im Allgemeinen erwarten Benutzer, dass ein "fertiges" Produkt in dem Sinne angezeigt wird, dass es für den angegebenen Zweck verwendbar ist, frei von offensichtlichen Fehlern usw. "Frühes Freigeben" ist gut, Benutzer sollten jedoch darüber informiert werden, dass es sich um Meerschweinchen handelt.
R ..
3
Ja. Ich würde dem im Nachhinein zustimmen. Um fair zu sein, dachte ich, ich hätte es gründlich getestet. Ich dachte, es war 1.0 zu der Zeit @R ... Ich habe mich geirrt.
RubberDuck
12

Es ist dasselbe wie bei Closed-Source-Software. Kommunikation ist wichtig.

Informieren Sie die Benutzer über den Status der Software und warum sie zum Herunterladen verfügbar ist.

Software führt immer zu Kundenproblemen, unabhängig davon, ob sie vollständig getestet wurde oder nicht. Die meisten Kunden akzeptieren diese Tatsache, und einige Kunden tun dies niemals. Wenn die Software jedoch zu mehr Problemen führt, als vernünftigerweise zu erwarten wäre, besteht eine moralische Verpflichtung, den Kunden über das von ihm eingegangene Risiko zu informieren. Informationen sollten sowohl in Kurzform ("Alpha / Beta / EarlyAccess" -Labels) * als auch im Detail vorliegen: Eine Liste bekannter Probleme, Problemumgehungen und besonderer Überlegungen, z. B. wenn es wahrscheinlich ist, dass Daten beschädigt werden.

* Beachten Sie, dass Benutzer von einigen großen Softwarefirmen geschult wurden, "Beta" als einen Zustand zu betrachten, in dem die Software ziemlich solide ist. Dem Benutzer mitzuteilen, dass es sich bei der Software um "Beta" handelt, ist häufig nicht ausreichend.

Peter
quelle
3
Sollten wir daraus schließen, dass "Beta" nicht ziemlich solide sein sollte? Ich vermute, "große Softwareunternehmen" nennen es "Beta", wenn es darum geht, produktionsbereit zu sein, um die Software mit realen Daten zu konfrontieren. Nennen wir es vielleicht einen Prototyp ?
Pierre Arlaud
2
Das "Beta" -Label bedeutet nun verschiedene Dinge für verschiedene Leute, daher können wir meiner Meinung nach nicht viel aus dem "Beta" -Label schließen, außer dass die Software irgendwo zwischen "etwas brauchbar" und "fast fertig" liegt. Einige Kunden werden auf etwas schließen, und nicht alle werden auf dasselbe schließen. Deshalb habe ich die Bemerkung gemacht.
Peter
3
Ich neige dazu, den Begriff "Alpha-Build" jetzt für Prototyp-Builds zu verwenden. Es gibt den Leuten das Gefühl, dass "dieses Ding noch nicht einmal Beta ist! Erwarten Sie nicht, dass es fast fertig ist."
RubberDuck
2
Sie können es in einer anderen Form, beispielsweise nur in Quellform, ohne Binärpakete verteilen.
el.pescado
3
@SteveJessop, bevor die Spieleindustrie unsere Meinung zu "Beta" geändert hat, hätte ich Ihnen zugestimmt. =)
RubberDuck
7

Es gibt keinerlei moralische Verantwortung. Niemand wird gezwungen, Ihre halbherzige Software zu verwenden.

Das einzige, worüber Sie sich Sorgen machen müssen, ist Ihre Glaubwürdigkeit.

Whatsisname
quelle
2
Ohne eine Erklärung kann diese Antwort für den Fall unbrauchbar werden, dass jemand anders eine gegenteilige Meinung äußert. Zum Beispiel, wenn jemand eine Behauptung wie "Es gibt eine moralische Verantwortung. Jemand könnte versucht sein, Ihre halbherzige Software zu verwenden. Ihre Glaubwürdigkeit wäre nicht das Einzige, worüber man sich Sorgen machen müsste." , wie würde diese Antwort dem Leser helfen, zwei gegensätzliche Meinungen zu treffen? Überlegen Sie , ob Sie es in eine bessere Form bringen möchten, um den Richtlinien zur Beantwortung zu entsprechen.
gnat
6
@gnat: Es ist falsch, dass diese Antwort ohne Erklärung ist - die Erklärung ist der nächste Satz: "Niemand wird gezwungen, Ihre halbgebackene Software zu verwenden". Es ist eine kurze Erklärung, ja, aber es ist immer noch DER GRUND zu sagen, dass es keine moralische Verantwortung gibt
slebetman
@gnat: das gleiche kann über die meisten antworten sagen. "Ich glaube nicht, dass Sie [...] freigeben sollten. Es ist nicht sehr wichtig, es [...] zu kennzeichnen." Erwarten Sie mehr externe Quellen für diese Antwort?
Pierre Arlaud
2
Es gibt gute und schlechte Meinungen. Ich stimme Ihnen zu, aber es wäre schön zu sehen, dass Sie dies mit einem stärkeren Argument untermauern.
RubberDuck
6

Ich habe die Erfahrung gemacht, dass ein Gleichgewicht erreicht werden muss.

Im Moment arbeite ich (im Sinne der Beantwortung von Fragen und der Bereitstellung von Entwicklungsvorschlägen, ohne Code zu sehen) mit einem Entwickler, der ein sehr aufregendes FOSS-Projekt erstellt, das den von mir geschriebenen Code verwendet. Die Veröffentlichung wurde wiederholt verzögert, da Konstruktionsänderungen vorgenommen wurden, die das Projekt auf lange Sicht verbessern werden, jedoch erhebliche Änderungen des Codes erforderlich machen, der bereits geschrieben wurde und bereits "funktionierte". Wäre eine funktionierende, aber unvollständige Veröffentlichung gemacht worden, sobald es etwas zu zeigen gab, könnten Ideen für Änderungen (und aktuelle Patches) von der breiteren Community, die an diesem Projekt interessiert ist, kommen und es eher beschleunigen als haben die Probleme tauchen nacheinander langsam auf, Wie der Entwickler darüber nachdenkt und um Feedback zum Design von mir und anderen interessierten Mitgliedern der Community bittet. Von diesem Standpunkt aus bin ich also ein großer Befürworter von "Früh freigeben, oft freigeben".

Auf der anderen Seite können Releases mit geringer Qualität dazu führen, dass ein neues Projekt schlecht aussieht, bevor es überhaupt in Betrieb genommen wird. Einige Fallstricke, die ich gesehen habe, sind:

  • Gerüstbäume mit Schnittstellendefinitionen, aber ohne Code.
  • Code, der nur für den Entwickler erfolgreich kompiliert werden kann.
  • Keine Anweisungen zum Erstellen / Ausführen des Programms.
  • Keine Dokumentation darüber, welche Aspekte voraussichtlich funktionieren.
  • Unklare Beschreibung dessen, was das Programm überhaupt tut oder tun wird.
  • Fehlender Nachweis der Nützlichkeit.

Zum Schluss denke ich an Dinge wie:

  • Compiler / Interpreter, der nicht einmal ein Hallo-Welt-Programm kompilieren / ausführen kann.
  • Emulator, der zumindest kein Beispielprogramm ausführen oder auf andere Weise demonstrieren kann, dass er etwas tut.
  • Bildverarbeitungs-Tool, das nur das Laden und Speichern des unveränderten Bildes ermöglicht.
  • Spiel mit nichts als einem Titelbildschirm.

Diese Art von Problemen führt zu einem "Vaporware" -Image, das schwer zu verwackeln ist, es sei denn, Sie sind sehr offen für den Mangel an Arbeitscode.

Schließlich machen Ihre Versionsnummern Sinn. Nennen Sie Ihr Projekt nicht "1.0", bis es das tut, was die Benutzer ohne Absturz erwarten. Ich hatte schon immer Glück damit, Versionsnummern um "0.5" für die erste Veröffentlichung zu verwenden, aber ich habe auch Dinge wie "0.1" oder "0.10" gesehen, die Sinn machen.

R ..
quelle
1

Es gibt einen Fall, in dem die Veröffentlichung freier Software negative Folgen haben kann. Einige Spezifikationen sind für die Öffentlichkeit unter der Bedingung lizenziert, dass alle an die Öffentlichkeit verteilten Implementierungen bei der ersten Veröffentlichung vollständig der Spezifikation entsprechen. Der Verlag untersagt Ihnen rechtlich, eine in Arbeit befindliche Implementierung der Spezifikation zu verbreiten. Ohne eine spezielle ausgehandelte Lizenz des Herausgebers der Spezifikation müssen Sie diese mit niemandem teilen, bis alle Tests bestanden sind. Dies zwingt ein "Kathedralenmodell" (wie Eric S. Raymond es nannte) zur Implementierung der Spezifikation.

Eine Spezifikation unter einer solchen Lizenz ist die Java-Sprachspezifikation . Diese Einschränkung gilt für Entwickler von virtuellen Maschinen, die mit der JVM kompatibel sind, aber zum Glück nicht für Entwickler von Anwendungen, die in einer JVM ausgeführt werden.

Der Artikel " 4 Shifty Details About Microsofts 'Open Source' .NET " von Liu Qihao & Ciaran O'Riordan erwähnt die Möglichkeit, das Microsoft-Patentversprechen für .NET-Bibliotheken und Laufzeitkomponenten so zu interpretieren , dass unvollständige Implementierungen der CLR auf ähnliche Weise ausgeschlossen werden . Dies gilt jedoch nicht für Anwendungen, die in der CLR ausgeführt werden.

Damian Yerrick
quelle
2
Dies ist nur von Bedeutung, wenn Sie eine JRE / JDK-Implementierung erstellen möchten, keine Java-Programme, die darauf ausgeführt werden, AFAIK.
Sjas
@sjas Wollen Sie damit andeuten, dass JLS die einzige Spezifikation ist, auf die man wahrscheinlich stößt, die die Einschränkung "vollständig oder für sich behalten" aufweist?
Damian Yerrick
Sie versuchen zu implizieren, dass ich das impliziere. ;)
sjas
@sjas Danke. Gibt es eine andere Möglichkeit, diese Antwort nützlich zu machen?
Damian Yerrick
Ich habe übrigens nicht abgelehnt. Ich habe bereits das Missverständnis ausgeräumt, das ich hatte, als ich Ihre Antwort zum ersten Mal las. Sie können es in Ihren Beitrag aufnehmen, wenn Sie etwas ändern möchten.
Sjas