В этой статье не будет психологических исследований на тему open-source и разработки.
Не будет анализа open-source проектов с помощью R или Python.
И не расскажу о том, как правильно контрибьютить.
Возможно я даже буду говорить какие-то банальные вещи.

Впервые я узнал про мир открытого ПО где-то в году 2009, когда начал серьёзно заниматься программированием и зарабатывать этим.
Но впервые отправил pull request в open-source проект году только в 2012. Это было попытка добавления Redis в качестве провайдера для кэша в Joomla Framework. Скажем так, попытка была не самая удачная, но попробовать очень хотелось.

Вернулся я к open-source позже - в 2015.
Я долгое время пытался придумать и реализовать с друзьями и коллегами разные идеи, «замутить стартап» и тд. Но всё почему-то захлёбывалось, лично мне не хватало мотивации.
Тогда я попытался взглянуть на эту ситуацию и понять почему это происходит.
Я понял, что всё дело в том, что меня интересовали не сами идеи, стартапы, бизнес, мне была интересна разработка и программирование.
И поняв это, я решил что если мне интересно программирование как таковое, то почему бы не направить это в полезное русло и не помочь улучшить инструменты, которыми я пользуюсь. Так я начал периодически отправлять pull request"ы в проекты, которые мне нравятся (Yii2 , Design Patterns , Django)

Почему это интересно?

1. Знакомство с новыми людьми

За всё время, что я контрибьютил в открытый код, я познакомился с большим числом отличных людей. Все они невероятные профессионалы, с которыми приятно общаться, делиться, узнавать новое. У каждого из нас есть возможность пообщаться с создателями любимых продуктов, получить от них отзыв. В целом коммьюнити - одна из самых важных составляющих таких проектов.

2. Участие во всемирно известных проектах

Вы можете работать в маленькой компании или жить где-то очень далеко, но у каждого есть возможность поучаствовать в развитии проектов, которыми пользуется весь мир. Facebook, Google, Ebay и другие выкладывают свои разработки во всеобщий доступ и мы имеем отличный шанс стать частью сообщества разработчиков таких интернет-гигантов.

3. Это весело

На самом деле, разработка ПО с открытым кодом зачастую бывает очень весёлым занятием, сопровождающимся живым общением.
Вот несколько примеров.

4. Признание

Это довольно интересное и тёплое чувство, когда Ваш код вливают в ветку известного проекта. Вы понимаете, что Вы действительно хорошо поработали, что в конце концов Вы что-то можете.
Если Вы вдруг теряете интерес к программированию или Вам кажется, что у Вас что-то не получается, попробуйте Open Source - и Вы поймёте насколько «лечебным» он может быть.

Почему это полезно?

1. Новый неповторимый опыт разработки

Тот опыт, который вы получаете при разработке ПО с открытым кодом, Вы вряд ли получите где-то ещё.
Я помню как я волновался, когда отправлял свой первый pull request. Я перечитывал каждую строчку кода, проверял code-style и т.д.
Осознание того, что Ваш код увидят тысячи других разработчиков , сами создатели проекта, заставляет вас думать, что Вы пишите в своём коде и это очень важно.

Кроме того, open-source разработка прививает хорошие навыки, такие как соблюдение стандартов кода, написание тестов и многое другое.
К тому же, здесь всегда есть возможность сделать code review чужого кода, если Вы устали от непосредственно написания кода. Это тоже бывает очень полезно и для кого-то это действительно новый опыт.

2. Возможность изучить что-то новое

Лично я люблю изучать новые языки программирования. Прочитав пару-тройку книг, хочется попровать язык в реальных условиях.
Но так как мне никогда в голову не приходят хорошие идеи (ха-ха:)), я ищу интересные проекты с открытым кодом на новом языке, и пробую контрибьютить в них.
Бояться показаться новичком не стоит, никто за это журить не будет, если будут какие-то недочёты, Вы всегда можете их исправить. А если Ваш код всё же вмержили, значит Вы действительно поняли ту или иную часть языка и проекта и можете гордиться собой.

3. Отличная галочка в резюме

После того, как я начал контрибьютить, мне всё чаще и чаще пишут HRы со словами - «нам нравится Ваша активность на GitHub, приходите к нам на собеседование».
Я думаю для работодателя ссылка в Вашем резюме на Ваши pull request"ы, принятые в крупные проекты, скажет о том, что вы действительно пишите достойный код, если его одобрило большое количество людей.
Кроме того, намного круче вместо сухого, вырванного из контектста примера кода, прислать работодателю ссылку на принятый pull request.

4. Знай свой инструмент

Участие в разработке продуктов, которыми Вы постоянно пользуетесь, помогает Вам лучше понять его - как он устроен внутри, как работает, какие люди в конце концов стоят за ним.
Кроме того, Вы всегда будете знать какие новые «фичи» появляются в проекте, какие есть нерешённые проблемы и многое другое.

5. Персональное развитие

Open source разработка помогает развить не только навыки программирования. Вот, на мой взгляд, небольшой список того, какие персональные качества развиваются ещё:

• Умение общаться
• Внимательность и аккуратность
• Уровень английского языка

Этот список можно продолжать ещё.
Кроме того, я считаю, что в каждом человеке присутствует желание помогать другому человеку, и как раз-таки Open Source разработка даёт такую возможность.

Заключение

В конце я хотел бы сказать вот о чём - единственное о чём я жалею, что мне не всегда хватает свободного времени участвовать в open-source разработке. Замечательно, когда компания, в которой Вы работаете, понимает важность такого участия для разработчиков и самой компании и выделяет для этого часть рабочего времени (а я такое встречал).
Тем не менее, даже если Ваша компания не делает этого, старайтесь хоть иногда участвовать в разработке открытого ПО, это сделает Вас настоящим профессионалом и подарит отличный опыт.

На недавно прошедшей конференции Application Developer Days 2012 мне довелось прочитать коротенький доклад о том, как создаются Open Source проекты на примере OpenVZ Web Panel. К сожалению, у меня было 10 минут, вместо положенных 30-40 и в результате 80% подготовленного материала оказалось “за бортом”. Организаторы, почему-то в последний момент передумали и убрали даже 5-минутную секцию с вопросами, так что остался без фидбэка. Но не буду сильно наезжать на организаторов - они старались как могли и конференция явно удалась, за что им огромное спасибо. Также очень порадовало и качество большинства докладов.

