Wie kann ich vermeiden, meinen eigenen Namen in den von mir erstellten Bezeichnern, Paketen oder Namespaces von Open Source-Projekten zu verwenden?

15

Ich entwickle viel in meiner Freizeit. Diese Projekte, an denen ich arbeite, sind alle (bisher) nur zum Spaß und zum Lernen gedacht. Ich mache normalerweise Java-Entwicklung mit Maven, aber ich war auch dafür bekannt, in .NET und Python zu experimentieren. Alle Projekte, an denen ich arbeite, verwenden Open-Source-Lizenzen, obwohl sich die meisten von ihnen in keinem öffentlichen Code-Repository befinden.

Bei der Java / Maven-Entwicklung muss ich eine eindeutige groupId(z. B. "com.mydomain") und eine eindeutige package(Verzeichnis-) Struktur verwenden, die normalerweise die groupId.NET-Entwicklung "unique" enthält, namespacesin der ich ähnliche Konventionen wie das Java- packageKonzept verwende. Um die Eindeutigkeit zu gewährleisten, verwende ich normalerweise nur einen meiner Domainnamen mit umgekehrten Teilen (z. B. "ca.jessewebb"). Ich glaube, das ist eine sehr verbreitete Praxis.

Ich bin in der Anfangsphase der Erstellung eines neuen Open Source Java / Maven-Projekts (nennen wir es "newproj") und möchte es auf GitHub veröffentlichen. Mein Benutzername auf GitHub ist „jessewebb“ , so das es eine URL geben wie: https://github.com/jessewebb/newproj. Ich möchte nicht die Mühe machen, den Domainnamen "newproj.com" zu registrieren, daher habe ich mich entschieden, "ca.jessewebb" und "ca.jessewebb.newproj" als groupIdund zu packageverwenden.

Mir ist der Gedanke gekommen, dass das Vorhandensein meiner persönlichen Identität im Code und als Teil der Projekt-Homepage (in der GitHub-URL) einen potenziellen Mitwirkenden dazu veranlassen wird, zweimal über eine Beteiligung an meinem Projekt nachzudenken. Das ist ein Problem, ich möchte nicht, dass es mein Projekt ist. Ich würde es vorziehen, wenn ich stattdessen die Nachricht übermitteln könnte, dass mir das Projekt nicht gehört. Um ehrlich zu sein, ist es keine so große Sache, denn ich bezweifle, dass meine Projekte viel Engagement in der Gemeinde mit sich bringen werden, aber ich sehe dies auch eher als Grund, um die Möglichkeit zu vermeiden, potenzielle Mitwirkende abzuschrecken.

Als weiteres Beispiel habe ich vor einigen Jahren ein Google Code-Projekt erstellt (nennen wir es "oldproj"). Als ich das Projekt erstellte, wusste ich, dass ich es auf Google Code groupIdhosten würde. Daher habe ich den Paketnamen "com.googlecode.oldproj" verwendet. Dies ist die Umkehrung des Standard-Domainnamens, den Google Code für jedes neue Projekt bereitstellt. Es stellte sich heraus, dass dies keine so gute Idee war. ein Jahr später, ich den Code in einem anderen Repo bewegt und ich hatte diese Bezeichner umbenennen (gut habe ich nicht habenzu aber ...). Zu der Zeit besaß ich keine Domainnamen und kaufte schließlich den Domainnamen "oldproj.com" und benutzte ihn. Das gefiel mir, weil es dem Projekt eine eigene Identität verlieh und ich nicht überall meinen Namen in den Code eingeprägt habe. Ich hätte genauso gut den Domainnamen "jessewebb.ca" registrieren und "ca.jessewebb.oldproj" als Paketnamen verwenden können, aber ich tat es nicht, weil ich damals die gleichen Bedenken hatte.

Also meine Frage ist ...

Wie kann ich vermeiden, meine eigenen (Domain-) Namen beim Erstellen von Open Source-Projekten zu verwenden, ohne die Eindeutigkeit von Paketen / Namespaces zu beeinträchtigen?

Da Projekte an Dynamik gewinnen, ist es sinnvoll, die Domain-Namen zu registrieren, aber es scheint albern und eine Verschwendung von Geld, dies früher zu tun. Ich weiß , dass ich nicht wirklich haben , besitzen den Domain - Namen , um es im Code zu verwenden , aber das fühlt sich falsch und kann zu einem Squatter führen es unter Ihnen in der Zwischenzeit schnappend. Was tun andere Menschen gegen dieses Dilemma? Gibt es Beispiele für populäre (weit verbreitete, große Community usw.) Open Source-Projekte, die die Identität des ursprünglichen Entwicklers als Teil ihrer eigenen Kennung (en) enthalten?

Jesse Webb
quelle
2
Whoa, ziemlich lang, aber immer noch eine gute Frage!
Marcel
1
Verwenden Sie eine UUID in Ihren Paketen / Namespaces? ;-)
Jeroen

Antworten:

5

In meinen Projekten gebe ich ihnen einen Namen, aber nicht unbedingt eine Domain. Daher sind meine Paketnamen (und Namespaces) normalerweise nur "projectname.libraryname", unabhängig davon, wo der Code gehostet wird.

