Open source проекты

Содержание

Как участвовать в open source проектах

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

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

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

  • https://help.github.com/
  • https://habrahabr.ru/post/275219/

В начале публикация своей работы на 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.

Open source проект на пальцах

Любите ли вы гулять по парку? Возможно не сейчас, потому что уже ноябрь, как говорят «зима близко!». Уверен, в хорошую погоду вы с удовольствием бродите меж деревьев по ухоженным аллеям. Но что, если бы ваш любимый парк забросили муниципальные службы? Очень быстро начался бы беспорядок. Везде валялся бы мусор вперемешку с отходами жизнедеятельности собак в томительном ожидании, что в них кто-нибудь наконец-то вступит. Вряд ли вы бы продолжали ходить туда на прогулки.А теперь представьте более радостную картину: группа добровольцев взяла под свою ответственность содержание своего любимого парка. Она регулярно выделяет средства, чтобы превратить нечто неухоженное и заброшенное во что-то очень красивое и полезное другим людям. И делает это не только ради личного удовольствия, но и к радости общественности. Скорее всего, ваш любимый парк содержат на наши с вами налоги, но в целом приведенная выше ситуация описывает то, как работают open source проекты.

Свободно распространяемое программное обеспечение с открытым исходным кодом (open source) — это приложения, чей код доступен всем. Их можно загрузить и/или использовать на любом количестве устройств. Вы вольны взять код программы и делать с ним всё, что захотите, а затем распространить его среди ваших знакомых. Это так, потому что такие программы распространяются по свободным лицензиям, например, лицензии MIT.

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

Начало и ознакомление

Начало работы в проекте может казаться обманчиво легким, но при этом иметь много подводных камней. Когда вы выбрали задачу для решения, вам нужно развернуть проект на своей машине. Скорее всего, исходники проекта будут «тяжелыми» (хотя это зависит от проекта). Возможно, вам придется установить большое количество зависимостей просто для того что бы запустить проект.В проекте, на который я попал, таких моментов было немного, но это не значит что это было просто. Например, нам пришлось установить специфические версии Ruby и специфические версии Rails, PostgreSQL, Phantom JS и Gemfile с перечнем Gems для инсталляции. Казалось, что это не так уж и много требований, но я столкнулся с большой проблемой с поиском специфической версии Ruby, необходимой для разработки проекта и работающей на моем компьютере. Наконец, я использовал RVM для переключения версий: это еще одна вещь которой я научился, только для того чтобы просто установить проект и заставить его работать на компьютере. Когда же я запустил проект, то увидел, что тот написан на Angular и Coffee Script, с применением Active Record для взаимодействия с данными поступающими из бек-энда. Это были новые для нас вещи, и с ними нужно было разобраться самостоятельно до начала работы над проектом.

Поиск других задач

Возможно, прямо сейчас вам это не нужно, и даже не пригодится в ближайшем будущем, но я столкнулся с этим практически сразу. Огромное везение сразу заметить, что в проекте что-то работает не так. Если вы нашли такой баг, переходите на рабочий сайт и посмотрите так ли это там. Не спешите писать в поддержку, возможно, всё работает. Обычно кураторы контролируют ситуацию и критичных ошибок быть не должно. Но если вы всё-таки обнаружили то, что требует внимания, найдите и проверьте среди задач, которые уже существуют. Скорее всего, проблемная задача уже была записана и скорее всего вам не надо ничего делать. Хотя, возможно, стоит решить ее самостоятельно, когда вы закончите то, над чем работаете.Когда вы оформляете и записываете новую задачу, убедитесь, что вы как можно более подробно описали её. Используйте скриншоты, чтобы наглядно показать, что вы пытаетесь сказать и максимально упростить понимание вопроса постороннему, который заглянет на сайт и увидит описываемую проблему. В моем случае я закончил, добавив две дополнительных задачи, кроме той, что была закреплена за мной. Я даже не смог сделать пул реквест (это было связано с ограничениями безопасности). Мне казалось, что я сделал два шага назад для проекта, но на самом деле описание и оформление задач все равно двигает проект вперед. Создание pull request (PR)

Pull request (пул реквест) — предложение изменения кода в репозитории (хранилище кода проекта). Если вы работаете над открытым проектом, всегда нужно создавать собственную ветку (branch), а вносить изменения в основной код (master) желательно только после подтверждённых кураторами проекта пул реквестов.

Вы решили поставленную перед вами задачу. Прежде, чем писать отчёт о проделанной работе, покажите решение тому, кто сможет его оценить. Предварительный просмотр — отличная идея всегда, но для вашего первого вклада в открытый проект он просто необходим. Вы же не хотите краснеть из-за недоработанного или неправильно работающего куска кода? По этой же причине кураторы проекта предложат вам пройти все необходимые тесты перед пул реквестом. Поэтому проверьте себя загодя, чтобы быть уверенным в своей работе и поправить её в случае необходимости до получения подтверждения от кураторов. Убедитесь, что вы придерживаетесь названий или стилистики, которая принята кураторами проекта. Вы можете найти информацию в файле CONTRIBUTING.md, он есть в большинстве проектов. Также там вы сможете уточнить, в каком виде вы должны создавать commit message, как должно выглядеть описание вашего pull request и как оформить новую задачу.

Покинуть задачу

Иногда понимаете, что не справляетесь со взятой задачей. Или вам казалось, что у вас есть время на проект, но на деле его не оказалось, вам на голову свалилась срочная работа и вам нужно заняться ею. Это в норме вещей. Главное, отпишитесь от задачи и оставьте сообщение кураторам, чтобы они знали, что вы не сможете продолжать заниматься проектом. Но ни в коем случае не бросайте задачу, не сообщив кураторам и не отписавшись от неё.Я считаю, что от участия в разработке открытого проекта — одна сплошная польза. Вы практикуетесь и в тоже время делаете что-то полезное для других людей. С другой стороны, данный проект может стать еще один пунктом в вашем резюме и дать дополнительные плюсы при борьбе за получение желаемой должности. Буквально в прошлую пятницу я общался с программистом, который устроился на свою работу (очень крутую и интересную, такую, которая может изменить мир к лучшему, и я действительно не шучу) именно благодаря его работе над open source проектами.

Что ещё почитать:

Популярно о лямбда-выражениях в Java. С примерами и задачами. Часть 1

Лучшие книги для подготовки к экзамену OCAJP8 (1Z0-808) по Java 8

Что такое открытое проектирование?

Открытое проектирование подразумевает публикацию в публичном доступе информации о процессе работы над каким-либо заданием. Делается это по-разному:

  • Делимся наработками — Некоторые дизайн-проекты (такие как Super Friendly и их redesign of Reading Is Fundamental) выкладывают в открытый доступ скетчи, наброски стилевых решений, шаблоны, прототипы и прочие составляющие определяющие будущий вид проекта.
  • Выкладываем отдельные части — Некоторые открытие проекты представлены лишь превью. Это похоже на трейлер к еще не вышедшему фильму.
  • Делимся историями — Ведущие некоторых открытых проектов делятся историями о процессе подготовки (пример — PSU»s redesign). Они рассказывают как проходит работа, какие техники используются, какие уроки были выучены и какие выводы сделаны.
  • Показываем источник — Один из самых простых способов открыть проект — расшарить ссылку на проект, чтобы те, кому интересно, могли самостоятельно следить за этапами работы.
  • Выкладываем механизмы — Руководители проектов некоторых компаний (таких как The Guardian и NY Times) делятся кодом и использованными инструментами на Github.

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

Преимущества открытого проектирования