Теперь к сути топика - хочу выложить полную версию рассказа о том, как создаются Open Source проекты на примере собственного начинания, поделится мыслями и взглядами на разработку подобных проектов, рассказать о внутренней кухне, попробовать предостеречь от типичных ошибок.

Большая часть всего, что написано ниже - абсолютно субъективно. Некоторые вещи можно считать крамольными, однако многое было буквально выстрадано на собственном опыте.

Текста довольно много. Для особо нетерпеливых - можно просто полистать слайды.

Немного о подопытном кролике проекте

OpenVZ Web Panel - это довольно популярная бесплатная веб-панель управления виртуальными серверами на технологии OpenVZ. В подтверждение этого можно сказать, что версия 2.0 была установлена на более чем 17 000 серверов. Для серверного продукта вполне солидная цифра.

Что представляет собой OpenVZ? Это одна из технологий контейнерной виртуализации серверов. Кому-то нравится и подходит для решения задач, кому-то не очень, но сейчас не об этом. OpenVZ по сути является плацдармом для коммерческого продукта Parallels Virtuozzo Containers. Изначально для OpenVZ не было хорошей бесплатной веб-панели управления. Сам я активно пользуюсь OpenVZ. Существовавшие бесплатные панели меня не устраивали по тем или иным причинам. В результате родился проект OpenVZ Web Panel.

Разработка была исключительно в целях удовлетворить свои потребности, поэтому на определенном этапе было решено сделать проект Open Source. Поделится своими наработками с другими людьми, которые, возможно, тоже были в поиске подобной панели.

Идея вашего проекта

Рекламный блок вы прочитали, теперь возвращаемся к сути топика. Итак вы собрались создать свой Open Source проект. Первое, что должно у вас быть - это классная идея. В отличие от коммерческих проектов у вас не будет отдела маркетинга, массированной рекламы в специализированных изданиях и на биллбордах. Рекламу по телевизору бесплатного браузера Google Chrome может позволить себе только компания Google.

Кроме того, идею, желательно, как можно быстрее проверить на практике. Желательно выпустить альфа-версию и посмотреть на реакцию аудитории. Если будут восторженные отклики и множество пожеланий - вы идете в верном направлении. Если все молчат, то это хороший повод задуматься.

Мотиваторы-демотиваторы

Любой создаваемый вами проект должен иметь какую-то внятную мотивацию. Проекты из разряда “это прикольная штука и такой проект повысит мою карму” на практике очень быстро угасают. Примеры более весомой мотивации: вы собираетесь сами использовать свой проект или у вас есть конкретный заказчик. В случае OpenVZ Web Panel работал первый вариант, то есть необходимо было удовлетворить собственные нужды. Без сильной мотивации довести проект даже до первого релиза будет очень сложно.

Иногда люди говорят: создам Open Source проект, а потом на нем заработаю. Это пример неправильной мотивации. На самом деле, если вы действительно хотите заработать, то думать об Open Source нужно в самую последнюю очередь. Иначе наиболее вероятен следующий план развития событий: проект сделан, как зарабатывать - не понятно. В итоге мотивация полностью утрачена и продолжать развитие проекта вы уже не захотите.

Эффективная разработка

Старайтесь оставаться сфокусированным на нескольких самых важных для вашего проекта вещах. Сообщество будет толкать вас в сторону самых разнообразных изменений, уводить от основного курса. Например, для OpenVZ Web Panel если бы я соглашался и реализовывал все запросы пользователей, то давно бы уже делал очередной Webmin, а не систему управления контейнерами.

Разработка должны быть максимально эффективна в плане времени. Это единственный и самый дорогой ваш ресурс. Зачастую, принятые решения могут идти в ущерб качеству или каким-то требованиям, но если они эффективны по времени, то скорее всего вы идете в правильном направлении.

Кроме того желательно, чтобы вы умели выполнять практически любую задачу, которая встретится в вашем проекте. Если вы планируете какие-то работы делегировать другим людям, а работать они будут на общественных началах, то, поверьте, работа пойдет самым неэффективным образом. Плюс велика вероятность, что они вас просто продинамят.

Довольно трудным вопросом в плане эффективности является вопрос автоматизации процессов. С одной стороны вы же программист и предпочитаете действовать по принципу “за час написать и за 5 минут долететь”. Это принцип работает очень часто в ущерб вашему времени. Автоматизировать надо только то, что действительно повторяется из раза в раз.

В Open Source проектах обычно нет профессиональных тестеров, которые внимательно проверят все тест-кейсы и заведут вам баги, поэтому тестировать свой продукт, в первую очередь, будете вы сами. Это значит, что нужно заставлять себя писать функциональные и юнит-тесты, иначе вынуждены будете либо тратить время на ручное тестирование, либо пропускать в релиз серьезные проблемы. Тут, конечно, можно сказать: «спасибо, Кэп». Однако, в угоду экономии времени очень часто в проектах страдает именно этот пункт.

И последний момент. Если хотите вести разработку более-менее серьезно - занимайтесь учетом времени. Поставьте Redmine, заводите не только баги, но и задачи, пишите сколько потратили на них времени. Только тогда вы начнете понимать сколько в действительности стоит та или иная фича. В следующий раз вы уже вряд ли потратите два дня на автоматизацию одноразовой процедуры, которая делается вручную за полчаса. Кроме того, если вдруг появится спонсор, то будет гораздо легче объяснять стоимость той или иной фичи.

В рамках работы над OpenVZ Web Panel ко мне не раз обращались с просьбой собрать продукт в виде пакета под «любимую ОС». Причем под любимой ОС порой фигурировал и ArchLinux и Gentoo. Я ничего не имею против этих дистрибутивов, но сообщество их пользователей настолько мало по сравнению с тем же CentOS или Debian, что я потрачу кучу времени на очень сомнительную в плане пользы задачу. У панели есть замечательный Shell-инсталлятор. Я знаю, что он менее предпочтителен по сравнению с пакетами. Однако я также очень хорошо знаю, что поддержка пакетов на должном уровне для, скажем, пяти дистрибутивов Linux - это очень затратная задача в плане времени. Пока Shell-инсталлятор экономит мне уйму времени на разработку. Самое забавное, что если любителя Debian (который уже пятый по счету обещает прислать пакет, но ни один так нормальный пакет и не прислал), я еще попрошу попробовать собрать пакет под CentOS, то… ну вы меня поняли.

Качество продукта

Довольно часто пользователи Open Source продуктов недовольны их качеством. Если вы хотите сломать этот стереотип, не забываете о качестве продукта.

