Девять ступеней Open Source кунг-фу | НЕЙМАРК

Таймкоды видео

Девять ступеней Open Source кунг-фу | НЕЙМАРК

00:00 Введение в доклад

  • Доклад называется “Девять ступеней open-source кунг-фу”.
  • Егор Бугаенко, директор лаборатории создания инструментов ПО, будет рассказывать.
  • Обсуждение страха программистов перед open-source и публичностью.

01:00 Пример токсичности в open-source

  • Пример имейла Линуса Торвальдса, где он критикует контрибьютора.
  • Исследование показывает, что 67% имейлов в open-source токсичны.
  • Егор предупреждает о токсичности и призывает подумать дважды перед участием.

02:58 Уровень 1: Создание GitHub-аккаунта

  • Создание GitHub-аккаунта важно, но не все аккаунты одинаково полезны.
  • Исследование показывает, что красивый аватар и оформление аккаунта привлекают внимание.
  • Пример успешного аккаунта, который должен быть у каждого.

03:58 Уровень 2: Отправка pull request

  • Только треть pull request в ядро Linux мерджится.
  • Важно быть готовым к rejection и учитывать, что 85% комментариев касаются оформления кода.
  • Google исследования показывают, что меньшие pull request мерджится быстрее.

07:53 Уровень 3: Позитивное общение и репутация

  • Позитивное общение в pull request увеличивает шансы на успех.
  • Репутация на GitHub важнее, чем качество кода.
  • Важно уделять внимание своему профилю и презентации на GitHub.

09:52 Уровень 4: Создание релиза

  • Создание релиза публичного пакета в open-source.
  • Большинство участников уже делали релизы, но это важный уровень.
  • Важно иметь код и готовность к релизу.

10:51 Упаковка и публикация кода

  • Упакуйте код и выложите его в неизменяемый репозиторий.
  • Maven-централ для Java не мутабелен, что делает его предпочтительным.
  • Важно обеспечить неудаляемость продукта, чтобы избежать удаления.

11:51 Настройка процессов релиза

  • Сделайте процесс релиза простым и регулярным, как стрижка в парикмахерской.
  • Настройте автоматические механизмы упаковки и публикации в публичный репозиторий.
  • Используйте книги для формализации процессов Continuous Deployment и Continuous Integration.

12:42 Уровень Open Source Kung-Fu

  • Придумайте следующую версию и нажмите кнопку для публикации.
  • Если процесс релиза автоматизирован, вы на третьем уровне Open Source Kung-Fu.

13:34 Получение Pull Request

  • Получение Pull Request от неизвестного человека — важный момент для программиста.
  • Оформление репозитория должно показывать, что вы заботитесь о нем.
  • Исследования показывают, что оформленные и документированные репозитории привлекают больше контрибьюторов.

15:23 Оформление и бэджи

  • Оформляйте репозиторий так, чтобы он выглядел профессионально.
  • Наличие бэджиков, таких как Continuous Integration, повышает доверие к репозиторию.
  • Частота обновлений README и количество ссылок коррелируют с популярностью репозитория.

17:17 Захват репозитория

  • Получение Pull Request от технически более грамотных людей улучшает продукт.
  • Пример: библиотека на Rust, улучшенная другим разработчиком, стала более качественной.
  • Важно создать репозиторий, который другие люди захотят захватить и улучшить.

20:13 Уровень 6: Качество продукта

  • Получение большого количества багов является показателем качества продукта.
  • Исправленные баги делают продукт действительно качественным.
  • Дефекты являются ингредиентом качества, и их наличие — признак хорошего продукта.

21:13 Art of Software Testing

  • Книга “Art of Software Testing” написана в 1979 году.
  • Утверждает, что количество дефектов в программном продукте неизмеримо велико.
  • Важно находить дефекты до пользователей, чтобы улучшить качество продукта.

22:11 Баги и качество продукта

  • Баги включают предложения по улучшению продукта, фичи и отсутствие документации.
  • Чем больше багов в бэклоге, тем лучше.
  • Примеры: Mozilla имеет 1,8 миллиона багов, TensorFlow – 36 тысяч.

23:10 Поддержка от крупных компаний

  • GitHub предложил автору репозитория деньги за поддержку продукта.
  • Это возможно, если продукт нужен большой компании.
  • Автор мог бы бросить основную работу и заниматься только open source.

25:06 Large runners от GitHub

  • GitHub предлагает бесплатные ресурсы для крупных проектов.
  • Пример: Александр Медведников, автор языка программирования V, получил оборудование для тестирования.
  • Это требует таланта и удачи.

27:04 Спонсоры на GitHub

  • Спонсоры на GitHub могут приносить значительные доходы.
  • Пример: программист, создавший LiveWire и AlpineJS, получает 112 тысяч долларов в год от спонсоров.
  • Open source может быть источником дохода, а не только хобби.

29:01 Заключение и вопросы

  • Автор предлагает подписаться на его телеграм-канал и курс лекций.
  • Вопрос о перспективах краудфандинга в текущих реалиях.
  • Рекомендация открыть американский счет для получения спонсорских средств.

Таймкоды сделаны Яндекс Браузером https://browser.yandex.ru/

Расшифровка видео

0:00
Наш следующий доклад с очень таким интригующим названием “Девять ступеней open-source кунг-фу”
0:06
Вот так он называется И рассказывать про это будет директор лаборатории создания инструментов ПО, основатель Zeroсrasy
0:14
Егор Бугаенко Встречайте, пожалуйста, Егора На нашей импровизированной сцене
0:20
Микрофончик, кликер и слушаем Скажите, что
О 9-ти уровнях Open Source кунг-фу
0:27
Есть в open-source в большом количестве Чего нет в обычной разработке И чего многие боятся
0:34
Как вам кажется? Публичность, еще варианты
0:41
Чего боятся программисты, идя в open-source? Почему не все там? Коммуникации? Ближе?
0:48
Что там есть такого, чего мы боимся? Критика, а еще пожестче Как это можно назвать?
0:55
Хейт Начнем мой доклад вот с этого имейла 2012 год Линус Торвальдс
1:01
Внизу последняя фраза Пишет письмо одному из контрибьюторов в Linux ядро
1:07
Контрибьютор справа, Линус слева Контрибьютор комментирует
1:14
Это важный контрибьютор в Linux ядро Он предлагает что-то изменить
1:20
И получает вот такой ответ Видимо, это продолжение какого-то конверсейшна Тем не менее, это публичное общение, которое присутствует
1:27
Ну, я думаю, часто этот имейл цитируют В настоящий момент, это было более 10 лет назад
1:34
В настоящий момент этот контрибьютор Работает в Дюссельдорфском офисе компании Huawei
1:40
И этот хейт – это не единичный случай Вот пример исследования, которое было совсем недавно проведено
1:51
Отмечается, что в большинстве, в 67% имейлов Которые присутствуют в open-source коммуникациях
1:59
Берется для исследования тот самый mailing-list ядра Linux Огромное количество хейта, огромное количество токсичности
2:08
Огромное количество негатива Я начинаю свой доклад о 9 уровнях open-source
2:14
Которые вы можете как программисты достичь Но перед этим предупреждаю вас, с чем вы столкнетесь
2:20
И призываю подумать дважды Хотите ли вы этого, хотите ли вы эту токсичность, этот негатив на себе испытать лично
2:28
Если готовы, то давайте пройдем через эти 9 уровней Я могу сказать, что прошел, наверное, через 6 из них
2:34
Может быть, немножко через 7 8 и 9 для меня пока недоступны Может быть, для кого-то из вас
2:40
Я уверен, что они для вас тоже, для присутствующих здесь пока недоступны Но может быть, кто-то из них до них доберется
2:47
Призываю попробовать, начнем с уровня номер 1 На уровне номер 1 вы создаете свой GitHub-эккаунт
1 уровень
2:55
Задача несложная, однако, я думаю, если сейчас я спрошу У скольких из вас GitHub-эккаунта нет вообще
3:01
Я думаю, кто-то поднимет рукой Скажите, у кого его нет, только честно
3:07
Дайте я посмотрю Один, спасибо за поднятую руку Я думаю, что кое-кто, может быть, слукавил
3:13
У вас наверняка есть аккаунты Однако аккаунт аккаунту рознь. Есть аккаунты, которые не стыдно показать работодателям
3:21
Как было отмечено несколькими докладами ранее А есть аккаунты, которые просто созданы для того, чтобы читать чужой код
3:28
Я вам покажу короткое исследование, где сказано Интересно, что то, как вы свой аватар представите на аккаунте
3:39
И чем больше он будет похож на человека Более того, чем больше гендерных признаков будет у вашего аватара
3:45
Тем с большим интересом будут на него смотреть пользователи Это исследование, может быть, больше юмористический оттенок здесь носит
3:52
Но тем не менее, нам важно, чтобы аккаунт был оформлен красиво На нем должна быть красивая аватарка
3:58
На нем должны быть красивые значки и так далее Я вам приведу для примера один аккаунт Который, мне кажется, вполне себе может служить таким эталоном
4:07
Или образцом для подражания Но, я вам рекомендую, что на этом аккаунте есть все, что должно быть
4:13
И красивый аватар, и много картинок, и большое количество контрибьюшена На первом уровне у вас должен быть такой аккаунт
4:21
Если у вас нет такой аккаунта, вы по-прежнему первый уровень не прошли Идем дальше
2 уровень
4:27
Второй уровень Ваш pull request кто-то смерджит
4:33
У кого получилось до этого уровня дойти? Вы куда-то прислали pull request в какой-то чужой репозиторий и его смерджили
4:41
Человек 10, может быть, чуть больше Это второй уровень, это важный уровень Я вам расскажу, как до него добраться
4:48
Я вам буду давать советы вплоть до шестого уровня Дальше следующие три, я не знаю, как до них добраться Просто расскажу о тех, кто добрался
4:56
Итак, посмотрим, что же нам сделать Во-первых, надо понимать, опять же, исследование
5:02
что только треть pull request, которые присылаются в ядро Линукса, мерджатся
5:08
Остальные две трети выбрасываются Вы должны быть к этому готовы Огромный rejection rate, а это люди, которые понимают, что они делают
5:17
которые присылают в ядро Линукса Это не случайные люди, это не мы с вами в основном Это весьма квалифицированные разработчики, которые понимают, какие изменения они пытаются внести
5:31
и тем не менее их rejected Будьте готовы к rejection, это первый залог успеха
5:37
Быть готовым к тому, что два из трех ваших pull request будут rejected А скорее всего первые два, а может быть первые двадцать
5:45
А вот следующие десять, их уже будут мерджить
5:52
Дальше интересный факт, опять исследование Говорят, точнее доказывают, что негативные комментарии, которые вы будете получать при представлении своих pull request
6:04
только в 15% случаев будут касаться собственно тех изменений, которые вы сделали
6:10
А 85% комментариев будут о том, как вы оформили свой код
6:16
Людям не нравится, как вы пишите, а не то, что вы пишите И это статистическая информация
6:22
То есть пишите красиво, чем красивее, чем нагляднее, чем привлекательнее вы оформите свои изменения, тем выше шансы на успех
6:32
Нам не так важно, какой вы функционал сделаете, как нам важно, что вы будете соблюдать те нормы и правила красоты, которые у нас в проекте присутствуют
6:45
Учитывайте это Следующий очень важный момент – это фирма Google нам рассказывает о своем опыте pull request
6:55
Такой очень знаковый ресерч был опубликован лет несколько назад, лет шесть назад
7:02
Они говорят, и они это доказали, что pull request меньшего размера мерджатся интенсивнее, быстрее, удобнее, с большим энтузиазмом
7:13
Размер определяет практически все В предыдущем слайде я сказал, что влияет качель, влияет красота вашего кода
7:21
Здесь мы видим, что размер – это очень важно Чем меньше ваши pull request, тем больше шансов на успех
7:28
Не присылайте много кода Не думайте, что этим вы их впечатлите Не думайте, что им нужно много
7:35
Им не нужно, им нужно поменьше Потому что так удобнее сделать ревью, удобнее принять ваши изменения
7:45
Ну и последний, из второго уровня Google – это опять нам сообщает Google
7:53
Google считает, что… В общем-то подтверждающие предыдущие исследования, просто оно более позднее, 2020 год
8:01
Они снова говорят о том, что размер каждого pull request определяет в основном его успешность или неуспешность
8:08
Вот второй уровень, для того чтобы вам на нем оказаться и ваши pull requests мержились Обратите внимание на красоту и на размер
8:16
Да, ну и последнее, еще одно исследование в этой же области
8:23
Переведу на русский Чем более радостно, чем более воодушевленно, чем более позитивно вы общаетесь в pull request со своими ревьюерами
8:37
Тем больше шансов на успех Ну я думаю это очевидно, но исследователи подтверждают это цифрами, статистикой, можно почитать статью
8:46
И они сравнивают количество позитивных слов и негативных в pull request
8:53
И видят, что мержится быстрее то, где автор настроен позитивно Видимо, зная, что его будут реджектить, он тем не менее настроен позитивно
9:01
То есть, чтобы пройти этот уровень, вам нужно… Еще одно исследование, тут их больше всего в этом уровне
9:09
Да, вот еще интересно, последнее Что здесь говорится?
9:16
Не так важно, что вы прислали, как важно, кто прислал То есть репутация вас, как open source девелопера, то есть тот самый ваш профайл на гитхабе
9:27
Оказывает наибольшее влияние или большое влияние на то, что вы прислали
9:33
То есть дефекты, которые находит даже статический анализатор в вашем коде Не так важно их присутствие, как ваша репутация на гитхабе
9:41
Они смотрят, кто пишет код Они смотрят, куда вы уже писали раньше Они смотрят, есть ли у вас аватар, помните первый уровень
9:49
Они смотрят, кто вы, как вы оформлены И чем больше человек, я как ревьюер тоже могу это подтвердить
9:55
Чем больше человек внимания уделил своей персоне и своей презентации на гитхабе
10:01
Тем с большим воодушевлением, с большим энтузиазмом я отнесусь к его pull request
10:07
Мне кажется, что он заслуживает большего внимания То есть не будьте никем от no-names получать pull request и никому не интересно
10:16
Они идут в корзину зачастую А если вы кто-то, и у вас есть картиночка, и написано, где вы работаете И вы уже что-то сделали, и у вас есть все эти значки и красивые медальки
10:26
То, конечно, мы посмотрим ваш pull request Переходим на третий уровень На третьем уровне вы сделали релиз
3 уровень
10:35
Кто из вас когда-либо делал релизы публичных пакетов в open-source? Раз, два, три, четыре, но больше десяти человек
10:43
Прекрасно Все остальные приглашаются на этот уровень Что это значит? Вы написали какой-то код в вашем гитхаб или не в гитхаб-аккаунте
10:51
Дальше нужно запаковать, дать версию этому коду и выложить в какой-то неизменяемый репозиторий
10:57
Куда-то, где его уже вы удалить не сможете Ну, в основном они неизменяемые, хотя есть некоторые, которые разрешают удалять
11:05
Это, мне кажется, позор open-source community, что у нас присутствуют такие мутабельные хранилища
11:11
Но, допустим, Maven-централ для Java, он не мутабельный, за это мы его очень любим
11:17
Вы должны постараться выложить, чтобы обеспечить неудаляемость вашего продукта
11:24
Потому что на гитхаб-аккаунте вы можете его удалить И тут я вам покажу две книги, не исследования, а две книги, прекрасные книги, которые очень рекомендую
11:32
В первом из них говорится, в первой книге Релиз должен быть настолько же простой и настолько же регулярной процедурой, как постричься в парикмахерской
11:45
Имеется в виду, что вы должны так настроить свои процессы релиза, так настроить свои скрипты
11:51
Так настроить свои автоматические механизмы упаковки вашего продукта и диплоймента его в публичный репозиторий
11:59
Чтобы это было суперлегко, суперудобно и рутинно Самое важное, это должна быть рутинная операция
12:05
Не спонтанная, не иногда, не тогда, когда есть настроение, а по расписанию, как haircut у некоторых
12:12
Ну и второе, это вообще фундаментальная книга, Continuous Integration, никто ее читал
12:19
Все читали, да, поэтому никто не поднимает руки
12:25
Но очень рекомендую эту книгу, нужно прочитать как минимум один раз Это книга, с которой, как я понимаю, началась такая формальная формализация процессов Continuous Deployment и Continuous Integration
12:37
До этого у нас были просто мысли о том, что должен быть Continuous Integration И были какие-то круиз-контролы, Дженкинсы, Хадсоны и прочие системы, которые были без особой, без фундаментальной, может быть не совсем научной, но формализации книжной
12:54
Вот эта книга подвела некую черту и предложила, как основной тезис, мне кажется, что у вас должно быть при диплойменте, ваш диплоймент вашего продукта должен состоять из двух операций
13:07
Первая, вы должны придумать, какая будет следующая версия, и вторая – это нажать кнопку Вот если у вас это так, если вы не задумываетесь каждый раз о том, как же мне выложить релиз нового моего продукта, а просто выбираете новую версию и нажимаете кнопку, то вы находитесь на третьем уровне
13:24
С чем я вас и поздравляю Уровня Open Source Kung-Fu Уровень четвертый – вам прислали Pull Request
4 уровень
13:34
Но другая история – вы сделали Open Source репозиторий, вы что-то туда выложили, написали какой-то код, и вот какой-то no-name, какой-то человек, которого вы не знаете, присылает вам Pull Request
13:46
Это судьбоносное событие в жизни каждого программиста, у кого такое случалось
13:52
Те же дети, человек, ну может быть не те же, но и даже не 10 Это момент такой эпохальный в жизни программиста, а оказывается то, что вы написали, не просто кому-то нужно, а они еще и хотят помочь вам сделать это лучше
14:07
И это, конечно, четвертый уровень, вы в этом случае действительно становитесь Open Source программистом, вы действительно попадаете в семейство Open Source девелоперов
14:16
Как туда попасть? Что для этого нужно сделать? Я думаю, и исследователи подтверждают мою интуицию, очень важно то, как оформлен ваш репозиторий
14:29
Оформление, стиль, стилистика, документация, тексты То есть вы должны показать контрибьюторам, что вы care, что вам это важно
14:40
Вы этот репозиторий создали не вечером в плохом настроении, а вы создавали его, и вы им живете
14:48
Вот что говорит нам исследование, что 95% популярных проектов у них не пустые README файлы, а у непопулярных в 65% только файлы заполнены
15:03
И есть еще несколько исследований, я их не привожу, которые показывают, что то, как README файл оформлен, то насколько в нем больше текста или в нем больше присутствует технических слов
15:14
От этого зависит интенсивность контрибьютора, а чем больше присылают pull-requests, тем ваш больше репозиторий имеет смысл и ценности для комьюнити
15:23
Оформляйте красиво, что бы вы ни выложили, даже если вы выложили курсовую работу, постарайтесь ее оформить так, чтобы она выглядела как проект с заявкой на победу, как будущий TensorFlow
15:35
Будьте TensorFlow на первых же шагах вашего проекта. Ни потом, когда у него будет уже 10 тысяч звезд, а начните с оформления, как будто вы уже TensorFlow
15:46
Я думаю, что это рецепт, ну так я его вижу, и эти цифры нам вроде бы говорят то же самое И второе интересное исследование, они говорят, что наличие бэджиков, которые показывают, знаете эти бэджики, continuous integration, бэджик, еще какие-то
16:01
И вот оказывается, что если эти бэджики на месте, если они есть, то лучше будут
16:10
They are most reliable signals, наиболее, так сказать, reliable, наиболее располагающие, да наиболее доверительные сигналы, которым мы, программисты, доверяем
16:22
И будем присылать свои pull-requests, если эти сигналы мы получаем Если бэджиков нет, я лично по себе скажу, у меня к репозиторию некое другое отношение, мне кажется, что его автор как-то сам к своему репозиторию относится не с интересом
16:39
И последнее, по-моему, в этом уровне Частота апдейтов readme file и количество списков и ссылок позитивно коррелируют с вероятностью того, что репозиторий будет популярным
16:55
Наука нам об этом говорит Чем больше ссылок, чем больше списков почему-то, я не знаю, почему списков, но в общем, чем более ваш readme симпатичный, больше шансов на получение pull-requests
5 уровень
17:09
Пятый уровень Ваш репозитории, ну я тут написал захватываю, я вам расскажу интересную историю, что это значит
17:17
Вам присылают не просто pull-request, а вам присылают pull-request, который вы сами написать не могли
17:23
Вам пишут такой код, о котором вы и не подозревали, и не умели его написать
17:29
То есть к вам приходят люди технически более грамотные, чем вы И делают из вашего продукта то, что нужно им
17:37
То есть они видят в вашем продукте перспективу, они его берут и улучшают под себя
17:43
Не свое создают, не аналог делают, а делают из вашего продукта более качественный
17:50
Со мной такое произошло однажды, я вам расскажу эту историю Вот мой продукт, который я сделал примерно полтора года назад, это библиотека на Rust
17:59
Я изучал Rust, год назад мне не хватило одной библиотеки, оказалось, что вроде бы ее нет, и я ее сделал
18:07
Но сделал некачественно То есть я сделал ее, как понимал, в тот момент, как я понимал язык Rust, но сделал очень красивый readme файл
18:17
Я сделал readme файл, я вставил в readme файл сравнительную характеристику скорости Вот правой слайдом видите, это часть моего readme файла
18:25
То есть я прямо в readme файле рассказал, с какой скоростью работает моя библиотека И сравнил ее с десятком других библиотек
18:32
И показал, смотрите, моя по определенным характеристикам на определенных скоростях
18:38
На определенных, точнее, размерах, объемах данных обгоняет другие библиотеки Все оформил красиво, но она не работала толком так идеально, как хотелось
18:47
И вот пришел человек, некий @Zefick!, и прислал мне с десяток pull-requests
18:54
И сделал все то, чего не сделал я И сейчас я не понимаю, что там внутри
19:00
Это по-прежнему моя библиотека, это по-прежнему мой код на Rust Я по-прежнему занимаюсь релизом свежих версий
19:07
А он куда-то ушел, он перестал контрибьютить Я ему писал несколько раз, спросил, а вот этот баг можешь поправить, а вот этот он испарился
19:16
Но он сделал серьезный contribution, он целый месяц этим занимался И он довел библиотеку до состояния, в котором мы обгоняем все другие 10 библиотек
19:25
Вот наша линейка Там, где вы видите цифру, которая меньше всех остальных, это выше скорость
19:32
Мы по всем колонкам, кроме последних, эти уже неважные колонки Но по первым колонкам мы, кроме вот одной цифры, мы обгоняем все остальные
19:40
Я не знаю, кто это сделал Но надо быть специалистом в Rust, я не такой глубокий специалист, чтобы решить ту задачу, которую он решил
19:48
То есть он захватил мой репозиторий, фактически Оставив при этом мне мои права
19:55
Я думаю, что это пятый уровень мастерства Сделать так, сделать такой репозиторий, в который пойдут другие люди и захватят
20:04
Не забирая себе Make sense? Ну и теперь мы переходим на сложный уровень, уровень номер 6
6 уровень
20:13
Вам присылают 100 багов
20:21
Цифра 100 условная, но она должна быть большая Вам начинают писать и требовать исправить ошибки
20:30
То есть у вас появляются комьюнити-пользователи И вам начинают набрасывать дефекты Я считаю лично, что количество багов является определяющим показателем качества продукта
20:41
Если багов много, в которых вы пофиксены, безусловно То у вас продукт высокого качества
20:47
Если вы его сделали и вам кажется, что он высокого качества, потому что вы в нем не можете найти ошибки Это еще пока не продукт
20:54
Это полуфабрикат Ваш совтверный продукт превратится в реально продукт Когда в нем будет большое количество найденных и исправленных дефектов
21:04
То есть дефекты являются ингредиентом качества Две цитаты вам приведу
21:13
Первая – кто читал эту книгу Называется Art of Software Testing Кажется, это вторая фундаментальная книга, вам посоветую за сегодня
21:22
Ее обязательно нужно прочитать Она короткая, несложная Уже третье издание, или даже четвертое сейчас
21:28
Ее переиздают и переиздают Книга была написана в 1979 году первый раз В ней говорится, среди прочего
21:35
Постулируется одна очень важная мысль Что количество дефектов в программном продукте неизмеримо велико
21:41
В любом программном продукте Вопрос просто в том, сколько из них вы успели найти
21:47
Вы успели найти много Вы как будто бы приблизились к некому качеству Вы успели найти мало – значит их найдут ваши пользователи
21:55
Ваша задача – найти раньше пользователей Если вы это делаете, а если еще это делают за вас, ваши open-source пользователи
22:03
То вот тут вы получаете бесплатный ингредиент качества любого программного продукта
22:09
Бесплатный И если посмотреть еще одна мысль, которая добавит здесь немножко
22:18
Под багом мы понимаем, и Mozilla, например, понимает это так Любые предложения по улучшению продукта
22:25
И фичи, и баги, и отсутствие документации Любые предложения, сформулированные пользователем со стороны или другим программистом
22:34
Являются для вас багом Чем больше таких багов у вас в бэклоге, чем больше у вас их в вашем баг-трекере, тем лучше
22:43
Ну и посмотрите на цифры, количество багов в известных программных продуктах В Mozilla 1,8 миллиона багов
22:52
Когда у вас будет, хорошо, забудьте про Mozilla Давайте посмотрим TensorFlow 36 тысяч багов зарегистрированы в TensorFlow, GitHub репозиторий
23:01
Это успешный софтверный проект Ни звезды, ни форки, ни количество скачиваний, количество багов
23:10
Это значит, что им пользуются, его испытали в тысячи разных вариантов Его попробовали на разном оборудовании, его попробовали с разным настроением
23:19
Его попробовали люди разной национальности и рассказали вам все, что они смогли найти 36 тысяч раз
23:26
Сколько у вас в проектах? Кто когда-либо получал 100 багов от комьюнити?
23:33
Есть такие люди же Вот это, мне кажется, шестой уровень Ну идем дальше
7 уровень
23:40
Уровень номер семь Дальше сложные уровни Первый уровень номер семь
23:46
Это вам какая-то большая компания предложит деньги за поддержку программного продукта
23:52
Такое случается Я вам расскажу свою личную историю Со мной это случилось один раз в жизни
23:58
GitHub прислал мне такой email Это было в 2018 год, 6 лет назад
24:05
У меня есть репозиторий на GitHub, мой собственный Который является библиотекой для работы с GitHub API
24:13
Тем, кому нужно работать через Java с GitHub API, могут использовать мою библиотеку Я ее создал для себя
24:20
Мне она нужна была, я ее создал, потом какие-то контрибьюторы там были А потом пришло письмо из GitHub GitHub говорит, а давай мы тебе деньги будем платить
24:28
И ты будешь продолжать разрабатывать свой open source продукт И могу вам сказать, что деньги были предложены неплохи
24:36
Я вполне мог за эти деньги, ну средний программист вполне мог за эти деньги Чувствовать себя очень хорошо
24:43
За поддержку open source продукта Это произошло за месяц до покупки GitHub Microsoft
24:52
Потом Microsoft их купил и у нас не случилось Видимо Microsoft поменял политику и никаких денег я от них не получил
25:00
Но переговоры шли И мы вполне были близки от того, чтобы получить деньги от GitHub
25:06
Мне кажется, это уровень, на который можно добраться, будучи Ну, просто дисциплинированным, хорошим open source девелопером
25:13
Который делает что-то нужное В итоге это окажется нужным какой-то большой компании И эта компания вместо того, чтобы делать свой продукт
25:21
Они просто скажут, а давайте мы вот этого девелопера, сидящего где-то там далеко Поддержим ежемесячным ретейнером
25:28
Будем ему платить какие-то деньги И он будет поддерживать продукт в живом состоянии
25:34
До этого уровня, если добраться, это круто Можно бросить основную работу Заниматься только open source, только своим проектом
25:42
И получать деньги от какого-нибудь условного Google, Amazon В данном случае GitHub
8 уровень [Alexander_Medvednikov_The_V_Programming_language]
25:48
Ну и последние два уровня, до которых я не добрался Я не знаю, смогу ли добраться Уровень номер 8
25:55
Это вам GitHub может предложить бесплатные так называемые large runners У GitHub Continuous Integration, у GitHub Actions
26:03
Есть стандартные машины, которые работают для всех и всяких Но для крупных проектов, для интересных проектов
26:10
GitHub предлагает дополнительное оборудование, более дорогое, бесплатно Откуда я об этом узнал?
26:17
Несколько месяцев назад я брал интервью у Александра Медведникова Он автор языка программирования V
26:25
Язык программирования V На GitHub у него более 28 тысяч звезд Сам он русский, живет в Европе
26:33
Он этот язык программирования создал самостоятельно Потом у него появилось большое количество контрибьютеров
26:39
В итоге язык популярный, созданный с нуля, просто одним программистом И GitHub ему дает железо для тестирования всего этого языка
26:48
Всей его кухни внутренней и так далее То есть это явный серьезный achievement для open source developer
26:57
Как стать таким, как Александр, я не знаю Я думаю, здесь одного просто дисциплинированного подхода К правильному оформлению readme файлов мало
27:04
Нужно еще талант, нужно еще как-то поймать эту сферу Ему, может быть, повезло в чем-то угадать с этим языком программирования
27:13
Он молодец, однозначно молодец Это восьмой уровень Ну и последний уровень – это
9 уровень
27:20
Спонсоры на GitHub принесут вам 100 тысяч долларов в год
27:28
Такие истории есть Вы знаете, что такое спонсорство на GitHub? Кому из вас что-то платили спонсоры?
27:36
Раз Ну, спонсор на GitHub – кнопочка “спонсор” GitHub – спонсор, да
27:42
Вот есть такие кейсы Это один из известных кейсов Это программист, который создал LiveWire и AlpineJS
27:50
Он показывает свои доходы вполне открыто У него на текущий момент – это скриншот вчерашнего дня – 200 спонсоров на GitHub
27:59
Средний спонсор ShipPacket – у него около 20 долларов Можете перемножить в месяц Можете перемножить 200 спонсоров на 20
28:07
А то и больше долларов ему платит каждый автоматически Он говорит, что он получает 112 тысяч долларов
28:14
Это его блог-пост, можно посмотреть, почитать Он получает 112 тысяч долларов в год только от GitHub
28:21
Чеки к нему приходят каждый месяц около 10 тысяч долларов Что он для этого делает?
28:27
Он делает продукты опенсорсные, которые успешные, которые нужны людям Он занимается только этим
28:33
Он бросил свою основную работу Это его фото Есть статья на GitHub, где они берут у него интервью, спрашивают, как он этого достиг и так далее
28:41
У него есть еще один блог-пост, где он рассказывает, что он в прошлом году заработал миллион долларов Не в прошлом году, сори, а суммарно на опенсорсе
28:49
Он заработал миллион долларов и рассказывает, откуда Там в том числе эти 100 тысяч от спонсоров
28:55
То есть опенсорс – это вполне себе место, где можно заработать Это не только for fun
29:01
Это не только получить удовольствие и поиграться в нерабочее время Это вполне себе может быть история успеха
29:08
Это точно девятый уровень Все, спасибо Спасибо большое, идеально в тайминг
Информация обо мне
29:18
Что дальше? Сори, последний слайд пропустил Вы можете подписаться на мой телеграм-канал, ссылка слева Вы можете прослушать все, что я вам рассказал
29:25
Я рассказывал студентам университета Иннополис курс из восьми лекций, состоящих Достаточно большой контент, все лекции записаны, можно тоже их посмотреть
29:33
Ну и последнее, если у вас нет идей, чем заняться в опенсорсе, с чего начать, какой проект сделать
29:39
Пишите мне, подскажу идею, помогу к нашему проекту присоединиться К одному из наших проектов
Вопросы
29:46
Все, класс, секундочку Да, давайте еще раз поаплодируем Тут просто рука поднялась еще до того, как вы закончили
29:54
Поэтому на один вопрос у нас все-таки есть время Давайте Спасибо за достаточно интересный лекция
30:01
Меня зовут Артем, я являюсь разработчиком опенсорс Вопрос такой Раньше я мог, например, использовать спонсорство на GitHub и донаты принимать
30:11
Сейчас все усложнилось, к сожалению Какие вы видите сейчас перспективы для краудфандинга, можешь так сказать, опенсорс в текущих реалиях сейчас?
30:21
Да, сложный вопрос, не знаю, не могу пока предложить Я думаю, что наши платформы должны что-то предложить, типа Gitverse, например
30:30
Или предложить аналогичную систему спонсорства Пока, видимо, она не предлагается Если есть действительно ожидание, что будет хороший sponsorship поток от GitHub
30:38
Я бы советовал попытаться американский счет открыть, американскую карту Если есть такие объемы
30:44
Если, конечно, речь идет о 100 долларах, то, наверное, никак, к сожалению Спасибо за вопрос, спасибо за ответ
30:52
Еще раз аплодисменты для Егора, пожалуйста Спасибо, что были с нами

Поделиться: