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, я заметил, что на раннем этапе имеются слишком оптимистичные планы и переоценка своих сил и возможностей. Не так просто находить время каждый день на написание новой фичи в проект. Большую часть задач пришлось в итоге отсеять и оставить необходимый минимум для

Открытое программное обеспечение стало двигателем инноваций. И в этой статье вы убедитесь в этом. Мы рассмотрим лучшие проекты OpenSource по версии премии Black Duck Open Source Rookies.

Это восьмой выпуск Black Duck Open Source Rookies. Каждый год, Black Duck рассматривает мир свободного программного обеспечения и находит лучшие новые Open Source проекты, которые были реализованы в этом году.

Большая часть проектов, получивших награду Black Duck разработана или финансирована коммерческими компаниями. Некоторые проекты - это дополнения к основной продукции спонсоров или внутренние ответвления, в то время как другие становятся поводом для развития этих основных проектов.

Как правило, у лауреатов премии наблюдается три тенденции в отрасли:

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

У RocketChat есть собственные приложения для Linux, Windows, MacOS, а также мобильные приложения для Android и iOS. Здесь даже есть собственное приложения для FirefoxOS, для настольных и мобильных устройств. А поскольку это Open Source проект, то это отличный выбор для разработчиков, жалеющих строить и развивать собственную платформу чата.

Mattermost

Другой отличной альтернативой для Slack есть Mattermost, ее история началась с компании - разработчика игр для HTML 5. Изначально это был игровой портал и приложение для обмена сообщениями, цель которого была найти геймеров за пределами Facebook. В итоге программа была переделана в решение для совместной работы в пределах компании, для таких случаев, когда компания не хочет, чтобы ее данные были получены провайдером. На данный момент - это отличная альтернатива Slack с открытым исходным кодом написанная на React и Go.

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

Hubl.in

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

Hubl.in - свободное решение с открытым исходным кодом, для организации видеоконференций от компании Linagora, создателя платформы для совместной работы - OpenPaaS. Hubl.in поднимает связь в реальном времени на новый уровень, позволяя использовать браузер для организации видеоконференций, даже без каких либо плагинов.

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

MXNet

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

MXNet - это легкая библиотека машинного обучения, созданная DMLC разработчиками CXXNet, Minerva, и Purine2. Здесь применен опыт, полученный в этих проектах, а также смешан императивный и символический стиль программирования. MXNet использует планировщик динамических зависимостей, который автоматически паралеллизует как символические, так и императивные операции на лету. Уклон в сторону оптимизации делает MXNet быстрым и потребляющим немного памяти. Библиотека портативная и легкая, она легко масштабируется даже для нескольких машин. Можно даже использовать для таких задач, как распознавание образов на смартфоне. Группа DMLC хочет сделать открытое программное обеспечение широкодоступным. Проект MXNet тоже содержит набор руководств и схем для построения систем машинного обучения.

Bazel

Bazel стремится ускорить процесс сборки и повысить надежность за счет общего хранилища кода, в котором все программное обеспечение находится в состоянии открытого исходного кода. Здесь автоматизировано тестирование и релизы, используется как параллельность, так и кеширование, чтобы ускорить обработку. Особенно подходит для проектов с крупными базами кода, на основе нескольких языков программирования или для различных платформ. Основная особенность Bazel - тщательное тестирование в сложных условиях работы в Google. Текущая версия поддерживает Linux, OS X, но не Windows.

React Native

Разработчики мобильных приложений сталкиваются с трудным выбором: разрабатывать приложения для iOS или Android с помощью собственных инструментов, или воспользоваться кроссплатформенными. С одной стороны, родные приложения быстрее и предлагают лучший пользовательский интерфейс. Однако разработка такого приложения, означает - написать его, по крайней мере, два раза на самых разных языках программирования. Кроссплатформенные инструменты, такие как JavaScript позволяют им писать программу только раз, но эти приложения часто работают плохо и выглядят не очень красиво.

React Native - это OpenSource проект с открытым исходным кодом, поддерживаемый Facebook. Он позволяет двигаться сразу в двух направлениях. Создавая свои приложения с помощью библиотеки JavaScript React вы сохраняете логику работы приложений JavaScript, а также пользовательский интерфейс полностью нативный для обоих оболочек iOS и Android. Для разработчиков React Native представляет собой новый подход к написанию мобильных приложений - учиться раз, писать везде.

Kontena

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

Kontera - проект с открытым исходным кодом, для управления контейнерами. Kontera имеет много новых технологий и возможностей для ускорения развертывания. Здесь есть поддержка нескольких хостов, мульти-AZ контейнеры, сетевая технология Weave, VPN доступ к контейнерам, а также интуитивно понятный мастер развертывания. У Kontera есть все что компании может понадобиться для разработки, развертывания и контроля контейнерных систем. Она может быть установлена в любой облачной инфраструктуре. Поскольку это открытый исходный код, она скоро выйдет за рамки Docker и будет поддерживать контейнеры Windows, CoreOS PKT и другие контейнерные технологии.

Nulecule

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

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

InSpec

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

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

Hygieia

Технологические гиганты не одиноки в инвестировании в свободное программное обеспечение. В этом году Capital One попытались найти панель инструментов для разработчиков, и небыли обнаружены ни коммерческие решения ни OpenSource проекты. Поэтому компания создала собственную - Hygieia. Панель выпущена в прошлом году и ее исходный код опубликован на GitHub.

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

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

Glucosio

Когда программисту Бенджамину Кернеса был поставлен диагноз диабет второго типа в мае 2015 он понял, что нет инструментов с открытым исходным кодом для отслеживания уровня глюкозы или других показателей, для людей подобных ему. В сентябре 2015, он и небольшая команда выпустили Glucosio, первое приложение с открытым исходным кодом для мониторинга уровня глюкозы.

Пользователи Glucosio могут отслеживать уровень глюкозы в крови и получить полезные советы, через приложение помощник. Пользователи также могут внести свой вклад в исследование диабета, оставив анонимную демографическую или личную информацию. Glucosio на данный момент доступно на 20 языках и было загружено на каждом континенте. Разработчики также планируют предложить бесплатный API для исследователей, чтобы они могли получить доступ к данным, которые пользователи оставляют в программе.

Vault

Компания из Сан-Франциско HashiCorp известна своим инструментом для создания и настройки легкой, портативной среды разработки - Vagrant. Новый проект с открытым исходным кодом этой компании - Vault, инструмент для безопасного управления секретами. Здесь могут находиться ключи, API, пароли, сертификаты, учетные данные сотрудников, и другая секретная информация. У HashiCorp отличные Open Source проекты, можно сказать - так держать.

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

Rancheros

Rancher Labs разработала высокоэффективную технологию запуска контейнеров - операционную систему в миниатюре, со всем необходимым для запуска контейнеров, но ничего больше. RancherOS - это дистрибутив Linux, размером 20 Мб, специально разработанный для простого способа запуска и управления контейнерами Docker. Идея заключается в том, что он похож на CoreOS, Но с одной особенностью - все здесь работает через Docker контейнеры, даже сама операционная система.

В RancherOS Docker работает непосредственно поверх ядра Linux и распределяет все сервисы пользовательского пространства как контейнеры Docker. Экземпляр системы Docker инициализирует все системные службы (Udev, DHCP, TTY) каждая из которых работает в отдельном контейнере. Экземпляр пользователя Docker создает отдельные контейнеры для всех пользователей, в пределах основного контейнера пользователя. RancherOS также обеспечивает обновление через контейнеры и может использовать различные системы управления контейнерами.

OWASP Security Knowledge Framework

OWASP Foundation (Проект Open Web Application Security) - это некоммерческое сообщество, которое предоставляет ресурсы и средства для обеспечения безопасности веб-приложений, которые разрабатывают OpenSource проекты. Многие разработчики не знают о рисках безопасности уязвимостей, с которыми они сталкиваются. С этой целью OWASP SKF (Security Knowledge Framework) обеспечивает свободный инструмент с открытым исходным кодом для обеспечения безопасности веб-приложений. Он также может служить учебным пособием, которое научит основам безопасности в веб-приложениях.

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

Выводы

Это были все новые Open Source проекты, отмеченные премией Black Duck. Награждение происходит каждый год, поэтому новые Open Source проекты за 2016 год мы увидим только в 2017.

Это не пустой призыв, в данном посте я расскажу какие бонусы приносят бесплатные сервисы и open source проекты…

И так начну со перечисления своих проектов (я не скромный и плодовитый):

• Бесплатные сервис: Charts Builder (~3 000 посещений)
• jQuery плагины: (a) Slideshow (~2 500 скачиваний), (a) Sexy Images (~500), jQuery iPhone UI (~3 500)
• WordPress плагины: (a) Slideshow (~14 000) и (a) QR Code (~300)
• WordPress темы: Constructor (~200 000), Black Urban (~16 000)
• PHP библиотеки: ZFCore (~800), jQuery PHP (~7 500), Yandex XML (~700), (~1 200)
• Разное: iCMS (~700)

Теперь о плюшках, которые мне дал каждый из этих проектов:

Опыт разработки

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

// Create new instance of Yandex class $Yandex = new Yandex(); // Set Query $Yandex -> query($query) -> host($host) // set one host or multihost -> page($page) // set current page -> limit(10) // set page limit -> geo($geo) // set geo region - http://search.yaca.yandex.ru/geo.c2n -> cat($cat) // set category - http://search.yaca.yandex.ru/cat.c2n -> request() // send request ;

Опыт общения