Под качеством нужно понимать не только тестирование продукта. Качество должно быть во всем - в дизайне, в юзабилити, во вспомогательных инструментах, сайте продукта, документации, технической поддержке.

Ниже скриншот фронт-энда для менеджера закачек wget. Подход программиста к дизайну интерфейса в чистом виде: «есть опция - должна быть на экране».

А вот скриншот WordPress. Можно любить или не любить этот продукт, но признать то, что люди явно работают над качеством продукта - стоит.

Нередко в Open Source проектах можно увидеть графический интерфейс, где в изобилии хаотично разбросаны элементы управления, а логика работы понятна только автору. Не забывайте о пользователях, пробуйте проводить ревью того, что вы делаете представляя себя в роли типичного пользователя. Если что-то работает не очевидным образом, будьте уверены - большая часть пользователей обязательно запутается и совершит ошибку. Характерный признак такой проблемы - в issue tracker’е уже 20-ый тикет на одну и ту же тему - где находится элемент управления. В этой ситуации люди часто ограничиваются просто добавлением информации в FAQ или Knowledge Base. На самом деле FAQ и Knowledge Base надо регулярно просматривать на предмет решения проблем в продукте и уменьшения списка часто задаваемых вопросов.

Не нужно забывать и о таком моменте, что качество кода на самом деле ваших пользователей интересует в последнюю очередь. А вот удобство использования, отсутствие как run-time так и логических ошибок очень сильно влияет на впечатление о продукте. Зачастую авторы стремятся к гармонии в плане кода и забывают об удобстве продукта. Понятно, что качество кода коррелирует с качеством продукта, но акцент желательно все-таки делать именно на втором моменте. В конце концов, многие успешные Open Source проекты имеют довольно унылый по качеству код. Хороший повод призадуматься (но не подумайте, что я агитирую вас писать говнокод).

Технологии

Open Source проекты предоставляют отличную возможность для обкатки новых технологий и проведения экспериментов. Обязательно пользуйтесь этим моментом. В корпоративных приложениях можно годами ждать перехода на использование какой-то модной и крайне удобной технологии. Здесь же вы сами себе CEO и CTO и все технические, архитектурные и стратегические решения можете принимать единолично.

Однако не стоит забывать и о конечных пользователях. Если у вас веб-приложение будте уверены, что большинство из них едва ли понимает, чем HTML3 отличается от HTML5. Однако если вы полностью откажетесь от поддержки IE, то они это обязательно заметят и просто не поймут. Пользователю в первую очередь важен контент, а не ваши технологические навороты.

В Open Source разработке вы менее ограничены в применении сторонних библиотек и фреймворков. Например, в OpenVZ Web Panel для UI используется известная библиотека ExtJS. Если вы захотите использовать эти библиотеку в своем коммерческом продукте, то нужно будет раскошелиться на весьма недешевую лицензию. С другой стороны работая с библиотекой ExtJS в рамках Open Source проекта вы можете получить ценный опыт ее практического использования и далее этот опыт применить в коммерческом проекте.

Отсутствие бюджета на разработку также толкает на поиск альтернатив дорогим платным компонентам. Нередко оказывается, что такие компоненты на порядок проще интегрировать и поддерживать, чем коммерческие аналоги. В конце концов, вы даже можете посодействовать развитию другого Open Source проекта, исправляя какие-то проблемы.

Инструменты

Существует довольно много удобных инструментов, помогающих в разработке Open Source проекта. Многие из них вы знаете и, наверняка, пользовались. Однако по настоящему их начинаешь ценить, когда работаешь над коммерческим проектом, где по тем или иным причинам эти инструменты не доступны. Вспоминаешь корпоративный Exchange и SharePoint и начинаешь грустить по Gmail и MediaWiki.

Не стоит также забывать о том, что ряд компаний стимулируют разработку Open Source проектов, раздавая таким проектам бесплатные лицензии на собственные коммерческие проекты. Например Atlassian может дать вам бесплатную лицензию на Jira или Confluence. Для разработки OpenVZ Web Panel некоторое время я использовал IDE RubyMine, бесплатную лицензию на который любезно предоставляли товарищи из JetBrains (пользуясь случаем передаю им привет и требую продления лицензии:)). В рамках интеграции с биллингом WHMCS, также понадобилась лицензия на продукт. Официально они не предоставляют бесплатных лицензий, но интерес был взаимный, поэтому лицензия была оперативно предоставлена. Поэтому, если вас интересует какой-то коммерческий продукт, который бы помогал в разработке проекта, обращайтесь к производителям этого продукта. Скорее всего вы сможете получить бесплатную лицензию, внятно объяснив зачем вам нужен именно их продукт.

Сообщество

Часто люди думают, что сообщество позволяет решать любые проблемы проекта. Это абсолютно неверно. Во-первых, если только вы не пишите инструмент для разработчиков, то среди пользователей оказывается, что нет программистов. Да и разбираться в дебрях вашего говнокода они почему-то не спешат. Если же вдруг вам прислали патч, то на проверку окажется, что в лучшем случае это костылик, который и работать-то не будет для большинства пользователей.

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

С другой стороны, багрепорты о насущных проблемах и голосование за фичи - работает вполне неплохо. Главное, не терять собственный контроль над ситуацией и быть готовым принять сложное и, может быть, не всем угодное, но правильное с точки зрения продукта, решение. Иначе моментально начинается известное произведение, где «лебедь раком щуку». Причем вы выступаете в роли отнюдь не лебедя.

Если же вам нужно перевести интерфейс на другой язык, попробовать причесать документацию, предложить что-то на обсуждение - сообщество всегда к вашим услугам. Устраивать холивары и бесконечные обсуждения - это тоже конек некоторых людей практически в любом сообществе.

И как обычно, в любом сообществе есть тот, кто чем-то недоволен и считает, что вы должны бросить все дела и заниматься только его проблемами. В конце концов он же пожертвовал вам 10 долларов.

Деньги?!

Я уже говорил о том, что если собрались заработать на проекте, то скорее всего этот проект не стоит начинать как Open Source. Отказаться от такой схемы в будущем будет очень сложно. С другой стороны как-то мотивировать разработку в финансовом плане все равно нужно. Даже на элементарную поддержку проекта вы можете нести расходы, например на хостинг, железо и прочее.

