Перевод статьи «Owning an Open Source Project: Part 2».
В предыдущей части мы обсудили, что такое open source и почему вообще им стоит заниматься. В этой статье мы подойдем к вопросу с более практической точки зрения и обсудим, как, собственно, дать старт проекту с открытым исходным кодом.
Итак, мы исходим из сценария № 1: у вас есть готовое решение конкретной проблемы и вы жаждете поделиться им с миром.
Давайте еще раз подчеркнем важные моменты:
- Речь не о том, чтобы потешить свое эго.
- Вы не надеетесь заработать на этом проекте.
- Вы искренне хотите помочь людям, которые сталкиваются с такими же проблемами, что и вы.
Если вы ответили утвердительно по всем пунктам, вот еще один чек-лист — чтобы убедиться в правильности действий:
- Проверьте, что open source — подходящий для вас формат. Если то, чем вы хотите поделиться с миром, очень маленькое, может быть, для его публикации вполне достаточно поста в блоге.
- Проверьте, нет ли уже существующего похожего проекта. Возможно, ваше решение станет прекрасным пул-реквестом в готовом проекте.
Будьте готовы к тому, с чем столкнетесь
Как я уже упоминал, ведение собственного open source проекта связано со многими сложностями.
Одна из самых больших проблем состоит в том, что это отнимает много времени. На все, что вы делаете для open source — написание кода, разбор возникающих проблем, обновление зависимостей, разговоры с людьми, ответы на вопросы и т. д., — требуется время. А каждая минута, которую вы инвестируете в свой проект, это минута, которую вы не потратите на свою семью, хобби, здоровье и все остальное.
Единственное, что может вам помочь, это делегирование полномочий. Когда (или лучше сказать «если») у вас в проекте будет достаточное количество участников, вы сможете поделиться частью ответственности с людьми, которым доверяете.
Отделение кода
Итак, у вас есть готовое решение конкретной проблемы и вы думаете, что оно пригодится окружающим. Но это решение интегрировано в вашу кодовую базу, а вы, вероятно, не захотите открывать миру весь этот код (хотя можете, конечно).
Первое, что нужно сделать, это отделить нужный код от остальной базы.
Начните с рефакторинга
…который в конечном итоге должен привести к тому, что весь нужный код окажется в отдельной директории.
Сделайте свой код универсальным
Код, вынесенный в отдельную директорию, должен стать достаточно обобщенным и не привязанным к конкретно вашей проблеме. При необходимости добавьте слой абстракции.
Приведу пример. Мой проект angular-builders начался с удовлетворения довольно специфической потребности — добавления пользовательского загрузчика для нативных модулей в сборку Angular. Я мог бы создать native-module-builder, который служил бы именно этой цели. Но я понял, что относительно легко могу создать более общее решение, которое сможет помочь с похожими (но не точно такими же!) проблемами.
Так родился сборщик custom-webpack.
Не усложняйте
Универсальность это хорошо, но не переусердствуйте с ней.
Преждевременная оптимизация и чрезмерная обобщенность это две очень распространенные проблемы в разработке программ. Нужно найти баланс, при котором ваш код будет решать не только вашу собственную проблему, но и другие проблемы, однако при этом — не все проблемы мира.
Если представить это в виде шкалы, на которой решение вашей специфической проблемы это 1, а решение всех проблем мира это 100, то для своего проекта ориентируйтесь на двоечку.
Ваш универсальный код должен решать немного больше проблем, чем ваш специфичный код.
Испытайте свое решение на себе
Используйте ваше универсальное решение в вашей же кодовой базе. Таким образом вы сможете удалить все лишнее из вашего кода и оставить только необходимое. Также этот подход поможет вам проверить, что код, который вы собираетесь открыть, является рабочим.
Помните, что первый пользователь вашего open source проекта это вы.
Не нарвитесь на судебный иск
Если вы собираетесь взять код из кодовой базы своей компании, проконсультируйтесь с начальством и, при необходимости, с юридическим отделом. Убедитесь, что они поддерживают вашу инициативу и что код, который вы собираетесь открыть, не является интеллектуальной собственностью вашей компании. Эти шаги также помогут вам определиться, какая лицензия open source лучше всего подойдет для вашего проекта.
Когда все работает, код отделен и достаточно универсален, у вас есть все разрешения (при необходимости) — время открыть ваш код миру.
Открытие проекта миру
Если ваш open source код уже отделен и обобщен, пора совершенно отключить его от вашей кодовой базы.
Выход на публику
Для начала нужно открыть исходный код вашего проекта (ведь потому мы и говорим об открытом исходном коде!).
Есть несколько вариантов размещения исходного кода онлайн, но мы пойдем самым распространенным путем и выберем GitHub.
- Создайте новый репозиторий на GitHub.
- Клонируйте этот репозиторий.
- Перенесите в репозиторий исходники из ранее созданной директории (но не удаляйте ее пока!).
- Commit & push — вуаля, теперь это проект с открытым исходный кодом.
Или нет?
Создание пакета
Ваш проект доступен публично, но им никто не пользуется (включая вас, потому что вы пользуетесь копией кода в своей кодовой базе). Никто даже не знает о его существовании.
Больше того, ваш проект доступен публично только в одном формате (в виде исходного кода), и единственный способ воспользоваться им — копипаст в какую-нибудь кодовую базу. Это не слишком удобно, не так ли?
Чтобы должным образом продвигать свой проект, вы должны:
- Создать пакет из своего исходного кода.
- Сделать этот пакет доступным в каком-нибудь публичном реестре пакетов (это зависит от вашей экосистемы, например, для Java это может быть Maven Central Repository, а для JavaScript — Npm Package Registry).
На этом этапе вы добавляете в свой новенький репозиторий цепочку сборки, выбираете имя для проекта и т. д.
Я не буду разбирать весь процесс, потому что он очень зависит от экосистемы, набора инструментов и используемого вами языка.
Возможно, вы мастер на все руки, для которого создать новый проект, а также добавить цепочку сборки и опубликовать проект это плевое дело. Если так, тем лучше для вас!
Но также вы можете оказаться человеком, который привык только писать код и никогда не сталкивался со всеми этими определениями, конфигурациями, артефактами и т. п. вещами. Все это может быть для вас совершенно новым миром. Что ж, пора учиться. И процесс не будет быстрым, это я вам обещаю.
В любом случае
Только когда вы уложите в голове все недостающие кусочки мозаики, изучите все, что касается соответствующего реестра пакетов, и опубликуете свой пакет, — только тогда вы сможете считать свой проект по-настоящему опенсорсным.
На этом этапе вы уже сможете говорить людям: «Эй! У меня уже есть готовое решение вашей проблемы! Просто добавьте этот пакет в свой проект!»
Проверка работоспособности
Прежде чем ваш проект станет «вирусным», следует убедиться, что он работает.
Чтобы проверить корректность вашего пакета, удалите директорию с обобщенным кодом из вашей кодовой базы и используйте вместо нее публично доступный пакет.
Ведь именно вы — первый пользователь вашего open source проекта.
Дальнейшая разработка
Когда вы начинаете использовать пакет в своей кодовой базе, ход разработки этого пакета чаще всего меняется. Раньше этот код был частью вашей кодовой базы, вы могли вносить все нужные вам изменения сразу. Сейчас это внешний пакет, такой же, как все остальные сторонние пакеты, используемые в вашем коде.
Поэтому теперь, чтобы получить возможность использовать в своей кодовой базе какие-то новые функции, разработанные вами для вашего нового блестящего open source проекта, вам придется для начала опубликовать вносимые изменения. Но вы не можете их опубликовать, не убедившись, что все работает, потому что после публикации этот код затронет и других пользователей.
Вот список действий, которые должны помочь вам не допустить публикацию сломанных версий:
- Покрывайте свой код тестами, как модульными, так и сквозными. Я полагаю, что нет нужды убеждать вас в необходимости и важности тестов.
- Упакуйте и установите новую версию пакета локально, в своей кодовой базе. Публиковать можно только убедившись, что все работает, как задумано.
- Опубликуйте бета-версию, доступную не всему миру, а только тем людям, которые явно выразят желание ее установить. В реестре пакетов npm, например, для этой цели есть специальные теги. Тег по умолчанию — latest. Когда вы запускаете команду npm install mypackage, на самом деле запускается npm install mypackage@latest. При публикации новой версии с другим тегом, например, beta, человеку, желающему установить данную версию, придется указать тег явно: npm install mypackage@beta.
Заключение
В отличие от предыдущей, чисто теоретической части, в этой статье мы рассмотрели практические вопросы. На прохождение шагов, описанных здесь, у вас может уйти от нескольких дней до нескольких недель (в зависимости от вашего опыта и способностей к учебе). А ведь мы, по сути, еще и не начали. Вот почему я чувствую себя обязанным спросить вас:
Вы действительно готовы пожертвовать довольно большое количество вашего драгоценного времени сообществу?
Продолжение: Собственный open source проект. Часть 3: документация
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]