В моей повседневной работе я редко общаюсь непосредственно с заказчиками, а вот занимаясь поддержкой своих проектов — постоянно. Кто-то что-то спрашивает, кто просит о фичах, а кто указывает и на ошибки. Помню было время, когда каждый баг или изменение функционала в рабочих проектах воспринимался в штыки, с open source проектом такой фокус не пройдет, ты либо адекватно реагируешь, либо теряешь пользователя. Такой расклад достаточно хорошо дисциплинирует. В моем почтовом ящике нет не отвеченных писем, хотя иногда и приходится начинать письмо с фразы «sorry for the late reply letter».

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

Thats all when ANTON says anything listen to him he is always right:D

Монетизация

Сервис Charts Builder, как и большинство домашних страниц монетезированы при помощи Google AdSense, кое-где висит Text-Ads-Links , выхлоп при этом составляет ~$20 с AdSense и $60 с Text-Ads-Links в месяц (это всего 8 ссылок).

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

На каждой домашней страничке проекта у меня висит кнопочка «PayPal Donate» — именно она приносит свои плоды. С момента ее появления, а это декабрь 2009, мне накапало от сознательных людей ~$600. Для более активной стимуляции пользователей стандартная кнопка была заменена на progress bar :

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

Бонусы

Наверное главным бонусом является распространение байки о том, что автор — «крутой разработчик». В подтверждение этой теории на моем почтовом ящики скопилось достаточное количество писем с предложением о постоянной или временной работе, главное чтобы было желание.

Ну еще бонус – мне вот недавно понравилась IDE PHPStorm , и у меня сейчас установлена бесплатная лицензионная версия для open source разработчиков:

У разработчиков WordPress тем есть дополнительный бонус в виде входящих ссылок (SEO специалисты смогут перевести эти цифры в деньги):

Трудозатраты

Тут все не так безоблачно, на разработку и на поддержку проектов естественно требуется время. Я могу рассказать о создании сервиса http://charts.hohli.com , просто тут не было поддержки и каких либо изменений, лишь разработка и отдача. Разработка заняла у меня один воскресный день, именно так, я просто читал новости, увидел сообщение о выходе нового Google Charts API и целый день потратил на разработку. Стоимость моего выходного дня — €165. В дальнейшем, поднабравшись опыта, сервис был обновлен за 16 часов — +€150.

Насчет же поддержки, каждый день на нее у меня уходит в среднем 15-20 минут, что ни коим образом не сказывается на моей эффективности, и даже наоборот, поможешь человеку с утра, и «настроение твоё улучшилось».

Раскруткой проектов практически не занимаюсь, статья в блоге + статья на хабре , вот и всё.

P.S.

В действительности, большинство моих проектов — это изучение нового, просто не хочется тратить время на простенькие примеры «hello world», ведь хочется создать действительно что-то полезное. Учил Google Chart API — создал charts.hohli.com , надо было подучить WordPress — вот вам Конструктор , изучал возможности jQuery UI — вот и iPhone UI подоспел, примеров могу приводить много.

Практика в open-source проектах поможет при составлении портфолио для трудоустройства. В статье приведены рекомендации по изучению этой тематики.

Прежде чем вы начнете…

3. Мгновенные ответы DuckDuckGo

Если кто не знал, DuckDuckGo – поисковая система, не собирающая информацию о пользователях. Мгновенные ответы - фича, которая позволяет получать ответы без необходимости открывать сайт. Сотни людей успели принять участие в разработке этой фичи, много идей для разработки лежит на этой странице . Также DuckDuckGo предоставляет хорошую документацию и рекомендует новым пользователям создавать шпаргалки для сервиса. Чтобы посмотреть, как выглядят такие шпаргалки, достаточно вбить в поисковик фразу «wordpress cheat sheet» . Если у вас возникли трудности, есть канал в Slack и вики-страница в Github-репозитории .

4.

5. Проекты Mozilla

Вне сомнений, Mozilla – одна из лидирующих организаций по количеству open-source проектов. Делать свой вклад в развитие проектов Mozilla может показаться не очень простым на первый взгляд, поскольку сложно найти задачи, помеченные как «для новичков», из-за того, что в целом задач много. К счастью, был создан отдельный сайт , где можно фильтровать задачи в зависимости от своих интересов. Новичку стоит обратить внимание на фильтр simple bugs внизу в секции фильтров!

6. Pinax

Pinax – это открытая опенсорсная платформа, сделанная с использованием веб-фреймворка Django. Это экосистема для повторно используемых приложений на Django, тем, шаблонов для нового проекта. В их репозитории на Github в разделе Issues есть задачи для новичков, помеченные first-timers-only . Они аккуратно задокументированы, таким образом, чтобы вы знали, что вам следует делать.

Я хочу еще проектов, что делать?

• Ищите по меткам в интересующих вас репозиториях. Наверняка там будет какая-нибудь задача в issues, которая помечена как легко решаемая.
• Зайдите на следующие ресурсы:

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

Я написал это руководство, чтобы помочь любому присоединяться или выкладывать свои (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.