Ряд моих знакомых, почему-то продолжают свято верить, в что подобные проекты вполне могут жить на пожертвования. Не могут. На вскидку сейчас не могу вспомнить ни одного проекта, где видел более-менее внятную собранную сумму рядом с кнопкой Donate (тут важно не путать спонсорство и пожертвования). Если вы не создатель Википедии и на сайте проекта не висит личной фотографии с грусными глазами, то пожертвований вам едва ли хватит даже на хостинг сайта проекта. Не буду говорить о собственном проекте, т.к. для него статистика не публична. Но недавно заглядывал на сайт проекта Gitlab. Довольно интересное начинание, много заинтересованных. Внизу «градусник» с прогресом сбора суммы в 1000 долларов. Заглядывал туда 3 недели назад и сегодня. Собранная сумма изменилась меньше чем на 150 долларов. Причем это даже очень неплохо по сравнению со другими.

Более реальные способы заработка - это продажа альтернативных лицензии (подходит для встраиваемых в другие системы продуктов) и коммерческая поддержка (подходит для сложных в освоении продуктов). Для меня же лично, наиболее симпатичным выглядит вариант наличия спонсора-клиента или спонсоров, заинтересованного в развитии вашего проекта.

Правда, с появлением спонсора очень желательно не допустить пару типичных ошибок. Первое - это потеря всех прав продукт и передача их заказчику. Второе - это бесконечная работа над кастом-версиями продукта без возможности работы над главной линией. И то и другое в конечном итоге приведет к тому, что вы будете вынуждены закрыть проект именно как Open Source.

Выводы, куда ж без них

Старайтесь, чтобы в проект был в первую очередь интересен вам самим и решал какую-то вашу проблему. Большинство успешных Open Source проектов, которые приходят сейчас в голову, шли именно по такому пути. Это и Rails и Nginx и многие другие.

Если вы решили крупно заработать с помощью создания Open Source проекта, то заранее тщательно продумайте бизнес-модель. Скорее всего, лучше делать проект закрытым.

Помните о самом дорогом вашем ресурсе - времени. В конце концов, у вас наверняка есть основная работа и хоть какая-нибудь личная жизнь.

И последнее, создавайте законченный продукт, которым можно будет гордиться. Не останавливайтесь на «супер технологичной», но альфа-версии. Самое трудное и в коммерческой и в Open Source разработке - это довести продукт до релиза. Потом сможете ездить по конференциям и рассказывать всем о вашем успешном начинании (как, например, это делает автор Sphinx’а:)).

P.S. Все вышенаписанное - исключительно личное мнение. Я, как и многие другие, склонен ошибаться, учиться на своих ошибках и делать многие вещи неправильно, но при этом пытаться учить других:)

Многие разработчики стремятся попасть в проекты на «open source», но не знают, с чего начать. Причина этому – неуверенность в собственных силах. На самом деле open source-проекты предоставляют массу возможностей специалистам различного профиля. Программное обеспечение с открытым кодом, или «open source», существенно повлияло на развитие информационных технологий и заинтересовало многих разработчиков. Однако зачастую специалисты видят ряд препятствий для своего участия в open source-проектах. Вот основные из них:

• «Я не очень хороший программист».
• «У меня недостаточно времени, чтобы этим заниматься».
• «Я не знаю, каким проектом заняться».

Но это не очень хороший подход к проблеме. Так, существует три основополагающих принципа, о которых необходимо помнить всякий раз, задумываясь о новых возможностях в области разработки:

• В проектах нужны специалисты с разным уровнем профессиональной подготовки, навыков и опыта
• Даже специалист-новичок – лучше, чем отсутствие специалиста.
• Лучший проект для начала – тот, с которым вы уже знакомы.

Наиболее распространенное заблуждение у новичков в том, что они считают, что для участия в open source-проектах необходимо быть настоящим «гением программирования». Но это совсем не так. Безусловно, в мире open source-разработки есть свои гуру, однако далеко не все. Большинство из них – обыкновенные разработчики, которые всего-навсего хорошо делают свою работу, независимо от того, насколько малый или большой вклад они вносят в проект. И далеко не всегда эта работа связана с программированием. Работа над open source-проектами в основном заключается в рутинном исполнении текущих задач. Большая часть задач, которые получают разработчики, не требует гениального видения проблемы, как у Ларри Уола, создателя Perl, или Дэвида Хейнемейера Ханссона, основателя Rails. Создание нового языка программирования или фреймворка, конечно, требует вдохновения, но остальная часть работы, которая и делает такие проекты, как Perl или Rails, успешными, требует постоянных рутинных усилий. Эти усилия едва ли могут принести вам славу, но они, безусловно, нужны и важны, и рано или поздно ваш вклад будет замечен.

Внимательно слушайте

Все стадии работы в open source-проектах так или иначе связаны с людьми, которые в них задействованы. Вы присоединяетесь к команде, а это значит, что необходимо понимать, как устроены процессы и взаимодействие между всеми ее участниками. Прийти в команду со своим видением ситуации и навязывать всем свою точку зрения - не самый удачный вариант. Для некоторых проектов такой подход может быть приемлемым, но если над продуктом работают уже не один месяц, шансы на то, что ваши идеи воспримут с энтузиазмом, очень невелики. Прислушиваться к мнению и точке зрения коллег – это, пожалуй, лучший способ понять, что необходимо проекту на текущей стадии. 1. Присоединяйтесь к рассылке. На многих проектах e-mail-рассылка является основным способом коммуникации. На крупных проектах обычно есть несколько списков рассылки. Например, на проекте PostgreSQL используют не менее 12 рассылок, касающихся обсуждения вопросов пользовательского интерфейса, а также 6 рассылок для разработчиков. Оптимальный вариант – следить за основными рассылками в каждой из групп, чтобы начать вникать в основные текущие вопросы. 2. Следите за блогом. Блоги, которые ведут ведущие разработчики, могут быть весьма полезны, поскольку будут информировать вас об изменениях и улучшениях в грядущем релизе. Существуют специализированные порталы со словом “planet” в названии, которые аккумулируют новости и посты из блогов с различных ресурсов, связанных с проектом. Найти такой ресурс можно, отправив поисковой запрос типа “planet ”в Google. 3. Добавляйтесь в чат. Во многих open source-проектах для обсуждения текущих вопросов используются групповые чаты. Поэтому не забудьте выяснить, как общаются между собой участники вашего проекта.

Работайте с “тикетами”

Безусловно, код – это основа любого open source-проекта, но не стоит полагать, что написание кода – это единственный способ участия в проекте. Технической поддержке зачастую уделяют недостаточно внимания в погоне за созданием новых функциональных возможностей и исправлением ошибок. А ведь именно это и есть те области, которые позволяют новичкам войти в проект. Большинство проектов имеют общую открытую систему работы с “тикетами”, которая связана с веб-сайтом проекта и включена в документацию. Подобная система – это основной источник коммуникации между разработчиками и пользователями. Постоянная работа с текущими запросами – это отличная возможность внести свой вклад в проект. Для работы с системой могут понадобиться специальные права доступа, которые вам предоставит тим лид, как только вы решите заняться текущими запросами от пользователей. 4. Находите баги. В проектах с открытым исходным кодом баги часто проходят незамеченными. Обнаружение и сортировка багов может значительно сэкономить время разработчикам на поиск проблемы. Если пользователь пишет: «Программа не работает, когда я делаю такие-то шаги», - не поленитесь разобраться в том, чем вызвана эта проблема. Проблема повторяется? Вы можете вызвать эту проблему, повторив ряд конкретных шагов? Вы можете сузить круг проблемы до конкретного браузера или дистра? Даже если вы не знаете истинную причину проблемы, попытки сузить круг возможных причин во многом помогут разработчикам справиться с ней. Независимо от того, что вам удалось выяснить, добавьте свои комментарии к багу, чтобы все могли с ними ознакомиться. 5. Закрывайте старые баги. Нередко случается, что баги «пофиксили», но «тикет» не закрыли. Таким образом, система «засоряется» старыми багами, которые мешают работать с актуальными проблемами. «Очистка» системы трекинга от старых багов – это скучная и длительная процедура, но она очень важна для всего проекта. Для начала отфильтруйте «тикеты» по дате, например, старше, чем один год, и посмотрите, существуют ли такие баги. Просмотрите логи по релизам и убедитесь, что эти баги устранили и их можно закрыть. Если баг исправили, необходимо добавить комментарий с упоминанием версии, в которой баг был устранен, и закрыть его. Постарайтесь воссоздать баг в последней версии продукта. Если его невозможно воспроизвести, сделайте соответствующую запись и закрывайте «тикет». Если баг продолжает повторяться, укажите это в «тикете» и оставьте его открытым.

Работайте с кодом

Все программисты, работающие на проекте, независимо от опыта и квалификации, могут помочь вам с кодом. Не думайте, что вам необходимо быть гением, чтобы начать работать над проектом. Если ваша работа связана с изменением кода, изучите методы изменения кода, которые используются на проекте. Для каждого проекта характерны свои внутренние технические процессы, поэтому узнайте о них побольше, прежде чем предложить ваш вариант кода. Например, на проекте PostgreSQL жестко регламентированы все процессы: изменения в коде отправляются в виде патча в рассылке всем основных разработчикам, которые тщательно изучают все изменения. С другой стороны, есть и другие типы проектов, как, например, Parrot, где программисты могут «коммитить» все изменения непосредственно в базу. Если на проекте используется GitHub, возможно, процессы поставлены через pull request’ы, т.е. запросы на включение сделанных изменений. Помните: нет двух одинаковых проектов. Всякий раз, когда вы переписываете код, не забывайте, что вы работаете в команде и поэтому делайте все возможное, чтобы ваш стиль совпадал с общей базой, используемой в проекте. Часть кода, которую вы добавляете или меняете, не должна выбиваться из общего кода. У вас могут быть свои предпочтения в оформлении кода, но ваш код должен соответствовать общим стандартам, принятым на проекте. В противном случае это то же самое, что сказать: «Мне не нравится ваш стиль, и я думаю, что мой лучше, поэтому вы должны делать так, как я». 6. Тестируйте бета-версии. В любом проекте, который создается для работы на нескольких платформах, могут возникать проблемы, связанные с переходом на другую платформу. Накануне нового релиза, когда выходит новая бета-версия, руководители проектов ожидают, что они будут протестированы на различных платформах. Вы можете принять участие в тестировании и убедиться, что продукт работает на той или иной платформе. Как правило, вам необходимо собрать и установить новый «билд» и протестировать продукт, но особенно значимо для проекта, если вы используете нестандартные аппаратные средства. Если вы подтвердите, что «билд» работает и при таких условиях, это существенно облегчит задачу руководителей проекта в определении текущего статуса релиза. 7. Исправляйте баги . Обычно с этого начинается работа новичков с кодом. Здесь всё просто: найдите «тикет», в котором описывается какой-нибудь баг и попробуйте устранить его в коде. Подтвердите изменение в документации (если необходимо). Неплохо также добавить тест для тестирования той части кода, которую вы исправили; некоторые проекты требуют, чтобы все баг-фиксы сопровождались соответствующими тестами. Ведите записи, по мере того как вы осваиваете незнакомый код. Даже если вы не можете справиться с багом, опишите в тикете, что вам удалось о нем выяснить. Это поможет тем участникам команды, кто будет работать с багами после вас. 8. Пишите тесты. В большинстве проектов используются тестовые комплексы, предназначенные для тестирования кода, но сложно представить себе такой комплекс, который бы не предусматривал возможности добавления в него новых тестов. Используйте такие тестовые инструменты, как gcov для C или Devel::Cover для Perl, чтобы установить те области исходного кода, которые нельзя протестировать готовым тестовым комплексом. Затем добавьте соответствующий тест, чтобы иметь возможность протестировать необходимый функционал. 9. Отключайте оповещения компилятора. Часто «билд» проектов на С сопровождается многочисленными оповещениями компилятора. Такое сообщение не всегда говорит об ошибке, но заставляет отвлекаться. Проверьте, возможно, в коде скрыт какой-то баг. Если же багов нет, отключайте ложные оповещения. 10. Добавляйте комментарии. Когда вы просматриваете код, вам могут встретиться отдельные запутанные участки. Если какой-то кусок кода привел вас в недоумение, то велика вероятность того, что и у других он вызовет такую же реакцию. Опишите эту проблему в документации и отправьте патч.

Работайте с документами

