GitHub

Vielleicht offensichtlich (obwohl vielleicht nicht so offensichtlich in der Ära von Wikipedia und der Bearbeitung der eigenen StackExchange-Fragen und -Antworten durch andere, ohne zu fragen) ... das GitHub-Repository von jemandem im Web ist nicht etwas, das Sie direkt ändern. Stattdessen "gabeln" Sie es, um Ihren eigenen Klon zu erstellen, den nur Sie (und von Ihnen bestimmte Mitarbeiter) ändern können.

Wenn das Projekt also ist github.com/JohnDoe/coolproject, würden Sie GitHub mitteilen, dass Sie github.com/Noah/coolproject. Dadurch wird ein „Git-Klon“ aller Dateien und der Projekthistorie erstellt und der Bezug zum Original bleibt erhalten.

Das Arbeitsmodell besteht darin, dass Sie dann auf Ihrem lokalen Computer einen weiteren Klon von github.com/Noah/coolproject. Auf diese Weise können Sie Dateien im Projekt direkt ändern (selbst wenn Sie ein Repository besitzen, gibt Ihnen GitHub kein Shell-Konto und kein Kennwort, um sich bei ihren Computern anzumelden und Ihre Dateien zu bearbeiten) . Nachdem Sie die Änderungen vorgenommen haben, um das Logo hinzuzufügen und alle Dateien zu aktualisieren, die es verwenden, würden Sie die zugehörigen Änderungen in einem einzigen "Commit" zusammenfassen, das die Unterschiede darstellt.

Sobald Sie Ihr lokales Commit erhalten haben, würden Sie dieses Commit an Ihren auf GitHub gehosteten Klon des Projekts unter „pushen“ github.com/Noah/coolproject. Da Sie diesen Fork erstellt haben, verfügen Sie über die erforderlichen Berechtigungen dazu. Dann senden Sie eine sogenannte "Pull-Anforderung" an github.com/JohnDoe/coolproject. Sie erhalten eine Benachrichtigung, dass ein Commit verfügbar ist, und können es integrieren ... Feedback oder Verbesserungen anfordern ... oder es einfach ablehnen.

Sie sollten sich nicht zu viele Gedanken über die Etikette machen müssen, wenn Sie gute Absichten haben. Sie können höchstens jemanden ärgern, wenn Sie ihm eine Anfrage senden, die schlecht formuliert ist oder irgendwie nicht den Konventionen des Projekts entspricht. Ihre Kopie des Codes wird nicht ohne ihre ausdrückliche Zustimmung geändert.

Wenn Sie jedoch nur ein Bild und keinen Code-Patch einreichen, ist es einfacher, die Datei als Anhang zu einem GitHub-Problem einzureichen . Dies ist ein Ticket-Tracking-System, das in GitHub integriert ist, und die meisten (aber nicht alle) Projekte haben es aktiviert. Sie finden es zum Beispiel unter github.com/JohnDoe/coolproject/issues. Der Entwickler kann sich darum kümmern, es an den richtigen Stellen zu platzieren, wenn er es akzeptiert, also dreht sich die eigentliche Frage eher um die Diskussion, ob er es verwenden möchte ... und welche Änderungen er möglicherweise benötigt.

Lizenzierung

Standardpraxis beim Spenden von Logodesigns an Open Source ist es, das Logo so zu kennzeichnen, dass es unter den bestehenden Copyright-Bedingungen der Marke/des Namens beibehalten wird. Wer den Namen kontrolliert, kontrolliert somit die Marke; Dies verhindert eine Abweichung, bei der die Projektadministratoren jemandem die Erlaubnis geben, den Namen zu verwenden, aber dann kommt der Logodesigner von vor Jahren zurück und sagt: "Aber ich mag sie nicht, Sie können mein Logo nicht verwenden!"

Gerade bei großen Projekten bleibt der Name und die Website die zentrale Open-Source-Organisation. Sie können den gesamten Code zu Firefox bringen und eine Codezeile ändern, um NoahBrowser zu erstellen, aber Sie können es nicht Firefox nennen (und wahrscheinlich nicht einmal NoahFirefox). Ein Designer, der mit Open Source arbeitet, sollte bereit sein, das Design in gutem Glauben an die Organisation zu übergeben, die das Projekt leitet ... und wenn Sie dieses Vertrauen nicht haben, sollten Sie wahrscheinlich zunächst keine kostenlose Arbeit für sie leisten Platz.

Es mag einige Leute geben, die die Idee vorantreiben, dass das Logo eines Open-Source-Projekts über Creative Commons lizenziert wird. Beachten Sie jedoch , dass nicht einmal Creative Commons selbst dies tun , und Sie würden denken, wenn jemand es tun würde, wären sie es ... also gibt es wahrscheinlich einen guten Grund, diesen besonderen Identitätsaspekt eines Projekts unter der Kontrolle des traditionellen "Alle Rechte vorbehalten" zu halten ".

Anerkennung

Es ist nichts Falsches daran, sie zu fragen, ob es ihnen nichts ausmacht, es im offiziellen Blog des Entwicklers zu erwähnen, wenn sie sich dafür entscheiden, es zu verwenden. Oder Sie können in Ihrem eigenen Blog darüber schreiben, für diejenigen, die neugierig sind, woher das Logo stammt.

Open Source ist oft irgendwie anonym, und das meiste „Wer hat was gemacht“ wird in den Versionsverlaufsprotokollen des Quellcodes erfasst. Den Namen des Entwicklers sieht man in vielen Softwares nicht, normalerweise bleibt das irgendwo für ein Easter Egg übrig. Die Grafik ist ein ähnlicher Deal.

(Wenn Sie eine Liste aller Entwickler sehen müssten, die zu Linux beigetragen haben, bevor es hochgefahren wird, würden Sie sehr lange zusehen, wie das vorbeiscrollt ... und die Namensliste würde zu einer sehr großen Datei in jede Verteilung.)

Wenn Sie Assets und Symbole einreichen ... Bilder für eine Schaltfläche oder etwas, das vernünftigererweise "Teil des Codes" als "Teil der Projektidentität" ist ... dann werden diese Beiträge normalerweise unter derselben Lizenz wie der Code erstellt selbst. Wenn eine Zuordnung erforderlich ist, erfolgt diese im Allgemeinen zum Projekt; nicht an die Mitwirkenden.

Für eine persönliche Zuordnung von Grafikinhalten, die im Programm selbst verwendet werden sollen, sollten Sie sie wahrscheinlich als Ihr eigenes Projekt erstellen und Ihre eigene Lizenz auswählen, wenn Sie dies durchsetzen möchten. Dann könnten Sie vorschlagen, dass das Projekt das Werk unter dieser Lizenz verwenden darf. Daran ist nichts auszusetzen; Dinge wie Silk Icons funktionieren auf diese Weise. Meiner Meinung nach übt es einen gewissen Druck auf Sie aus, die Arbeit als verallgemeinert zu definieren und als etwas, das von mehreren Projekten verwendet werden könnte.

Meine Erfahrung damit

Ich habe zwei OSS-Logo-Design-Interventionen durchgeführt und hier ein wenig darüber geschrieben