Ich bin an .NET gewöhnt, wo dies ziemlich frei gehandhabt wird.

Marcel
quelle
Ich halte dies für eine gute Lösung, wenn ich keine Domain für das Projekt registriert habe oder (sofort) möchte. Ich könnte dies sogar tun, wenn ich eine Domain habe. Es würde sogar helfen sicherzustellen, dass ich eindeutige Projektnamen verwende, was niemals eine schlechte Sache ist. Ich werde diese Antwort wahrscheinlich bald annehmen, es sei denn, es kommen bessere dazu. Vielen Dank!
Jesse Webb
Ja, .NET-Programmierer tun dies, aber es ist keine gute Idee. Wenn der Projektname ein erfundenes Wort ist, kann es gut funktionieren, aber ich wünschte, ich hätte einen Dollar für jedes "Downloader" - oder "Browser" -Projekt, das ich gesehen habe.
Ross Patterson
1
Ich habe begonnen, diese Strategie für alle meine Projekte zu verwenden. Ich habe mir einen eindeutigen Namen für die Projekte ausgedacht, fast einen Codenamen (entschuldigen Sie das Wortspiel), und benutze ihn für meine Pakete / Namespaces. Ich muss mir keine Sorgen um Domänennamen machen, zumindest nicht bis zu dem Zeitpunkt, an dem ich einen möchte.
Jesse Webb
2

Ich kann mich nicht erinnern, wo ich es gesehen habe, aber ich habe es vorgeschlagen, eine Struktur wie diese zu verwenden:

YourIdentifier.YourProduct.YourComponent

YourIdentifier kann so etwas wie eine Domain sein, die Sie besitzen, Ihr (ziemlich eindeutiger) Internet-Alias ​​usw. usw. Der Komponentenname wird für den "Kern" -Code Ihres Produkts weggelassen. Zum Beispiel habe ich ein kleines MVC-Framework namens BarelyMVC, also habe ich folgende Namespaces darin:

Earlz.BarelyMVC
Earlz.BarelyMVC.Authentication
Earlz.BarelyMVC.Caching

etc etc. Ihr Online-Alias ​​ist in den meisten Fällen eindeutig genug, um Konflikte zwischen anderen Entwicklern zu vermeiden

Wenn Sie Angst haben, einen eigenen Online-Alias ​​zu verwenden, erstellen Sie ein "Label" für sich. Es muss nicht offiziell als Unternehmen oder irgendetwas (oder sogar als Domain) registriert sein. Beispielsweise verwendet die beliebte Json.NetBibliothek den Namespace Newtonsoft.Json. Es basiert offensichtlich auf dem Nachnamen "Newton" des Autors, aber ich glaube, das interessiert niemanden wirklich. Und wenn Sie eine formelle Firma registriert haben, können Sie diese natürlich nutzen. Die meisten von meinem Unternehmen erstellten öffentlichen APIs haben beispielsweise Namespaces PreEmptiveSolutions, die mit dem Namen des Unternehmens beginnen

Earlz
quelle
1
Sehr verbreitet in der .NET-Welt, in der sich die Abwärts-Domain-Name-Sache nie wirklich durchsetzte. Und solange "YourIdentifier" wirklich einzigartig ist, funktioniert es. Aber auch Newtonsoft ist nur aus Versehen einzigartig - James Newton-King leitet eine solche Firma nicht, und das Markenzeichen würde nur in Neuseeland existieren, wenn er es tun würde.
Ross Patterson
1

Es gibt keine Regel, dass Java-Paketnamen oder .NET-Namespaces Domänennamen sind. Es gibt nicht einmal die Anforderung, dass sie einzigartig sind, obwohl das sicherlich eine gute Idee ist. Ich glaube tatsächlich, dass Sie Recht hatten com.googlecode.oldproj, und in Ihren Schuhen hätte ich nicht gewechselt, com.oldprojwenn ich nicht versucht hätte, Werbung für den neuen Domainnamen zu machen.

Ross Patterson
quelle
Mir ist klar, dass es keine Regel gibt, dass Sie Domain-Namen verwenden müssen, aber ich denke, dass dies eine sehr verbreitete Praxis ist, zumindest in der Java- und .NET-Welt, nur weil es dabei hilft, die Eindeutigkeit sicherzustellen. Außerdem hast du gesagt, dass du denkst, ich hätte Recht com.googlecode.oldproj, warum denkst du, war das eine gute Idee? Im Nachhinein fand ich es irgendwie albern, den Code an den Hosting-Provider zu binden.
Jesse Webb
1
Es geht nicht darum, dass Sie an einen Hosting-Anbieter gebunden sind, sondern darum, dass es sich um eine konventionell eindeutige Kennung handelt, die für dieses Projekt spezifisch ist. Welches ist alles "com.jesseweb.oldproj" ist, technisch. Da Sie also nicht wollten, dass Ihr Name daran angehängt wird, war es eine gute Entscheidung. Java-Pakete und .NET-Namespaces sollten keine Wegweiser sein, die Sie zu einer Download-Site usw. leiten, sondern lediglich eine Kennung, die gemäß Konvention eindeutig ist.
Ross Patterson