Ведение документации – это рутинная составляющая любого проекта, которой зачастую пренебрегают. Кроме того, проблемы с документацией часто могут быть вызваны тем, что она написана с точки зрения людей, хорошо знакомых с проектом, нежели тех, кто только знакомится с ним. Если при чтении документации по проекту вас когда-нибудь посещала мысль: «Такое ощущение, что этот мануал написан так, как будто я уже знаю, как пользоваться программой», то вы понимаете, о чем речь. Очень часто новый взгляд со стороны позволяет выявить недостатки в текущей документации, которые могут быть не замечены непосредственными участниками проекта. 11. Приводите примеры. Нет таких проектов, в которых существовало бы слишком много примеров. Независимо от того, о чем идет речь: об API, об электронной библиотеке, о графическом приложении, таком как Gimp, например, или об инструментах командной строки – хороший пример с правильным описанием может быстро дать более четкое представление о правильном использовании программы, нежели стопка документов. Для API или электронной библиотеки создайте пример программы, которая использует этот инструмент. Он может быть взят из кода, который вы уже написали, и адаптирован к нуждам текущего примера. Для инструментов лучше всего привести какой-то пример, как можно использовать в повседневной жизни. Если вы визуал, добавьте скриншот какого-либо процесса, например, установки приложения.

Работайте в команде

Работа в open source-проектах только отчасти связана с кодом. Настоящий успех проекту приносит команда. И вы можете помочь созданию сплоченной команды. 12. Отвечайте на вопросы. Лучший способ сплотить команду – это помогать другим. Для дальнейшего успеха проекта особенно важно отвечать на вопросы, в частности, на вопросы новичков. Это время не будет потрачено зря, даже если новичок задает вопрос, на который можно найти ответ, перечитав необходимую документацию. Кроме того, вы получите нового благодарного и активного участника своей команды. Все с чего-то начинают, а любому проекту необходим постоянный приток кадров, чтобы он продолжал развиваться. 13. Ведите блог. Если у вас есть блог, делитесь своим опытом, который вы получили на проекте. Расскажите о проблемах, с которыми вы столкнулись при использовании софта, и как вам удалось их решить. Таким образом, вы сможете убить двух зайцев сразу: поддержать внимание к проекту своих коллег и создать полезную базу информации для тех, кто присоединится к проекту в будущем и будет искать в сети ответы на уже описанные вами вопросы. (Блог, рассказывающий о ваших технических достижениях и изысканиях – это также отличный способ поделиться реальным опытом разработки и решения технических проблем, который может вам пригодиться при поиске новой работы). 14. Уделяйте внимание вебсайту. Большинство программистов, к сожалению, не самые лучшие дизайнеры, поэтому едва ли найдется проект, при разработке которого не прибегали дополнительно к помощи дизайнеров. Если вы талантливый веб-дизайнер и можете помочь улучшить вебсайт, а, следовательно, и представление проекта для пользователей, именно на это вам и следует направить свои усилия. Возможно, сайту необходим редизайн или собственный логотип. Именно эти умения могут требоваться в вашей команде. Многим руководителям команды на проектах не хватает именно таких креативных дизайнеров. И самое главное: прислушивайтесь к словам ваших коллег. Возможно, вам удастся помочь им в решении насущной проблемы. Так, например, недавно разработчики Parrot в процессе обсуждения в рассылке решили использовать GitHub в качестве системы работы с «тикетами» вместо прежней системы Trac. Некоторые были против этого перехода, поскольку не было возможности перенести существующие «тикеты» в новую систему. После дня обсуждения всех «за» и «против» один из разработчиков предложил написать программу-конвертер, чем и привлек к себе внимание. Через некоторое время программа была готова, и всю историю из более 450 «тикетов» удалось сохранить. В любом проекте всегда есть возможность найти для себя работу, и на open source-проектах таких возможностей множество. Нужно только суметь найти правильное применение своим способностям.

Это перевод заметки Брайана Форда .

Я написал это руководство, чтобы помочь любому присоединяться или выкладывать свои (contributing) open source проекты на GitHub. Одна из причин крутости open source - в желании людей помогать друг другу.

Не важно - программируете ли вы много лет или только начали, есть несколько моментов, которые вам нужно знать, чтобы продуктивно использовать GitHub. Гайдов "как" сделать что-то с технической точки зрения на GitHub множество: на какую кнопку нажать, какие команды запустить и подобное.

В начале публикация своей работы на GitHub пугает. Существует мало руководств, посвященных этикету, практическим приёмам и ожиданиям. Этот гайд направлен заполнить пробелы.

Читая этот гайд, помните, что нормально (и даже ожидаемо!) делать ошибки. Не нужно запоминать каждую мелочь. Делайте всё возможное и учитесь в процессе.

Гайд предполагает, что вы работаете с JavaScript-модулем, установленным через npm или bower , который размещён на GitHub. Кроме команд, предназначенных для npm или bower , большая часть этого гайда применима к другим платформам и языкам.

Как задавать вопрос

Перед тем, как спрашивать, поищите и почитайте существующие записи. Загляните в документы, Google, GitHub, и StackOverflow. Если на ваш вопрос уже отвечали раньше много раз, то разработчики, ответственные за проект, возможно, устали повторять ответ.

Если проект маленький, обычно принято задавать вопросы через отправку issue (см. ниже). Если большой - у них скорее всего есть рассылка или IRC-канал, через которые лучше всего обращаться с вопросами. StackOverflow - также очень хороший ресурс. Когда есть возможность, задавайте вопросы на публичном форуме. Таким образом ответить на вопрос сможет кто угодно, а ответ будет доступен любому человеку с таким же вопросом. Если ничего не работает, можно написать в твиттер или на почту поддержки проекта.

Отправка уведомления о баге (issue)

На GitHub уведомления о багах или улучшениях называются "issues".

Об этом спрашивали раньше?

Перед тем как отправить уведомление, нужно поискать существующие issues. Не забывайте проверять и открытые issues и закрытые. Если вы найдёте issue, который подобен вашему, прочтите всё о нём.

Если issue такой же как у вас, вы можете прокомментировать с дополнениями, чтобы помочь ответственным за проект разработчикам (maintainers) сделать отладку. Добавление комментария автоматически подпишет вас на уведомления по почте, что может быть полезным, когда будут появляться обновления, касающиеся этого issue. Если вам нечего добавить, но вы хотите получать уведомления об обновлениях на почту, вы можете нажать кнопку "watch", которая находится под комментариями.

Нет, никто не спрашивал

Если вы не можете ничего найти в существующих issues, не стесняйтесь отправить свой.

Нужно проверить, что указана версия проекта, так же как и версии связанных с ним приложений. Например, удостоверьтесь, что включили номера версий, выводимые командами node --version и npm list . Если вы заметите, что у вас установлена не последняя версия, используйте npm update и подтвердите, что issue всё ещё присутствует.

Разработчики проекта очень приветствуют тщательные разъяснения. Обычно это помогает им быстрее справиться с проблемой и всем это на руку.

Улучшаем код

Лучший способ - сделать "Fork" (копию) репозитория на GitHub. Это создаст экземпляр-клон репозитория в вашем GitHub аккаунте.

Перед тем как улучшать код, стоит сфокусироваться на том, что вы хотите конкретно сделать.

Каждый коммит должен выполнять что-то одно, а на каждый PR (см. ниже) должно быть одно специфическое улучшение.

Forking

1. Нажмите на Fork в репозитории
2. Перейдите в ваш форк внутри вашего аккаунта
3. Сделайте git clone

Исправление и тестирование

Ок, теперь вы готовы к исправлению кода? Не совсем! Перед тем, как начать редактировать, вам нужно создать ветку (branch). Branch - как альтернативная временная линия. Можете почитать о git ветках .

Делаем ветку: git checkout -b something

Если вы пытаетесь починить баг, возможно вам стоит назвать ветку "fix-short-description". Если вы добавляете функциональность, "feat-short-description" - хорошее название. Когда вы меняете что-то в коде, возможно, вам захочется испытать его внутри какого-нибудь приложения или более крупного проекта.

В отношении стиля кода - просто пытайтесь имитировать стиль существующего. Не пыхтите над ним слишком сильно. Если владельцам не понравится внешний вид вашего кода, они предложат изменения.

Большая часть проектов пользуется наборами тестов, для уверенности в том, что имеющаяся функциональность кода не меняется из-за вносимых изменений. Это помогает поддерживать софт в стабильном состоянии.

Коммиты и пуш

git commit -m "your commit message"

Использование собственных изменений

Хоть это и не очевидно, вы можете начать использовать код в своих проектах сразу же.

Отправка ваших изменений обратно в проект

Вы сделали изменения, протестировали их с git commit и хотите отправить обратно в проект, чтобы они были включены в следующие версии.

На GitHub это делается с помощью отправки "pull request" (PR).

Отправка pull request

Золотое правило отправки pull request - всё выполнять так, как задумали владельцы проекта. Вы не можете читать мысли ответственных за проект, но можете посмотреть, что они делали в прошлом. Оценка этих действий заранее может повысить вероятность принятия ваших изменений.

Проще выражаясь: попытайтесь сымитировать стиль существующего кода. Обращайте внимание на отступы и стиль фигурных скобок в коде. Содержит стиль ранние инструкции return или там их избегают?

Код - не единственное, на что стоит обращать внимание. Заметьте какое время и формат имеют коммиты сообщений. Некоторые проекты используют настоящее время: "fixes the bug". А некоторые прошедшее: "fixed the bug".

Хороший способ проверить это - использовать git log и прочитать последние коммиты.

Что ещё стоит помнить:

Не меняйте номер версии софта (в package.json или bower.json). Владельцы проекта сами позаботятся об этом, когда будут выпускать новую версию.

Если проект поддерживается корпорацией, возможно у них есть Contributor License Agreement (CLA) для избежания проблем с законом.

Владельцы проекта могут быть заняты, так что дайте им немного времени. Разработчики, вовлечённые в open source, часто участвуют во множестве проектов. Нередко разработчик получает десятки нотификаций о неисправностях в день, так что будьте терпеливым.

Если они не отвечают в течение 2 недель, вы можете прокомментировать это, чтобы вынести тему наверх. Чего-нибудь, вроде, "ping @ProjectMaintainer" обычно достаточно. Если даже после этого от них ничего не слышно, электронная почта - хороший способ выйти на контакт.

Команда может ответить тремя возможными способами:

1. Всё сливается (merge). Ура!
2. Ответственный за проект просит вас исправить что-то в PR перед тем, как принять вас. Мы обсудим это ниже.
3. PR закрывается, а ваши изменения не добавлены. Обычно ответственные за проект дают небольшое разъяснение. Если от вас была новая фича, возможно, уже существует способ заставить код делать то, что вы хотите, вы просто этого не заметили. Если исправление бага, возможно, они хотят решить проблему иначе. Не позволяйте трудностям отбить у вас желание продолжать.

Исправление issues в pull request

Когда команда просит внести изменения в PR, новички ошибочно закрывают существующий и создают новый. Не стоит так делать! Существующий PR легко обновляется.

Во-первых, внесите изменения в соответствующие файлы. Добавьте файл с помощью git add , как вы уже делали:

git add some-file

Затем можете изменить свой предыдущий коммит вот так:

git commit --amend

Эта команда помещает ваши поэтапные изменения в предыдущий коммит.

Чтобы обновить коммит в вашем PR, вам нужно выполнить force push:

git push --force

Команда --force сообщает git , что вы хотите перезаписать предыдущий коммит.

Другая распространенная ошибка - создание нескольких коммитов, вместо внесения изменений в один.

Мой PR был закрыт, но я хочу использовать свои изменения!

Хорошие новости : даже если ваше изменение не будет принято в репозиторий контрибьютора, вы в любом случае сможете его использовать. npm позволяет установить из репозитория GitHub

$ npm install user/repo

А ещё вы можете использовать свои изменения и одновременно видеть изменения исходного кода репозитория. Обычно это называется "maintaining a fork" (поддержка копии) проекта. Для этого потребуется добавить ещё один remote .

Создание своего проекта

Перед тем как начинать свой проект, пожалуйста хорошо изучите существующие - нет ли сильно похожего на ваш.

Поиск по существующим проектам

$ npm search

Иногда вы находите старый проект, который больше не поддерживается, но он решает ваши проблемы. Как делать форк смотрите выше.

Бонус : Составляйте список заметок по ходу работы. Если найдете понравившийся модуль, можете использовать заметки, чтобы улучшить секцию «See Also» в тех модулях, которые вам встретились, пока вы вели поиск, отправив им PR. Если не найдёте нужный модуль и не создадите свой собственный, можете превратить эти заметки в секцию «See Also» для своего модуля!

Начало проекта

Начало нового open source проекта должно быть крайней мерой. Почему?

Практический опыт: Не публикуйте ничего в npm пока у проекта не будет обоснованной минимальной функциональности.

Помните: вы всегда можете использовать npm link или npm install user/repo

Название проекта

Если ваш модуль - это плагин, обычно лучший способ - сделать для него префикс, в зависимости от того для чего этот плагин. В некоторых проектах есть гайды или соглашения как это делать. Например компоненты AngularJS обычно называются "angular-something", плагины Gulp -"gulp-something", а плагины Karma - "karma-something".

Пишем Readme

Хороший readme должен состоять из следующих частей:

• Объяснение, которое умещается в одно предложение.
• Установка (Install)
• Смотрите так же (See Also)

Это правда важно . Если существуют другие модули с аналогичной функциональностью, ваш модуль должен объяснять, чем он отличается от других. Эта секция должна быть связана с другими модулями. Это поможет другим решить когда использовать ваш.

Пишем тесты

Есть много способов писать тесты. Их важность в том, что если они провалятся, процесс будет существовать с кодом ошибки. Вы можете использовать для этого assert или if (condition) { process.exit(1) } .

Бонус: вы используете инструмент CI вроде TravisCI .

Публикация в npm

Перед публикацией:

1. Вы написали README.md , который объясняет что делает модуль. Он должен включать секцию See Also , которая ведёт на другие подобные пакеты.
2. Вы написали тесты. Тесты должны запускаться с помощью npm test , и они должны проходить.

Бонус: Найдите кого-нибудь, кто будет содействовать в поддержке проекта. Отлично, если кто-то может помочь делать ревью issues и мёрджить PR. Невозможно угадать, как много свободного времени у вас будет в будущем. Обидно иметь непочиненные баги или несмёрженные PR в полезном проекте.

Этикет

Обычно люди покидают сообщества, которые кажутся им недоброжелательными. Чтобы быть уверенным, что все ощущают гостеприимство, важно относиться ко всем мягко и с уважением.

Чаще всего - это не проблема. Но иногда у разработчиков случаются срывы, эмоции зашкаливают, они оскорбляются.

Предполагать, что все делают всё возможное

эта задача должна быть очевидной для решения! почему её никто не решил?

Возможно у владельца проекта есть другие важные дела в жизни, которыми ему нужно заниматься. Ставить в приоритет жизненные задачи - не значит быть лентяем. Здоровье, счастье и благополучие реального человека на другом конце интернета намного более важны, чем любой баг.

Одна из мощных сторон open source как раз в том, что вы всегда можете сделать копию и отладить ошибки сами.

вы очевидно не понимаете, о чём я говорю!

Такой тип комментария особенно отталкивает новичков. Совершать ошибки должно быть абсолютно приемлемым.

Это проблематично ещё и потому, что на окружающих участников тоже распространяется чувство вины. Возможно, вы могли бы объяснить недочёт понятнее.

Абсолютно нормально злиться из-за бессилия. Программирование - это одна из самых сложных деятельностей человека. Но, несмотря на это, нужно не упускать точки зрения других людей. Сообщество намного более ценный компонент, чем код, а быть уважительным важнее, чем быть правым.

Заключение

Спасибо за то, что прочитали. Надеюсь этот гайд поможет вам получить то, чего вы хотели от open source.

1 января 2018 в 01:14

Как начать создание Open Source проекта в новом году

• Ruby ,
• Программирование

Полгода назад мне пришла идея создания своего open source проекта. Вместо тестовых задач на интервью мне было бы достаточно отправить ссылку на репозиторий, а перспектива помочь коллегам с решением их повседневных проблем еще больше зарядила меня энергией.

Мне всегда не нравились гемы для создания административных панелей, любое лишнее движение требует переопределения классов, для изменения полей нужно делать изменения в файлах. После размышлений и беседой с коллегами было принято решение создать новую библиотеку, которая была бы гибкой и не требовала бы дашбордов или файлов конфигурации.

Определите цели

Каждый open source проект решает определенную проблему. Пообщайтесь с коллегами, чаты, форумы, расскажите о своей идее - все это поможет вам на раннем этапе сформировать картину того, какие решения уже существуют и услышать критику со стороны. Пообщайтесь с людьми, у которых уже есть свои open source проекты, они могут дать очень ценные советы, не бойтесь спрашивать и проявлять инициативу.

Одним из ценных советов, который я получил на данном этапе, это обратить внимание в первую очередь на документацию проекта. У вас может быть очень хороший проект, но никто не будет читать исходники и пытаться понять как это работает.

Самый важный аспект, без которого дальнейшие этапы невозможны это мотивация. Идея проекта должна цеплять в первую очередь вас. Чаще всего люди привыкают к тем инструментам с которыми работают и попадают в зону комфорта.

Планирование

Задачи следует фиксировать и иметь четкую картину на каком этапе сейчас находится проект в целом. Разбейте задачи на подзадачи, в идеале чтобы выполнение одной задачи не занимало более 3-4 часов, важно получать удовольствие от выполнения небольших задач, это поможет избежать выгорания и потерю мотивации.

Выбор определенного таск менеджера вопрос вкуса. Я использую pivotal tracker, основное преимущество является наличие бесплатной версии для open source проектов, присутствует сортировка задач по типу (feature, bug, chore, release), задачи можно группировать в релизы и определять дедлайн.

Еще одной приятной возможностью у pivotal tracker является интеграция с github. Если вы соблюдаете определенную конвенцию в именовании комитов, то внутри задачи будут автоматически отображены все связанные изменения с этой задачей.

Оформление

В каждом open source проекте должны присутствовать следующие вещи:

• README
• open source license
• Contributing guidelines

Файл README не только объясняет как использовать ваш проект, но и какая цель вашего проекта, как начать его использовать. Если не знаете как правильно оформить README можете посмотреть другие известные open source проекты или воспользоваться шаблоном .

Лицензия гарантирует, что другие могут использовать, копировать и модифицировать исходный код проекта. Вам необходимо добавлять этот файл в каждый репозиторий с вашим open source проектом. MIT, Apache 2.0 GPLv3 самые популярные лицензии для open source проектов, если не уверены какую выбрать можете воспользоваться удобным сервисом .

Файл CONTRIBUTING поможет другим разработчикам сделать вклад в проект. На первых шагах проекта не обязательно уделять этому файлу пристальное внимание, можно воспользоваться уже готовым шаблоном из другого проекта.

Мои ошибки

Если анализировать первоначальный этап, у меня была идея, но не было четкого плана. Я решил, что хочу сделать это, не имея четкого представления сколько по времени это может занять и конкретного представления функционала, который будет в первой версии библиотеки.

У меня было просто много желания и отсутствие четкого плана
Так же почитав историю других проектов, не только open source, я заметил, что на раннем этапе имеются слишком оптимистичные планы и переоценка своих сил и возможностей. Не так просто находить время каждый день на написание новой фичи в проект. Большую часть задач пришлось в итоге отсеять и оставить необходимый минимум для