Открытый исходный код: это не так уж и страшно!

Следующее было опубликовано в преддверии запуска стипендий Toptal для женщин-разработчиков.

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

В Toptal у нас недавно было несколько интересных разговоров о том, какой вклад женщины вносят в открытый исходный код и что может мешать им вносить больший вклад, поэтому мы изучили этот вопрос. Поучаствовав в этом разговоре с Бреанденом Бенешоттом и Божидаром Бацовым, я задумался: Божидар — один из ведущих разработчиков открытого исходного кода на GitHub. Где я? Если вы посмотрите мой публичный аккаунт на GitHub на сегодняшний день, это в основном небольшие тестовые проекты, которые я использовал в классе для своих студентов. Они полусырые и определенно не отражают мои навыки или опыт. (В этом вам придется поверить мне на слово.) Если бы кто-то решил нанять меня, основываясь на том, что они могут найти в этом аккаунте, я думаю, мне было бы трудно зарабатывать на жизнь. Тем не менее, я был профессиональным разработчиком более 20 лет, и в своей повседневной работе я использовал больше программного обеспечения с открытым исходным кодом, чем мне хотелось бы помнить. Со временем я взломал ядро ​​​​Linux, чтобы приспособить его к какой-то конкретной потребности, настроил каждый маршрутизатор и NAS, которые я купил, терпеливо ждал несколько месяцев в списке ожидания Raspberry Pi, чтобы получить его в свои руки и получить мою самодельную домашнюю систему. Мне это нравится. Тем не менее, ни одна из этих настроек и тестов так и не попала на мой GitHub, чтобы стать открытым исходным кодом. Кроме того, помимо исправления ошибки в одной из первых версий Tomcat, я никогда не участвовал в проектах с открытым исходным кодом. Любопытно, не так ли?

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

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

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

• В течение вашей карьеры : многие клиенты изучат все ваши социальные сети, прежде чем принять решение нанять вас; ваша учетная запись GitHub и ваше резюме LinkedIn находятся в верхней части списка вместе с вашими профилями Facebook и Twitter. Вы должны использовать их с умом.
• Для ваших технических навыков : изучение кодовой базы, написанной другими разработчиками, часто очень хорошими, многому вас учит. Способность извлечь смысл из плохо написанной кодовой базы вызовет и научит вас не меньшему.
• Для ваших социальных навыков : программное обеспечение с открытым исходным кодом — это совместный процесс, и почти все интересные проекты создаются командами. Научитесь работать с другими разработчиками с помощью инструментов, которые все используют, сливаться с командой, эффективно общаться — вот что сделает вас отличным разработчиком, а не просто опытным.
• Для сообщества : важен каждый ваш вклад в проект с открытым исходным кодом. Чем больше вы сделаете, тем лучше, но даже исправление одной небольшой опечатки в переводе сделает конечный продукт лучше.
• Для вашей сети : вы можете отправить сотни резюме в компании, но ничто не работает так, как коллеги с личными связями. Активное участие в проекте с открытым исходным кодом гарантирует, что вы встретите людей и завоюете их уважение, а ваша репутация будет расти, что неоценимо для любого профессионала.

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

Что такое программное обеспечение с открытым исходным кодом и где его найти?

Программное обеспечение с открытым исходным кодом, или сокращенно OSS, — это любое программное обеспечение, выпущенное с исходным кодом и включающее лицензию, позволяющую изменять и распространять его. Его можно доставить куда угодно: на сайт, через список рассылки или с совой. Самый распространенный сценарий, который нас интересует, — это когда кодовая база поддерживается в совместном репозитории. Здесь мы ориентируемся на GitHub, но есть и другие варианты, такие как SourceForge и Bitbucket. GitHub очень удобен, имеет огромную базу пользователей, может использоваться для любого кода и с любой используемой вами средой разработки. Важно отметить, что он также широко используется для проектов без открытого исходного кода. Скорее всего, ваш следующий клиентский проект будет размещен там, поэтому знание того, как с ним работать, само по себе является полезным навыком.

Что делать, если я не знаю, как кодировать?

Если вы читаете это, вероятно, вы хотите научиться программировать. Вы можете найти отличные курсы на нескольких бесплатных и платных сайтах. Вы должны выбрать один язык для изучения; если у вас нет предпочтений, используйте JavaScript. У вас уже есть все необходимое для работы в веб-браузере, и это один из наиболее широко используемых и востребованных навыков. Мой личный фаворит — Python, который используется как в веб-разработке, так и в научных приложениях. У меня также есть личный любимый курс для начинающих «Введение в информатику» на Udacity. Мне это нравится, потому что это практический курс, где вы работаете над проектом, когда учитесь. Вы также можете найти несколько других курсов на Coursera, Khan Academy и PluralSight.

Что делать, если я не знаю Git?

Как упоминалось ранее, знание Git важно, поэтому пройдите курс по Git. Сделайте это, даже если вы некоторое время работали с Git; вы не узнаете, как много вы не знаете о Git, пока не изучите его по-настоящему. Сделайте это, если вы не можете уверенно объяснить, что делает команда rebase . Делайте это, даже если неправильный ребаз вас не пугает. Я прошел полный курс Git в Code School, но опять же, вы можете изучить другие сайты для получения дополнительных возможностей.

Как выбрать проект на GitHub?

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

Например, быстрый поиск «Raspberry» в поиске GitHub показывает более 17 тысяч репозиториев. Легко заблудиться, поэтому ищите проект с хорошим сообществом и хорошим отслеживанием проблем. При выборе проекта проверяйте количество:

• Авторы . Настройте таргетинг на всех участников, число которых превышает десять. Это должно гарантировать, что проект вызывает достаточный интерес, а не просто усилия небольшой команды. Если вы новичок в OSS или не слишком опытны, ограничьте поиск проектами, в которых участвует не более пятидесяти участников; более крупные сообщества подразумевают более крупные кодовые базы и более сложные проекты.
• Коммиты : выберите проекты, в которых есть не менее тысячи коммитов, а самая последняя активность не старше недели. Проект, который был неактивен в течение месяца или более, является старым и устаревшим с точки зрения OSS, и вы, вероятно, не получите никаких ответов быстро. Ежедневная активность — признак здорового проекта.
• Проблемы : проблемы — это открытые проблемы, ошибки, о которых сообщалось, или запрошенные функции для реализации. Они дадут вам отправную точку и являются хорошим показателем интереса к проекту.

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

Я выбрал ScyllaDB, проект хранения данных по столбцам, так как меня интересуют данные — все, что связано с производительностью. Я никогда не работал с ним, но надеюсь, что смогу погрузиться в его кодовую базу. Может быть проще работать с инструментами, которые я знаю, но я воспринимаю это как вызов и возможность узнать что-то новое. В остальном он идеально подходит; у него 18 участников, 6,5 тыс. коммитов (последнее было 23 часа назад на момент написания), 178 открытых проблем и он выглядит активным.

Что мне теперь делать?

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

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

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

Создание форка

Это может быть тривиально, но на данный момент для проекта ScyllaDB я мисс Никто; было бы рискованно позволять мне вносить изменения в их код без присмотра. Что мне нужно сделать, так это создать «форк» в моей собственной учетной записи GitHub. Вот мой форк ScyllaDB. Это моя собственная игровая площадка, где у меня есть доступ ко всему коду, и я могу изменять файлы по своему усмотрению. Если бы я хотел создать свою собственную версию ScyllaDB и настроить ее так, чтобы она делала что-то совершенно отличное от первоначальной цели, я мог бы сделать это здесь. Создать вилку просто; перейти на главную страницу проекта и нажать кнопку «форк». Совсем не страшно.

Время исправить ошибку

Теперь пришло время протестировать код на вашем компьютере и внести необходимые изменения. Прежде всего, убедитесь, что на вашем компьютере установлен клиент Git. Затем добавьте свой открытый ключ SSH на GitHub и убедитесь, что он загружен вашим ssh-агентом. Получить код локально очень просто; просто используйте команду git clone , которая указывает на вашу ветку, а не на основную ветку:

 git clone [email protected]:acbellini/scylla.git

К настоящему времени вы должны были протестировать проект в основной ветке, поэтому вы собираетесь собрать свой код локально и протестировать его таким же образом. Имейте в виду, что вам придется разветвить любые другие проекты GitHub, на которые опирается ваш проект, поскольку ссылки являются относительными. В моем случае мне пришлось форкнуть seastar, scylla-ami и scylla-swagger-ui.

Ошибка, которую мне нужно исправить, относительно проста; документация в conf/scylla.yaml упоминает три настраиваемых каталога: один для файлов данных, один для журналов коммитов и один, по-видимому, неиспользуемый, для кешей, все они по умолчанию относятся к некоторому подкаталогу $CASSANDRA_HOME :

Погружаясь в код, он показывает, что значения по умолчанию разные, и, как упоминалось в проблеме № 372, с которой я начал, $CASSANDRA_HOME не следует использовать. Я подтверждаю свою гипотезу, тестируя код с несколькими различными настройками, удаляя настройку из файла конфигурации и проверяя, какие каталоги используются. Когда я достаточно уверен, что все правильно, я могу добавить, зафиксировать и отправить измененный файл:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

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

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

На данный момент код исправлен и находится на GitHub, в моем приватном форке. Вот где начинается самое страшное: попросить людей из ScyllaDB принять мой код. Это называется запросом на включение.

Последний шаг: запрос на извлечение

Мне нравится создавать пулл-реквесты прямо из веб-интерфейса на GitHub. Я нахожу это более интуитивным и защищенным от ошибок, чем попытки сделать это из командной строки. Все, что мне нужно сделать, чтобы создать свой запрос на включение, — это нажать маленькую зеленую кнопку рядом с именем моей ветки:

Обратите внимание, что комментарий был автоматически рассчитан GitHub. В моей ветке теперь есть один новый коммит, но с момента создания моего форка в основном репозитории осталось еще 14 коммитов, поэтому я нажму зеленый значок слева.

К счастью, мой единственный коммит не конфликтует с 14 другими, поэтому GitHub сообщает мне, что я готов к работе. Мне не нужно добавлять какие-либо другие комментарии или сообщения. Сообщение коммита, хотя и очень короткое, говорит само за себя: что делает мое изменение кода и с чем оно связано. Когда я нажимаю последнюю кнопку, чтобы подтвердить свой запрос, я задаюсь вопросом, что же это было, что я нашел так страшно всего несколько дней назад. Сейчас на меня не рычит никакой монстр, и адское пламя, кажется, не горит. Честно говоря, было совсем не страшно. В том маловероятном случае, если я ошибся, мое исправление не будет принято, и на этом все.

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

Заключительные заметки

Теперь я жду, когда мой запрос на извлечение будет принят, я получу уведомление, когда это произойдет. Имейте в виду, что это может занять несколько дней, даже недель; кто-то должен просмотреть мой код, протестировать его работу, как описано, устранить проблему и, в конечном счете, убедиться, что это не влияет отрицательно на функциональность остального кода (читай: создает новые ошибки). Все это требует чьего-то времени, так что наберитесь терпения. В конце концов, когда мой запрос на включение будет принят, у ScyllaDB будет на одного участника больше, на одну проблему меньше, и у меня будет мой первый вклад в OSS. Теперь пришло время попробовать и вам. Ведь это совсем не страшно.