Давайте попробуем разобраться зачем же все-таки нужно открытое проектирование?

  • Помощь, подсказки и техники от читателей. Специализированные сообщества — отличная среда для решения проблем. Если в ходе работы над проектом возникает вопрос, читающие вас пользователи вполне могут подсказать дельное решение. В некоторых случаях вы можете получить решение еще даже не возникшей проблемы от более опытного члена сообщества.
  • Сбор мнений. Если вам нужно оценить проделанную вами работу, открытое проектирование может решить этот вопрос. Вы сможете понять насколько удачно сработали по реакции людей, которым открываете проект.
  • Создание сообщества по интересам. Делясь проектами вы можете заранее обзавестись поклонниками как вашей работы, так и осуществляющегося проекта. Хороший пример Indie Game: The Movie. Создатели этого проекта работали над ним открыто. За время работы они приобрели такое количество заинтересованных последователей, что когда проект был окончен и фильм вышел, у продукта уже имелось целое сообщество желающее купить новинку.
  • Позиционирование себя как лидера и новатора. Это может неплохо сказаться на вашей репутации среди потенциальных работодателей. Также вы подаете интересный пример новичкам.
  • Альтруизм и +100 к карме. Еще одно преимущество открытого проектирования по сути является преимуществом для ваших читателей. Ведь вы делитесь своим опытом, который может помочь начинающим специалистам в решение тех или иных вопросов. В любом случае это хорошо скажется на вашей репутации.
  • Удобная форма работы с заказчиком. Подобная форма работы может помочь в общении с заказчиком. Убедитесь только в том, что заказчик адекватный и не будет лезть с «бесценными» советами и подсказками ежеминутно. У клиента есть возможность наблюдать весь процесс и корректировать направление согласно требованиям. Таким образом можно исключить вариант «Ой! Нет! Я вообще не это хотел» после месяца кропотливой работы.
  • Коммуникация и обоснования решений. Работая открыто, когда этапы вашей работы проиллюстрированы, проще обосновать свои решения. Это может быть полезно, когда вы работаете на большую компанию, в которой 100500 псевдо-заинтересованных лиц смертельно обижаются на то, что с ними не посоветовались.
  • Ответственность. Работая открыто вы фактически садитесь за большой стол, где команда помощников и критиков следит за вашим проектом. Теперь вы ответственны не только перед собой, но и перед аудиторией, что добавляет мотивации.

Сложности открытого проектирование

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

  • Чертовски дискомфортно показывать незаконченную работу. Мало кто любит, когда ему смотрят в монитор во время работы. Ощущения во время публикации незаконченного проекта примерно схожи. Неоконченная работа на то и неоконченная — в нее не были внесены все необходимые правки, она еще очень далека от совершенства. Зарисовки смотрятся неряшливо, прототипы глючат и т. д. Для того, чтобы со спокойной душой показать всем черновик, нужно смириться с несовершенством своей работы на данном этапе. А это очень непростая задача, особенно для творческих личностей, которых в дизайне хватает.
  • Комментарии с галерки. Открытое проектирование предполагает взаимодействие с аудиторией. Вы получите отзывы и оценки работы хотите того, или нет. Некоторые мнения будут действительно ценны и полезны, однако часто фидбэк похож на комментарии с YouTube. Вам с командой нужно заранее определить стратегию поведения и решить насколько внимательно вы будете прислушиваться к мнению ваших читателей.
  • «Кто-нибудь украдет мои идеи!» Это одна из самых большим моральных проблем, с которыми сталкивается разработчик, решаясь на открытое проектирование. «Мы что, просто поделимся всем? Нашими идеями? Нашим конкурентным преимуществом ?». От этого параноидального типа мышления нужно избавляться. Также важно убедить клиента, что лучше вашей команды эти идеи все равно никто не воплотит. Повторений и сознательного или неосознанного плагиата все равно не избежать, а открытое проектирование — хороший способ заявить о том, что вы сделали это первыми!
  • Время. Ведение блога, публикация этапов работы и сопровождающего материала отнимают время. Так что решение вести открытый тип работы обязывает вас выделить необходимое время для публикации процесса.

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

Открытые проекты

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

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

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

Нижний уровень управления — совокупность последовательно (так же как и параллельно) выполняемых подпроектов, которые представляют собой обычные терминальные проекты. По завершении определенного подпроекта (подпроектов) или планового периода, охватывающего несколько подпроектов, происходит изменение содержания всего открытого проекта

Нижний уровень управления — совокупность последовательно (так же как и параллельно) выполняемых подпроектов, которые представляют собой обычные терминальные проекты. По завершении определенного подпроекта (подпроектов) или планового периода, охватывающего несколько подпроектов, происходит изменение содержания всего открытого проекта

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

Образно говоря, управление открытым проектом напоминает движение в большом темном пространстве с зажженным прожектором (следует обратить внимание, что слово «прожектор» является этимологически родственным слову «проект»). Сначала направленный свет прожектора освещает некоторый участок пространства. Мы начинаем двигаться по нему в выбранном направлении с учетом того, что видим. Проходя по этому участку, мы постепенно обнаруживаем следующий участок со свойственными ему препятствиями и возможностями. Это вносит определенные коррективы в наше дальнейшее движение. Мы можем обнаружить совершенно новые пути, что повлечет за собой кардинальное изменение целей. Мы можем зайти в тупик, что повлечет за собой возврат и также изменение целей. Если в ходе традиционного терминального проекта мы проецируем проект на плоскость предположительно стабильную, по крайней мере ограниченную содержанием проекта, то в ходе открытого проекта мы проецируем не заданную ограниченную модель, а общие направления, высвечивающие наши возможности по управлению постоянно изменяющейся, динамической предметной областью.

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

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

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

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

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

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

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

  • Использование контейнеров Docker — в предыдущем году, Blcak Duck выбрала технологию Docker в качестве лучшего решения для виртуализации серверов. Экосистема Docker продолжает расширяться, вместе с несколькими проектами, в том числе спонсируемыми Red Hat и Capital One.
  • Рост открытого сотрудничества — Учитывая успех Facebook и Skype для личного обмена сообщениями, было реализовано много подобных решений для офиса. Таких как GoToMeeting или Slack. Теперь запатентованные решения сталкиваются с серьезной конкуренцией со стороны программ с открытым исходным кодом, которые предоставляют те же функции, но полностью открыты.
  • Использование искусственного интеллекта — мы можем быть очень далеко от действительно умных машин, но за глубокими методами обучения, с помощью которых компьютер может научиться путем обработки данных и моделирования нейронных систем, наше будущее.

Mattermost

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

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

React Native

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

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

Hygieia

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

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

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

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 проекта

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

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

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

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

Известно множество примеров, когда люди, даже далекие от профессиональной разработки, вносят вклад в открытое программное обеспечение, получая удовольствие от общения с близкими по духу людьми. Но для новичков, как показывает опрос, проведенный на сайте opensource.com, основным барьером для вхождения в мир открытой разработки программного обеспечения является банальное отсутствие знаний о том, с чего начать.

А начать довольно просто – с поиска проекта, который вам симпатичен.

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

Программы для поддержки студентов

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

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

Google Summer of Code

Google Summer of Code – самая известная глобальная программа, сфокусированная на привлечении молодых программистов в Open Source разработку. В 2018 году студенты могут выбрать один из проектов и подать свои заявки на участие в программе с 12 по 27 марта.

К 23 апреля студентов и менторов связывают в пары для начала планирования проекта. С середины мая до начала августа студенты работают над своим проектом, а в конце августа подводятся результаты. Стипендия зависит от страны проживания и разбита на три платежа: 30%, 30% и 40%. Например, для России сумма сейчас составляет $3600.

С общим планом вы можете ознакомиться на странице расписания. Правила участия в программе приведены на соответствующей странице. Прочитать подробности от участника Google Summer of Code на русском языке можно в серии статей awRabbit.

Другие стипендиальные программы

Кроме Google Summer of Code существует ряд не менее достойных программ поддержки студентов:

  • European Space Agency: Summer of Code in Space (SOCIS) – разработка систем для космоса, анализ данных, обработка изображений, визуализация и т.д. После утверждения проекта студент получает стипендию 1000€, после успешного завершения – еще 3000€. На написание кода дается три летних месяца.
  • OpenDaylight Summer Internship Program – в дополнение к стипендии программа оплачивают перелет в Кремниевую долину на OpenDaylight Event по завершении программы для презентации отчета.
  • The X.Org Endless Vacation of Code (EVoC) – программа, у которой нет дедлайна: вы выбираете проект и описываете что именно готовы делать в течение 3-4 месяцев. Стипендия в $5000 разбита на начальный ($500) и два последующих платежа по $2250, начисляемых после успешного прохождения ключевых точек.
  • Tor Summer of Privacy – очередной виток программы был объявлен в блоге Tor 2 марта. Программа связана с различными идеями относительно развития Tor. У студентов преимущество, но могут участвовать и не студенты. Суммы стипендий аналогичны Google Summer of Code. Подача заявок проходит с 12 по 26 марта, объявление победителей 20 апреля.
  • OWASP Summer Code Sprint – программа, посвященная системам безопасности, более скромная по стипендии (суммарно $1500), но интересная самими проектами.
  • Outreachy Program – программа, нацеленная на привлечение в Open Source людей из социальных групп, слабо представленных в разработке: женщин, трансгендеров и национальных меньшинств без ограничения по возрасту. Размер стипендии $5500 плюс дополнительные $500 в качестве трэвел-гранта. Проекты включают не только программирование, но и User Experience, документирование, иллюстрацию, графический дизайн и Data Science. Дедлайн подачи заявок 22 марта. Для оповещения о датах конкурса подпишитесь .
  • Rails Girls Summer of Code: еще одна программа, нацеленная на привлечение девушек в IT. Здесь также нет ограничений по возрасту и не обязательно быть студенткой. В этом году прием заявок уже закончился, но продолжается краудфандинговая компания.

Программы менторства проектов

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

  • Mozilla Winter Of Security – программа проводилась последний раз в 2016 году.
  • Season of KDE – в этот раз проходит с 10 декабря 2017 по 21 марта 2018, дедлайн подачи был 26 декабря 2017 года.
  • Free Software Foundation Interships – ближайший дедлайн для подачи заявки 27 апреля 2018. Программа проводится три раза в году: весной, летом и осенью и требует отдачи по 20 часов в неделю.

Обратите внимание, что в этих же сообществах вы можете найти проект и наставника вне обозначенных дедлайнов.

Программа для школьников Google Code-In

Из-за сложностей с перечислением денежных средств несовершеннолетним в стипендиальных программах обычно указывается возрастное ограничение: не младше 18 лет. Для подростков 13-17 лет проводится соревнование по открытому программному обеспечению Google Code-In. В результате конкурсов участники получают различные подарки, футболки и сертификаты. Отчеты русскоязычных школьников по этому конкурсу в 2012, 2013 и 2014 годах сподвигли и некоторых взрослых людей заняться Open Source 🙂

3. Ищите и исправляйте ошибки

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

Если вы обнаружили еще не оформленный баг, пишите issue. Если вы сами сумели его исправить, оформляйте pull request и указывайте, что он исправляет определенный issue. Или найдите чужой issue, в котором описывается баг и устраните его в коде. Некоторые проекты требуют, чтобы баг-фиксы сопровождались тестами.

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

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

Если вы работаете с компилируемым проектом и проект компилируется без ошибок, попробуйте разобраться в причинах прочих предупреждений (warnings) – указывают ли эти замечания компилятора на особенности, которые не позволят расширяться проекту далее.

Типичные проблемы новичков

Проблемы, с которыми сталкиваются новички в open source проектах, можно объединить в следующие категории:

  • Неуверенность в собственных силах. Код в Open Source проектах пишут в большинстве своем не гении разработки, а такие же программисты, как вы. И даже у них есть ошибки и просто опечатки. Нужно понимать, что крупным проектам требуются разработчики разного уровня подготовки, навыков и опыта. Открытость никак не гарантирует качества кода и часто даже неопытный новичок лучше, чем отсутствие специалиста.
  • Пугающая величина проекта. Да, проекты могут состоять из сотен и тысяч файлов, миллионов строк кода. Но никто не читает все эти файлы подряд. Чаще всего есть какая-то проблема, которая становится для вас точкой входа в проект – вы постепенно «разматываете» код от этого отправного пункта.
  • Боязнь задавать вопросы и раздражить сообщество своим непониманием. Если вы будете кого-то раздражать, вам скорее всего на это мягко намекнут, в этом нет ничего страшного. Такое происходит крайне редко, так что нужно постараться – многие проекты живут исключительно за счет энтузиазма создателей, и хорошие пулл-реквесты подстегивают их к продолжению работы.
  • Попытки решить множество проблем ондим пулл-реквестом. Обычное правило: один баг – один pull request, одна фича – один pull request. Так тем, кто получает ваши исправления гораздо проще их принимать или отклонять и аргументировать решение.
  • Вопросы сразу лично авторам проекта. Получить ответ гораздо быстрее из чата или мейлинг-листа, так как его одновременно читает множество людей.
  • Вы безоговорочно соглашаетесь с тем, что вам говорят ревьюеры. Ревьюер может быть тоже не прав. Старайтесь аргументировать свою позицию, если вы считаете ее правильной. Это очень полезный навык для того, чтобы работать в команде. Обратная сторона – умейте принять позицию, если вы действительно не првы.
  • Вы сдаетесь. Спокойствие, только спокойствие. Даже об этом вы можете написать в сообщество. Что где-то застряли и не знаете как дальше продвинуться. С этой ситуацией сталкивался любой, и кто-то обязательно даст совет по вашей проблеме.

Как это поможет в работе/карьере

Разработка открытого программного обеспечения повлияла на карьеру многих разработчиков. Мы объединили отзывы разработчиков о работе в Open Source проектах относительно основной работы в следующие пункты:

  • Весомая строчка в резюме и опыт. В хорошем крупном проекте есть все, что обычно требуется от разработчика на собеседовании: грамотное проектирование, хорошее кодирование, навыки работы с системой контроля версий и баг-трекером, peer review, работа в команде и т.д. За два-три года непрерывной работы в такой атмосфере можно вырасти до уровня, соответствующего позиции Senior Developer. Такой опыт может оказаться эквивалентен соответствующей строчке в трудовой книжке.
  • Портфолио и набор программных решений. Вашу компетенцию становится легко оценить по профилю на GitHub. Всегда есть что показать и легко пройти первый этап собеседования при приеме на работу. Кроме того, есть шанс, что работодатель найдет вас по коммитам или профилю на Github. Зарубежом это становится все более распространенной практикой.
  • Репутация и востребованность. Если компания использует развиваемый вами открытый продукт в своем технологическом стеке, вы становитесь идеальным кандидатом на место соответствующего разработки. Кроме того в Open Source проектах вы можете пересечься с другими специалистами, которые предложат вам место в своей компании.
  • Самостоятельность. Можно не ждать выхода новой версии библиотеки, а исправить баг самостоятельно.
  • Стажировки в мировых компаниях.

Как это поможет в учебе

Вернемся к студенческому вопросу. Что дают занятия открытым программным обеспечением студенты?

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

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

  • Стипендия по постановлению Правительства РФ #945.
  • Стипендия Президента РФ.
  • Стипендия Правительства Москвы.
  • Стипендия фонда Владимира Потанина.
  • Стипендия Аниты Борг.
  • Другие конкурсы гранты.

Варианты развития

В дополнение к спонсорству возможны следующие варианты заработка для дальнейшей работы в Open Source:

  • Собственный бизнес. Сделайте проект, на основе технологии которого можно построить бизнес. Например, вы создаете бинарники для конечных пользователей. К технологии будет испытываться большее доверие в силу свободности кода –можно проверить проект на отсутствие закладок. Кроме того, вы можете создать более крупный программный продукт, который может применяться многими, и на собственном примере вы можете показать другим как работает проект и привлечь контрибьюторов.
  • Платная поддержка. Одна из самых популярных моделей: вы разрабатываете открытый код, но предоставляете клиентам платную поддержку своего решения. Таким образом, например, поступает Linux Red Hat.
  • Разработка на заказ. Фактически аутсорсинг для других фирм и платные доработки под нужды заказчика. Пример: компания Chronicle Software кроме свободных проектов Crhonicle выполняет заказы по разработке систем с использованием этих проектов.
  • Обучение клиентов. Проводите обучающие платные тренинги, на которых вы учите клиентов как использовать ваш продукт. Таким образом, вы одновременно продвигаете проект и зарабатываете деньги.
  • Двойное лицензирование. Лицензируйте свой проект двумя лицензиями. Например, бесплатной лицензией для одиночных пользователей и образовательных учреждений и платной лицензией для коммерческого применения. Примером является система виртуальной роботехники V-REP.
  • Платные вспомогательные сервисы. Стратегия, близкая к предыдущей, но более гибкая: зарабатывайте не на самом проекте, а на предоставлении платных вспомогательных сервисов, таких как хостинг, сервис резервного копирования или мониторинга.
  • Сбор пожертвований. Не самый популярный подход в Open Source проектах, примером может служить Linux Mint и ReactOS.
  • Краудфандинговые компании. Последний подход, совмещающий первый и предпоследний пункты данного списка заключается в целенаправленном сборе средств на создание продукта в ограниченные сроки. Такие компании регулярно объявляются на Kickstarter и c переменным успехом набирают необходимую сумму. Один из успешных примеров – клиент для MySQL mycli.

Как раскрутить свой Open Source проект

Для того, чтобы представить свой проект общественности, нужно начать с довольно простых вещей:

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

Когда вы посчитаете, что проект уже выглядит достойно, проведите рекламную кампанию: добавьте ссылки на проект в Reddit (в ветку reddit.com/r/{язык вашего проекта}), Hacker News, в профильных группах и форумах. Если ожидается, что проект станет достаточно крупным, заведите для него свой твиттер-аккаунт, в который будете выкладывать новости по работе над проектом и попробуйте его разрекламировать, попросив кого-то из близких по духу известных разработчиков.

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