Семь аспектов, как Github изменил мир Open Source

http://honza.ca/2011/03/7-ways-github-has-changed-the-open-source-world/
  • Перевод
Как известно, мир Open Source быстро меняется. Мы постоянно отслеживаем всё новое, пытаемся не отстать. Я уверен, что проект Github оказал сильное влияние и сделал Open Source более понятным и общедоступным. Каким образом?

Заставил разработчиков писать хороший README

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

Единое место для всех ваших проектов

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

Обсуждение кода

Конечно, вы можете обсуждать проект на IRC-канале или в почтовом листе рассылки. Но такие способы не совсем удобны, да и сам код обсуждать довольно тяжело. Github позволяет легко отправить запрос на пулл и посмотреть комментарии к коду.

Простая публикация своих хаков

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

Оценка активности проектов

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

Обнаружение новых проектов

Умные люди постоянно выпускают интересные вещи. Если они публикуют свой код на Github, то вы можете найти его в разделе Обзор Github. Я не могу даже посчитать, сколько интересных проектов я нашёл таким образом. Мой любимый пример — CoffeeScript.

Отслеживание развития любимых проектов

Сразу после логина на сайте вы видите список изменений, сделанных в проектах, за которыми вы следите. У этого новый релиз, у этого исправлен баг и т.д. Бесценно.

P.S. Добавим, что при приёме на работу Github-профиль разработчика зачастую говорит больше, чем его официальное резюме.
Поделиться публикацией
Комментарии 42
    +2
    P.S. Добавим, что при приёме на работу Github-профиль разработчика зачастую говорит больше, чем его официальное резюме.

    Интересно, а как с этим дела обстоят у нас? Кто-нибудь давал ссылку на свой гитхаб-профиль в резюме? Помогло?
      +52
      не, у нас до сих пор все в лаптях ходют
        +3
        Когда размещали вакансию, просили указать. Если в github кандидата было что-то адекватное, то было плюсом на собеседовании.
          +2
          Наши пока требуют готовые проекты. И для веб-программистов такими пока являются готовые сайты. Чтобы можно было «посмотреть и потыкать». Но в целом, добавление ссылки на Гитхаб только улучшит (но не заменит) имидж программиста.
            +6
            У нас один из программистов, когда заполнял анкету (у нас даже есть вопрос про это), написал.

            Вон, сидит напротив и программирует.

            Помогло, значит.
              +9
              Часто спрашивают на собеседованиях «Есть ли OpenSource проекты (GitHub, Google Code)? Помогаете ли вы развивать чужие проекты: пишете код, фидбэки, репортите баги?». Помощь в OpenSource большой плюс — значит человек разбирается в чужом коде и в тонкостях библиотек (jQuery например) и стремится к развитию.
                0
                А ответ «нет» может быть минусом, интересно? Ведь можно разбираться в чужом коде и тонкостях библиотек/фреймворков/систем без коммитов и репортов. Я, скажем, как та собака — всё (почти) понимаю по-английски, но сказать ничего не могу :)
                  +2
                  Может, особенно если работа хотя бы косвенно касается опенсорса. Основная причина — если человек с этим работает, и ничего не делает, значит он и не умеет особо работать. С программистами на глухой проприентарщине (а-ля asp) — другое дело, там и проектов-то опенсорсных толком нет, и у бизнеса модель другая.
                    0
                    Но ведь не выкладывать код в паблик != ничего не делать. Простейшая ситуация — делаю наследника класса фреймворка или библиотеки с нужными мне фичами, реализую какой-то интерфейс своим образом, но кажется, что фича настолько уникальна, что даром никому не нужна, например, хранилище данных на плоских файлах, вряд ли ещё кому попадётся заказчик, который настаивает на бесплатных хостингах без мускула :)
                      0
                      Но вообще спасибо за инфу, никогда не задумывался что может. Буду теперь выкладывать не думая, нужно это кому или нет.
                +5
                Меня спрашивали или я участвую в открытых проектах и просили ссылки на гитхаб и битбакет.
                +24
                Меня Ализар поразил.
                Это первая статья без подоплеки не недоговорок.

                Плохо, что в ИТ нет премии аля Нобеля.
                За гитхаб было бы не стыдно.
                +3
                А мне нравиться их раздел справки help.github.com. Рекомендую, как хорошее руководство по Git.
                  +2
                  А я обожаю вот эту их страницу github.com/404. По-моему шедевр.
                    0
                    Парсер лох и включил точку в урл. А по тому урлу совсем не та страница, что вы имели в виду. Долго думал, за что ж вы её обожаете, так и не придумал :)
                      0
                      Я именно её и обожаю, парсер я проверил предпросмотром, но точка на конце ничего не меняет.
                      Да, страница, выдаваемая по статусу 404 — шедевр.
                        0
                        У меня по ссылке с точкой в конце 500, а не 404 :)
                  +9
                  На мой взгляд, гитхабу не хватает полноценной системы багтрекинга (как на bitbucket). Приходится пока что для этого костыли типа google code использовать.
                    0
                    Чем вам это не багтрэкер?
                      +3
                      В нем невозможно найти баг, отправленный тобой.
                        0
                        account -> public activity?
                          0
                          У публичной активности нет архива: cтарый issue не найти.
                        +2
                        Плохо индексируется гуглом, поиск работает довольно плохо. Инструмент нуждается в доработке.
                          +3
                          Баги нельзя назначать. Статусов только два — открыт/закрыт. В общем, это не багтрекер, это список багов, не более.
                            0
                            Фишка GitHub это облегчить общение и доступ к коду проектов для разработчиков. По этому он и называет себя «Social Coding». Думаю они и не стремятся к мощной системе багтрекера. Направление в другом движется проект. Если не нравится трекер, отключай и пользуйся внешним и никаких проблем) По моему правильное решение.
                              +2
                              Неудобно это. Там есть зачатки интеграции с багтрекером, и если бы это был полноценный бактрекинг, было бы вообще шикарно. А интеграция заключается в том, что если в коммите есть слова типа «Fixes #123» Или «Closes #312», то система отмечает баг как пофикшенный и добавляет к нему ссылку на коммит.

                              Так что нормальный багтрекер всё же нужен.
                                0
                                Посмотрел у крупных проектах на GitHub пользуют внешние трэкеры… Не знаю, не могу сказать большим недугом все равно. За систему форков и пулов, простим я думаю)
                        –2
                        > Простая публикация своих хаков
                        Спорно — вместо присоединения к проекту плодятся десятки клонов, о которых не знает никто кроме их автора…
                          +4
                          Pull requests, anybody?
                            –2
                            Мне это тоже кажется спорным. Когда много клонов, в них что-то и есть полезное, наверное, но не каждый же перебирать и смотреть, а что тут интересного. Ветки в меркуриале как-то приятнее выглядят.
                              +3
                              клоны — это не «готовые продукты», это попытки развивать какую-то фичу. Даже если она не используется в продакте, она может стать полигоном для отладки идеи или проверке возможности. И оно не сгинет где-то в потрохах домашнего клона репозитория.
                                –1
                                Я не к тому что клоны это плохо. Ситуация мне видится следующим образом — вместо того, чтобы создать запрос и прислать патч к проекту, создается клон который допиливается автором до нужного ему (автору) состояния и где-то используется, а в дальнейшем просто забрасывается. Понятно, что разработчики оригинального проекта могут ничего не знают о тех новых фичах которые есть в клоне. Проходит время оригинальный проект развивается, а клон так и остается в том состоянии в котором оставил его автор — разница только в том, что оно сгинет не «где-то в потрохах домашнего клона репозитория», а в потрохах гитхаба.

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

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

                                (за кадром — есть ли доверие к Васиному коду? Почему тогда он не включен в проект? ...)
                                  0
                                  я вижу словосочетание «pull request» вас не заинтересовало, дам ссылку — help.github.com/pull-requests/
                                  вкратце, это и есть «запостить патч»
                                    +3
                                    Вы плохо разобрались в Гите. Это отличный инструмент. И форки — это тоже отлично. Ты можешь реализовать серьёзную функциональность и бросить её автору проекта. К примеру, я форкнул одну игрушку и полностью перевёл фронтенд с SVG на Canvas, потом сделал пул-реквест. Там было много коммитов, в отдельной ветке, а потом мы просто слили эти проекты.

                                    Или, к примеру, я хотел воспользоваться Packager, но мне не очень понравилось, что в нём надо указывать список файлов. А сам проект уже не поддерживается. Среди пул-реквестов я быстро нашёл форк товарища slik и, в итоге, я все, кому я рекомендовал этот продукт — пользовались его версией. И если автор вдруг образумится и вернётся к разработке, то он просто смерджит свою ветку и ветку slik'a

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

                                    Но самое главное, что форки — это не отдельные проекты, а просто ответвления одного и того же.
                                      0
                                      > Вы плохо разобрались в Гите.

                                      Да, возможно, пользуюсь я им не очень часто. Но еще раз повторюсь — я не против клонов/фоков и очень рад если они в конечном итоге позволяют сделать проект лучше.

                                      Но вы же не будете отрицать того, что не все будут слать пул-реквесты? Возьмем, например, первый попавшийся проект:rails, форков — 1347, запросов — всего 199 (скорее всего я их не все нашел? + часть, возможно, были слиты без запросов). Более тысячи форков не влились и скорее всего не вольются в основной проект — тогда какая разница в том где они: на гитхабе или в локальной копии?

                                      Посмотрите с другой стороны — если вы хотите чтобы ваш патч был принят вам придется придерживаться принятых в проекте стандартов кодирования и т.д. — т.о. патч предполагает гораздо большую ответственность. Форк же позволяются просто реализовать то что нужно здесь и сейчас — кому кроме авторов нужны подобные поделки? Никому. И именно поэтому я считаю, что их не должно быть — хочешь что-то по быстрому сделать — сделай, но в своей локальной копии. не нужно выкладывать это в паблик, бессмысленно. Если же, действительно хочешь помочь проекту — сделай нормально и создай запрос (патч ли это будет или пул-реквест не слишком важно. впрочем последнее, возможно, поудобнее).
                                        +1
                                        Большинство форков не имеют ни одного коммита. Не знаю, зачем, но люди так делают. Это не недостаток технологии. При этом, делают подобное очень много людей.
                                        Ещё бывает, что форкаешь, хочешь поправить баг или внести патч, но видишь, что не осилишь, или резко пропало время. У людей после этого форк остаётся.
                                        Это не значит, что это плохой инструмент. Просто не надо смотреть на «Форк» в том смысле, в котором приняли видеть его в других технологиях. Это просто «своя ветка» для каждого человека.
                                          0
                                          А я и не говорил о том, что форки это недостаток или что это плохо — только о том, что это спорный момент (причины почему я так считаю — выше). Функционал удобный, но в некоторых случаях просто ненужный (форки без коммитов).
                                +11
                                Эти семь пунктов с некоторыми оговорками справедливы и для Google Code и для sourceforge.net
                                  +10
                                  У меня была идея предложить писать все дипломы наши кафедральные на github или другом подобном сервисе, кому что религия позволяет.
                                  Диплом то программиский и открытость и контроль научнику, и обсуждение если проект дельный и вдруг кто патч предложит, если кто-то форкнет. Но идея не вызвала бурного обсуждения. А могло бы быть интересно
                                    +1
                                    Не забывайте, что github умеет хостить также html странички вашего проекта. pages.github.com/

                                    Вот пример проекта который хостится на github jashkenas.github.com/coffee-script/

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое