В этой статье не будет психологических исследований на тему 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 разработке. Замечательно, когда компания, в которой Вы работаете, понимает важность такого участия для разработчиков и самой компании и выделяет для этого часть рабочего времени (а я такое встречал).Тем не менее, даже если Ваша компания не делает этого, старайтесь хоть иногда участвовать в разработке открытого ПО, это сделает Вас настоящим профессионалом и подарит отличный опыт.
Это не пустой призыв, в данном посте я расскажу какие бонусы приносят бесплатные сервисы и 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 подоспел, примеров могу приводить много.
Свободное программное обеспечение - неотъемлемая часть бизнеса Google. В этой компании проекты буквально рождаются и умирают с open source. Без Linux и открытого ПО не существовало бы компании Google в том виде, в каком мы её знаем. Google не только использует СПО в повседневной деятельности, но и постоянно выкладывает в открытое достояние собственные наработки. Например, за три месяца текущего года Google открыла Chrome для iOS , Upspin (фреймворк для глобального единого пространства имён), E2EMail (экспериментальный почтовый сервис с оконечным шифрованием), перцептуальный JPEG-энкодер Guetzli . Это только самые крупные проекты, которыми Google поделилась с сообществом в 2017 году.
Всего за время своей работы Google опубликовала код уже более 2000 проектов. Только как их посмотреть? Теперь вдобавок к репозиториям на GitHub все open source проекты Google доступны по единому адресу . Это новый портал свободного программного обеспечения поисковой компании.
В Уилл Норрис (Will Norris), разработчик группы Google Open Source Programs Office, пишет: «Свободное и открытое программное обеспечение лежало в нашем техническом и организационном основании с самого начала существования Google. Начиная с серверов под Linux, и заканчивая внутренней корпоративной культурой Google, когда кто угодно из другой команды разработки может выпустить патч для вашего кода. Open source является частью всего, что мы делаем. В обмен, мы публикуем миллионы строк open source кода, поддерживаем программы вроде Google Summer of Code и Google Code-in , спонсируем проекты open source и сообщества через организации вроде Software Freedom Conservancy , Apache Software Foundation и ».
И вот сейчас, спустя 18 лет после своего основания, компания Google открыла портал , который объединяет все открытые проекты Google, с сопутствующей информацией об использовании, выпуске и поддержке свободного программного обеспечения.
Зачем Google делает это? Если верить сайту, компания уверена, что СПО является всеобщим благом . Когда софт открыт и доступен для всех, это поощряет сотрудничество и продвижение технологий и «решает реальные мировые проблемы».
Наверное, так оно и есть на самом деле.
Нужно заметить, что портал Google - это не репозиторий вроде GitHub, а скорее инфорационно-справочный портал, здесь стоят ссылки на соответствующие репозитории GitHub. Таким образом, вряд ли можно опасаться, что Google откажется от размещения кода на GitHub, самом удобном сайте для совместной работы, который уже стал стандартом де-факто в своей области.
Уилл Норрис пишет, что компания не знает, какие проекты станут популярными и получат всеобщее признание, поэтому они поощряют своих сотрудников публиковать весь код, какой только возможно . Соответственно, здесь можно найти разные проекты по масштабу и уровню поддержки. Есть и крупные известные проекты вроде , и , есть и маленькие «любительские» проекты, которые сотрудники, вероятно, создали в свободное от основных обязанностей время (20% времени рабочего программисты Google могут работать над проектами на своё усмотрение). Например, и . Некоторые из проектов полностью поддерживаются и развиваются сотрудниками Google и сообществом, другие являются экспериментальными, сделанными просто ради удовольствия.
Есть кое-что ещё. Новый портал Google - это не просто собрание открытых проектов, сделанных в компании. Здесь компания ещё и делится своим опытом и корпоративными практиками разработки открытого программного обеспечения. В опубликована копия всей внутренней документации Google по разработке open source (за исключением нескольких документов). Это именно то, что видят и читают сотрудники компании. Здесь несколько разделов. Один из них посвящён - в том числе создание патчей для больших проектов и написание собственных маленьких проектов в 20% свободного времени. Другой раздел объясняет практики OSS внутри компании. Там разъясняется, под какими лицензиями можно брать и использовать код. Например, код под лицензиями AGPL использовать . Здесь размещён тщательно отобранный каталог из тысяч пакетов, рекомендованных для использования. Наконец, третий раздел посвящён инициатив свободного ПО: различным студенческим программам, проводимым мероприятиям, выдаваемым грантам и т. д.
Очевидно, что Google видит свободное ПО как неотъемлемую часть своей деятельности - и стремится максимально поддерживать и использовать его.
Open source становится важной частью бизнеса не только Google, но и многих других компаний. Как и предсказывали отцы-основатели, свободный софт распространяется как вирус, заставляя создателей производных программ тоже выпускать их под свободными лицензиями. Как сказал исполнительный директор Linux Foundation Джим Землин (Jim Zemlin), свободное ПО станет новым . Он имеет в виду, что 80% ценности любых технологий - от смартфонов или других сфер ИТ - будет происходить от свободного софта, и только 20% - от проприетарного. Процесс постепенно идёт. Исследования показывают, что в 2015 году .
Это перевод заметки Брайана Форда .
Я написал это руководство, чтобы помочь любому присоединяться или выкладывать свои (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
- Нажмите на Fork в репозитории
- Перейдите в ваш форк внутри вашего аккаунта
- Сделайте 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" обычно достаточно. Если даже после этого от них ничего не слышно, электронная почта - хороший способ выйти на контакт.
Команда может ответить тремя возможными способами:
- Всё сливается (merge). Ура!
- Ответственный за проект просит вас исправить что-то в PR перед тем, как принять вас. Мы обсудим это ниже.
- 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
Перед публикацией:
- Вы написали README.md , который объясняет что делает модуль. Он должен включать секцию See Also , которая ведёт на другие подобные пакеты.
- Вы написали тесты. Тесты должны запускаться с помощью npm test , и они должны проходить.
Бонус: Найдите кого-нибудь, кто будет содействовать в поддержке проекта. Отлично, если кто-то может помочь делать ревью issues и мёрджить PR. Невозможно угадать, как много свободного времени у вас будет в будущем. Обидно иметь непочиненные баги или несмёрженные PR в полезном проекте.
Этикет
Обычно люди покидают сообщества, которые кажутся им недоброжелательными. Чтобы быть уверенным, что все ощущают гостеприимство, важно относиться ко всем мягко и с уважением.
Чаще всего - это не проблема. Но иногда у разработчиков случаются срывы, эмоции зашкаливают, они оскорбляются.
Предполагать, что все делают всё возможное
эта задача должна быть очевидной для решения! почему её никто не решил?
Возможно у владельца проекта есть другие важные дела в жизни, которыми ему нужно заниматься. Ставить в приоритет жизненные задачи - не значит быть лентяем. Здоровье, счастье и благополучие реального человека на другом конце интернета намного более важны, чем любой баг.
Одна из мощных сторон open source как раз в том, что вы всегда можете сделать копию и отладить ошибки сами.
вы очевидно не понимаете, о чём я говорю!
Такой тип комментария особенно отталкивает новичков. Совершать ошибки должно быть абсолютно приемлемым.
Это проблематично ещё и потому, что на окружающих участников тоже распространяется чувство вины. Возможно, вы могли бы объяснить недочёт понятнее.
Абсолютно нормально злиться из-за бессилия. Программирование - это одна из самых сложных деятельностей человека. Но, несмотря на это, нужно не упускать точки зрения других людей. Сообщество намного более ценный компонент, чем код, а быть уважительным важнее, чем быть правым.
Заключение
Спасибо за то, что прочитали. Надеюсь этот гайд поможет вам получить то, чего вы хотели от open source.
С помощью open source проектов можно усовершенствовать свои навыки, исправляя чужие ошибки и создавая что-то новое. Можно найти проект, который будет полезен и для собственного бизнеса, например, в медицине или e-commerce. Кроме того, как практикующие программисты, один из лучших способов мотивировать себя на занятия программированием - это работа с open source проектами. Специально для читателей блога Geekbrains мы собрали список таких проектов из разных сфер деятельности:
Пакет программного обеспечения для работы с медицинскими изображениями. 3D Slicer доступен на нескольких платформах, в числе которых Windows, Linux и OS X.
Инструмент, который позволяет распределять обработку больших массивов данных по кластерам компьютеров с помощью простых моделей программирования.
Популярный пакет программного обеспечения для работы с текстом, создания электронных таблиц, презентаций, графики, баз данных и т.д. Полностью открытый процесс разработки означает, что кто угодно может сообщать об ошибках, запрашивать новые возможности или улучшать программное обеспечение. Он написан в международном open standard формате, поэтому воспринимает файлы из других открытых офисных программных пакетов.
Платформа для управления контентом, на которой работают миллионы веб-сайтов и приложений.
Менеджер для работы с медиаданными, предназначенный для создания больших централизованных медиа-библиотек.
Свободная операционная система типа Unix.
Офисный пакет для совместной разработки с функционалом, как у Microsoft Office или OpenOffice.org.
Система для создания курсов. Бесплатное веб-приложение, которое преподаватели могут использовать для создания эффективных Интернет-сайтов для обучения. Moodle стала очень популярной среди педагогов по всему миру в качестве инструмента для создания динамических веб-сайтов для своих студентов.
ПО для создания и управления обучающим аудио и видео контентом.
Мультиплатформенная система управления корпоративным контентом написанная на Java. Работает с несколькими базами данных (в том числе MySQL, Oracle, PostgreSQL, SQLLite, и другие), а также поддерживает несколько методов аутентификации.
Софт для создания частных и общественных облаков.
Сервис позволяет создавать опросы и делиться с контактами на сайте. Удобный способ собирать данные для их последующего анализа.
DICOM-сервер для здравоохранения и медицинских исследований. Предназначен для облегчения управления данными медицинских изображений. Хороший инструмент для автоматизации медицинских задач визуализации, специфических для каждого медучреждения.
Проект создан силами Open Source сообщества и предназначен для обеспечения лучших решений для предприятий с помощью бизнес аналитики.
Основные области применения:
- создание отчетов
- анализ
- сбор Данных
- платформа бизнес-аналитики
Java™ разработчики могут использовать компоненты проекта для быстрого создания собственных решений для бизнес аналитики.
Модульная open source система управления цифровыми данными.
Бесплатный софт для e-commerce.
Библиотека для быстрого фильтрования и сортировки больших коллекций - до 100000 элементов в браузере.
Языки c open source
Язык программирования с открытым исходным кодом и среда разработки для людей, которые хотят создавать изображения и анимацию.
R - открытый язык программирования и программная среда для статистических расчетов и графики. Язык R широко используется среди статистов для разработки статистического программного обеспечения и анализа данных.
Где найти больше open source проектов?
Один из самых крупных веб-сервисов для совместной разработки IT-проектов. Абсолютно бесплатен для open source проектов. Девиз сервиса “Social coding” можно перевести, как “Кодим вместе”.
Предназначен популяризовать open source проекты. С помощью инструментов, которые там предоставлены, разработчики создали мощное программное обеспечение в более чем 430,000 проектах; на ресурсе более 3,7 млн зарегистрированных пользователей. Популярный каталог объединяет более 41,8 млн клиентов с проектами open source и обслуживает более 4800000 скачиваний в день.
Цель Fossdroid - продвигать open source приложения на Android с помощью проекта F-Droid. Fossdroid берет свои данные из F-Droid и организует приложения в порядке, похожем на Google Play, с возможностью просмотра их по популярности.
Как узнать является ли ПО open source и каковы правила его использования?
Необходимо понимать, что не все open source проекты могут быть использованы в коммерческих целях или свободно модифицированы.Чтобы узнать, является ли ПО open source и каковы правила его использования, нужно посмотреть его лицензию . Обычно полный ее текст находится непосредственно в коде.
