Gibt es einen Begriff für Quasi-Open-Source-Software?

Angenommen, ein Unternehmen möchte die Entwicklung neuer Funktionen einer internen Software fortsetzen, möchte jedoch den Quellcode für frühere Versionen bis hin zu vorhandenen öffentlichen Funktionen veröffentlichen, damit andere Personen von der Verwendung und Änderung der Software selbst profitieren können und möglicherweise sogar Änderungen beitragen, die auf den Entwicklungszweig angewendet werden können.

Gibt es einen Begriff für diese Art von Anordnung und wie lässt sich dies am besten mit vorhandenen Tools und Plattformen zur Versionskontrolle erreichen?

Ich kenne den Namen nicht, aber für die Implementierung könnte das folgende Setup funktionieren:

Erstellen Sie zwei Repos auf Github (ersetzen Sie sie durch eine andere Plattform, die dasselbe tut), eine öffentliche und eine private. Behalten Sie die neueste Version X privat und vX-1 öffentlich. Aktualisieren Sie bei der Veröffentlichung einer neuen Version die öffentliche von der privaten Version. Auf diese Weise können Sie die Versionskontrolle einfach verwenden und Benutzern von öffentlichem Repo ermöglichen, Ihnen ihre Beiträge über Pull-Anfragen zu senden. Anschließend können Sie sie mit Ihrem privaten Repo zusammenführen, Probleme einreichen usw. Dadurch erhalten Sie auch die Optionen, mit denen bezahlte Benutzer dasselbe für Ihren privaten Code tun können - geben Sie ihnen entweder Lese- oder sogar Lese- / Schreibzugriff.

Es klingt wie Shared Source , ein Begriff, der von Microsoft verwendet wird, um zu beschreiben, wie Kunden aus Gründen wie Sicherheitsüberprüfung oder Referenz eine Kopie ihres Quellcodes erhalten können. Microsoft behält die volle Kontrolle über die Codebasis für Neuentwicklungen.

Die mit den Angeboten verbundenen Lizenzen reichen von Closed-Source-Lizenzen, bei denen der Code nur als Referenz angezeigt wird, bis hin zu Änderungen und Weiterverteilungen für kommerzielle und nichtkommerzielle Zwecke.

Ich kenne keinen Begriff dafür.

Vielleicht sollte es das Vorhängeschloss-Scheunentor-Modell heißen. Anstatt "das Stalltor zu schließen, nachdem das Pferd verriegelt ist" (dh zu versuchen, die Exklusivität wiederzugewinnen, nachdem Software unter einer zu liberalen Lizenz veröffentlicht wurde), schließen Sie das Stalltor ab und hoffen, dass das Pferd im Stall nicht verhungert. :-)

Im Ernst, wenn die Unternehmensleitung der Meinung ist, dass dies notwendig ist, um mit Open Source Geld zu verdienen, kann man nicht wirklich streiten. Schließlich sind sie für die Verwaltung der von ihnen getätigten Ressourceninvestitionen verantwortlich.

Dies ist jedoch kein Modell, das für den zahlenden Kunden gut ist. (Wenn der Kunde keinen Quellcode für die von ihm ausgeführte Premium-Version erhalten kann, wozu dient er dann zur Zahlung der Prämie?) Es ist unwahrscheinlich, dass Beiträge der Benutzergemeinschaft gefördert werden, und er wird diese Beiträge von leisten weniger Wert ... weil sie immer gegen eine alte Version der Codebasis sein werden. In der Tat könnte man argumentieren, dass es wahrscheinlicher ist, das Gabeln zu fördern.

Dieses Muster ist in der Branche tatsächlich recht häufig. Ein Beispiel ist, wenn ein Produkt als Community Edition und Enterprise Edition verfügbar ist. In der Regel ist die Community Edition kostenlos erhältlich und kann sogar freie / Open-Source-Software sein. In der Regel fehlen einige Funktionen, die nur von Unternehmensbenutzern benötigt werden. Die Enterprise Edition ist normalerweise durch den Kauf einer kommerziellen Lizenz erhältlich und kann optional mit einem Support-Paket, integrierten Software-Updates, mehr Funktionen oder freizügigeren Nutzungsbedingungen gebündelt werden. Dieses Muster kann in vielen Formen und Variationen auf dem Markt gesehen werden. Ein Beispiel ist die Eclipse-Plattform im Vergleich zu den darauf basierenden kommerziellen Produkten wie dem IBM Lotus-Client. Ein weiteres Beispiel ist der Beginn des heutigen Mozilla Firefox, der als Netscape Browser gegen Mozilla Browser gestartet wurde.

Ein anderer Ansatz besteht darin, das Produkt in zwei separate eigenständige Produkte zu trennen. Dies ist für große Projekte geeignet, die aus vielen kleineren Teilprojekten bestehen. Ein Beispiel ist Fedora Linux gegen Red Hat Enterprise Linux oder OpenSuse gegen Suse Linux Enterprise.

Ich glaube, der Begriff ist Doppellizenzierung . (oder Mehrfachlizenzierung )

Der Teil des Projekts, den die Leute mit Ihnen herumspielen sollen, wird beispielsweise unter der LGPL veröffentlicht, mit der proprietäres Material aufgerufen werden kann. Der Port des Projekts, den Sie unter Ihrem Daumen behalten möchten, ist eine proprietäre Verkaufssoftware.

Wenn der gesamte Code Ihnen gehört, können Sie nach Belieben Relicence verwenden. Wenn jemand anderes zu dem Code beigetragen hat, den Sie schließen möchten, MÜSSEN Sie dessen Erlaubnis einholen oder ihn dazu bringen, das Urheberrecht an Sie zu übertragen. Was einen Namen betrifft, kenne ich keinen Standard, vielleicht eine doppelte Lizenzierung? Ich denke, MySQL ist in der gleichen Position, und vielleicht QT?