Как я могу избежать использования моего собственного имени в идентификаторах, пакетах или пространствах имен проектов с открытым исходным кодом, которые я создаю?

Я много занимаюсь разработкой в ​​свое время. Эти проекты, над которыми я работаю, предназначены только для развлечения и обучения (пока). Я обычно занимаюсь разработкой Java с Maven, но я также знаю, что увлекаюсь .NET и Python. Все проекты, над которыми я работаю, используют лицензии с открытым исходным кодом, хотя большинство из них не включены ни в какие общедоступные репозитории кода.

Разработка Java / Maven требует, чтобы я использовал уникальную groupId(например, «com.mydomain») и уникальную package(каталог) структуру, обычно содержащую в groupIdто время, как разработка .NET поощряет уникальность, namespacesв которой я использую соглашения, аналогичные packageконцепции Java . Чтобы гарантировать уникальность, я обычно просто использую одно из своих доменных имен с переставленными частями (например, «ca.jessewebb»); Я считаю, что это очень распространенная практика.

Я нахожусь на начальных этапах создания нового проекта Java / Maven с открытым исходным кодом (назовем его «newproj»), и я хотел бы разместить его на GitHub. Мое имя пользователя на GitHub является «jessewebb» , так что это даст ему URL , как: https://github.com/jessewebb/newproj. Я не хочу беспокоиться о регистрации доменного имени "newproj.com", поэтому я решил использовать "ca.jessewebb" и "ca.jessewebb.newproj" в качестве groupIdи package, соответственно.

Мне пришло в голову, что присутствие моей личной личности в коде и как части дома проекта (в URL GitHub), вероятно, заставит потенциального участника дважды подумать о том, чтобы принять участие в моем проекте. Это проблема, я не хочу, чтобы это был мой проект. Я бы предпочел, если бы я мог вместо этого передать сообщение, что я не являюсь владельцем проекта. Теперь, честно говоря, это действительно не так уж важно, потому что я сомневаюсь, что мои проекты привлекут большое участие сообщества, но я также считаю это еще большей причиной, чтобы избежать какой-либо возможности удержать потенциальных участников.

В качестве другого примера я создал проект Google Code несколько лет назад (назовем его «oldproj»). Когда я создавал проект, я знал, что собираюсь разместить его в Google Code, поэтому я использовал groupIdимя пакета и com.googlecode.oldproj, которое противоположно имени домена по умолчанию, которое Google Code предоставляет каждому новому проекту. Это оказалось не очень хорошей идеей; Примерно через год я переместил код в другое хранилище и мне пришлось переименовать эти идентификаторы (ну, у меня не былоно ...). В то время у меня не было никаких доменных имен, и в итоге я купил доменное имя «oldproj.com» и использовал его. Мне понравилось это, потому что это дало проекту собственную идентичность, и я не везде отмечал свое имя в коде. Я мог бы так же легко зарегистрировать доменное имя «jessewebb.ca» и использовать «ca.jessewebb.oldproj» в качестве имени пакета, но я этого не сделал, потому что тогда у меня были те же проблемы.

Итак, мой вопрос ...

Как я могу избежать использования моих собственных (доменных) имен при создании проектов с открытым исходным кодом при сохранении уникальности пакетов / пространств имен?

По мере того, как проекты набирают обороты, имеет смысл регистрировать доменные имена, но это кажется глупостью и пустой тратой денег, чтобы сделать это раньше. Я понимаю, что на самом деле мне не нужно владеть доменным именем, чтобы использовать его в коде, но это неправильно и может привести к тому, что скваттер вырвет его из-под вас. Что другие люди делают с этой дилеммой? Существуют ли примеры популярных (широко используемых, крупных сообществ и т. Д.) Проектов с открытым исходным кодом, которые содержат идентификационные данные оригинального разработчика как часть его собственных идентификаторов?

В своих проектах я даю им имя, но не обязательно домен. Таким образом, мои имена пакетов (и пространства имен) обычно просто "имя_проекта.libraryname", независимо от того, где размещен код.

Я привык к .NET, где это происходит достаточно свободно.

Я не могу вспомнить, где я видел это, но я видел, что он предложил использовать такую ​​структуру:

YourIdentifier.YourProduct.YourComponent

YourIdentifier может быть чем-то вроде принадлежащего вам домена, вашего (довольно уникального) интернет-псевдонима и т. Д. И т. Д. Имя компонента не используется для «основного» кода вашего продукта. Например, у меня есть небольшая инфраструктура MVC с именем BarelyMVC, поэтому у меня есть такие пространства имен:

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

и т. д. и т. д. Ваш сетевой псевдоним в большинстве случаев достаточно уникален, чтобы избежать конфликтов между другими разработчиками

Если вы боитесь использовать собственный онлайн-псевдоним, создайте «ярлык» для себя. Он не должен быть официально зарегистрирован как компания или что-либо (или даже домен). Например, популярная Json.Netбиблиотека использует пространство имен Newtonsoft.Json. Это очевидно основано на фамилии авторов "ньютон", но я не думаю, что кто-то действительно заботится об этом. И если у вас есть официально зарегистрированная компания, то вы, конечно, можете это использовать. Например, большинство общедоступных API, созданных моей компанией, имеют пространства имен, начинающиеся с PreEmptiveSolutionsназвания компании.

Нет правила, что имена пакетов Java или пространства имен .NET являются именами доменов. Нет даже требования, чтобы они были уникальными, хотя это, безусловно, хорошая идея. Я действительно думаю, что вы были правы в использовании com.googlecode.oldproj, и на вашем месте я бы не переключился, com.oldprojесли бы не попытался получить рекламу нового доменного имени.