У всех на виду: нюансы Open Source разработки

Открытый семинар для студентов в компании CUSTIS (20 марта 2014 года).
Лектор: Виталий Филиппов, ведущий веб-разработчик.

Transcript

1. 20 марта 2014 У всех на виду: нюансы Open Source разработки Виталий Филиппов Ведущий веб-разработчик
2. О себе  Мои доклады и контакты: http://yourcmc.ru/wiki/User:VitaliyFilippov  Поддерживаю сборку MediaWiki4Intranet: http://wiki.4intra.net/  Linux’оид уже лет 8, горячий поклонник свободного софта (FSF! GPL!)  Пишу на разном с младых ногтей (сейчас в основном веб: PHP/Perl/Python) 2/55
3. больших (40–100 человеко-лет) корпоративных информационных систем на заказ занимается разработкой *Open Source в CUSTIS: библиотеки/фреймворки, внутренняя инфраструктура (контроль версий, баг-трекер, wiki, сервера) 3/55
4. Open Source 1. Что такое F/OSS, в чём его фишка? 2. Зачем оно мне? 3. Как вносить вклад? 4. Как вести проект? 5. Всё ли гладко? Как делать не надо? 4/55
5. О чём это всё? Да-да, открытые исходники! 5/55
6. Svobodno, not besplatno: терминология  Freeware. Free as beer. Исходников не дают, возможны ограничения. Внутри возможен троян %-)  Public Domain. Отказ от прав, отсутствие лицензии (обязательств)  Free Software. Свободное ПО. Можно без ограничений использовать, дорабатывать и распространять  Open Source. В основном синоним Free software, но точное определение более запутанно  Copyleft. Вид свободного ПО. «Авторское лево», «вирусная лицензия». GPL, CC-BY-SA  Permissive. Вид свободного ПО. «Разрешительная лицензия». BSD / MIT, Apache 6/55
7. В чём смысл свободного ПО? Снятие неестественных ограничений 7/55
8. Смысл свободного ПО  Производитель – потребитель (закрытые исходники не размножаются…)  Всеобщее сотрудничество – все дорабатывают, все пользуются  …сбывшийся коммунизм, реальный за счёт нулевой цены копии   Обмен и накопление опыта, переиспользование кода  Разработка открыта для пользователя (а не скрыта ботами в 2-х уровневой ТП…) 8/55
9. Дилемма заключенного Аналог «сотрудничать/предать» в мире ПО: «открыть/закрыть»   1 раз и независимо – оба предадут  Но при повторе – лучше «сотрудничать + мстить» Б молчит Б предаёт А молчит Обоим по 0.5 года А – 10 лет, Б – свободен А предаёт А – свободен, Б – 10 лет Обоим по 2 года 11/55
10. Теория критической массы ПО развивается довольно медленно ⇒  При (t → +∞) набирается «критическая масса» СПО  Сообщество расширяется*, развитие ускоряется  Закрытое теряет базу для обучения (зачем студенту Delphi за $1000-$2000?)  Слабые закрытые продукты вымирают («СПО коммодитизирует рынок») * если его правильно готовить 12/55
11. Собор и Базар (Эрик Рэймонд, 1997) 13/55
12. «Собор»  «Иерархическое подчинение»  Централизованное управление  Маленькая «команда экспертов»  Планирование  Закрытое тестирование  … Аналог из мира Wiki – Nupedia, которую никто и не помнит 14/55
13. «Базар»  «Равноправие»  Самоорганизация  Совместная работа большого сообщества,  Открытость для внесения правок и тестирования  Модерирование Компании это, кстати, тоже поняли: Agile, SCRUM… Аналог из мира Wiki – Wikipedia, её все знают хорошо 15/55
14. «Базар», есть и минусы  Меньшая направленность усилий  Редкий/специфический софт пишется медленно (например, CAD’ы)  Могут отсутствовать «красивости»  Не все вносят большой вклад  Много делают компании / основные разработчики Но всем надо помнить: важен каждый активный пользователь! 16/55
15. "TRUE" базар крут, но его немного  Linux, FreeBSD, независимые дистры (Debian, Gentoo, Arch), HomeBrew, CyanogenMod  KDE, Gnome(?), MATE(?)  Фреймворки/библиотеки/языки (php, js, java), VCS (Git, Subversion)  (?) VLC, QEMU, OpenStack, LLVM, Mesa, LibreOffice, MariaDB/MySQL, Blender Контрпримеры:  PostgreSQL – 38 авторов с 1996 года, 65 % – Bruce Momjian и Tom Lane  nginx – 26 авторов всего, 75 % – Игорь Сысоев 17/55
16. Почему «Базара» не так много? Надо строить сотрудничество, а это не так легко  Заинтересовать  Не отпугнуть (конфликтами, которые «мясом наружу»)  Не плодить лишнюю конкуренцию (форки)  Пропагандировать  Кстати, Github: Social Coding  Грамотный инженер-диктатор во главе… :) 18/55
17. А от конфликтов страдают все  Сам проект «Злые вы, уйду я от вас; пилите сами»  Смежные проекты «Надоело фиксить чужие баги, давайте форкнем его уже»  Пользователи «Отстой этот ваш линупс…»  Компании-разработчики «Ни хрена оно не делает, это ваше сообщество – закроем-ка мы проект» 19/55
18. OK, надо что-то делать 20/55
19. …и сначала определимся: а зачем?  Ради денежной выгоды?  Будем откровенны – нечасто и не сразу  Хотя… влезть в закрытое тоже трудно (а то и невозможно) 21/55
20. Монетизация Отсюда – куча странных гибридных вариантов монетизации:  Продажа поддержки – RedHat, очень успешно  Коммерческое лицензирование – Qt, ExtJS  Быстрые платные багфиксы – ExtJS  Отдельные несвободные версии, Open Core – GitLab, nginx, SugarCRM, MariaDB… 22/55
21. Монетизация  Инвестиции (MongoDB, CyanogenMod)  Их, правда, надо как-то отбивать…  Сервисы (OwnCloud)  Donation (туго)  Принудительный Donation – 5$ за скачивание (O_o, но Parted Magic)  Заказные доработки, Crowdfunding  Timothy Arceri + Mesa3D – молодец   http://www.bountysource.com 23/55
22. Зачем ещё?  Отличная база для обучения – код открыт!  Файловые системы? Видеодрайвера? СУБД? Компиляторы? 3D редакторы?  WELCOME! …всё лучше, чем под битрикс учиться писать  Дипломные работы (открыть? на базе открытого?)  Крайний случай: Con Kolivas, анестезиолог из Австралии 24/55
23. NIH? В обе стороны:  Прямая: всё, что есть, имеет «Фатальный Недостаток» ⇒ создаётся новый проект  Обратная: доработки могут не принимать потому же (LLVM/GCC?)  Canonical (Bazaar, Mir, Unity)  «не то, что чего-то не хватало, а было много того, что не нужно»  «некоторые разработчики Wayland ранее отрицательно высказывались о Canonical»  Lennart Poettering из RedHat  Уже поутихло, но: PulseAudio, systemd… 25/55
24. То, что и так нужно! Вам или вашей компании  Самый частый и самый простой путь.  В открытость нужно вложиться чуть-чуть, профит придёт сам  В конце концов, ПО – лишь инструмент, закрывать его нет смысла 26/55
25. Писать своё? Допиливать? Форкать? Варианты:  Отправлять патчи в апстрим  Поддерживать набор патчей  ??? Поддерживать форк  Форк = когда уже живого места нет  справа – форк КАМАЗа  Писать с нуля своё (конечно, дольше) Нюансов хватает в любом случае 27/55
26. Зачем вносить вклад?  Если нашёл баг / нужна фича – не жалуйся  …будь мужиком, напиши патч! :) 28/55
27. Зачем вносить вклад?  Не бойтесь допиливать/отлаживать всё подряд!  Это интересно и полезно, и ничего там сложного нет  Опыт незаменимый – «…умение понимать чужой код…»  «Просто поучиться» – тоже можно  Если у вас форк/патчи – чтобы переложить поддержку на апстрим  …и все остальные «зачем» сюда тоже подходят 29/55
28. Вклад = не только код!  Пользоваться, тестировать, искать баги Хорошие отчёты об ошибках всегда полезны  Написать документацию (разобрался сам – разъяснил другим)  Перевести на свой язык  Оценить удобство интерфейса, нарисовать макетик  Пиар/пропаганда  30/55
29. Если всё-таки код…  Пытаться принять чужие устои 31/55
30. Чужие устои  Стиль кода  Разбивать кодовые бомбы на отдельные патчи  Архитектура (совместимое побеждает)  Встречается излишняя диктатура…  Тогда решайте, надо ли оно вам 32/55
31. Можно форкнуть (если не удаётся сотрудничать)  Набор патчей  Небольшие доработки – предпочтительный вариант!  Форк  Когда уже живого места не осталось  Дальше форка – только свой проект с нуля  Сначала пробуйте отправлять патчи! 33/55
32. Свой проект 34/55
33. Что нужно проекту (маленькому, большому ли) Организация Инфраструктура 35/55
34. Организация 36/55
35. Чёткая цель и ценность  «Зачем», «какие/чьи задачи решает» (кстати, это верно для всех проектов, не только F/OSS) (Привет, ReactOS, привет, «Русские Линуксы»!..) 37/55
36. Пиар/пропаганда  Общаться с людьми!  Пользоваться своим продуктом «Eat your own dog food»  Подчёркивать ценность  Подчёркивать свободу  Планы разработки  Анонсы новых версий 38/55
37. Модульная архитектура 1. Полезно в целом 2. Даёт распределять задачи 3. Стимулирует сообщество к росту 39/55
38. Слушать мнение пользователей  Иначе частый конфликт – «Особое Видение»  Linus: “If you think your users are idiots, only idiots will use it”  Обратная сторона – «Шумное Меньшинство» (тролли?)  Нет дыма без огня! – прислушиваться всё равно надо Примеры:  KDE: «Nepomuk’у требуется Akonadi» (кто все эти люди?!!)  Gnome 3: стильно, модно… Но что-то люди не спешат юзать :(  Gimp: однооконный режим, разделение Save/Export 40/55
39. Стабильность, совместимость  Особенно для библиотек! (например, GTK 3.x: «мы libgnome, а не графический тулкит»)  KDE 4: Plasma не падает! А аккуратно ложится, медленно снимает с себя core и постанывает в syslog… (к 4.11 всё-таки, вроде, пофиксили) 41/55
40. Конфликты  Решать конструктивно  Бан – крайняя мера  Взаимодействовать с форками  Потеряли интерес? Отдайте кому-нибудь 42/55
41. Инфраструктура 43/55
42. Система контроля версий  Только DVCS!  (бэкап, веточки, pull request’ы…)  Самая популярная – Git  Можно Mercurial  Главное – НЕ Bazaar 44/55
43. Лицензия  Лучше копилефт  Если копилефт – GPL 3  Если разрешительная – Apache  Коммерческое лицензирование? Либо GPL+CLA, либо Apache  Главное – не своя и не малоизвестная! 45/55
44. Стиль кода, цикл релизов Стиль кода:  Должен быть!  Хотя бы кратко описан  Лучше популярный  MediaWiki: регулярные проблемы с review  mc: перешли на вменяемый стиль кода  Не увлекаться «дизайном ради дизайна» Цикл релизов:  Лучше – регулярный 46/55
45. Список рассылки – оружие пролетариата Минусы:  Неудобные архивы, навигация… «не модно» :)  Хочешь написать? Подпишись на ВСЁ! А ещё спам  Длинные обсуждения неудобны  >100 писем в день — беда; digest’ы не спасают Плюсы:  Всё вместе — новости, форум, багтрекер, code review  Подписка на ВСЁ может стимулировать взаимопомощь  Примитивные архивы «вечны»  Не зависят от хостинга/движка форума…  Индексируются gmane’ами, google’ом 47/55
46. Баг-трекер 48/55
47. Баг-трекер  Открытый!  На баги — реагировать!  Хотя не все баги одинаково полезны  Bugzilla, Trac, Redmine… 49/55
48. Code Review  На патчи — реагировать ещё активнее!  Иначе отпугиваете контрибьюторов  Можно жить в списке рассылки или багтрекере  Обязательное ревью — с осторожностью  Плохой пример — MediaWiki (обсуждают коммиты по полгода)  Хороших опенсорсных систем Code Review я не видел (Phabricator?)  Хорошие примеры — многие мелкие проекты 50/55
49. Сайт  Хотя бы минимальная страничка  Статус проекта  Ссылки на багтрекер, список рассылки и т. п.  README  Документация  Публичная Wiki 51/55
50. Хостинги Простейший вариант для старта   Некоторая зависимость от хостинга  Github, Gitorious,  Google Code, Bitbucket   Всё сразу: VCS, веб-интерфейс, багтрекер, Pull Request’ы, дополнительная раскрутка   Слабые Wiki и багтрекер, нет списка рассылки, форума  SourceForge:  обилие рекламы,  есть списки рассылок 52/55
51. Заключение  Не бойтесь отлаживать и улучшать всё, что вам интересно!  Слушайте пользователей, цените вклад, и его будет больше  Многое актуально лишь для крупных проектов: помните, если сделаете таковой  53/55
52. Ссылки  http://www.linux.org.ru/news/ubuntu/10057373 – есть чуть-чуть в тему NIH и Mir, интервью с Jono Bacon  http://www.opennet.ru/opennews/art.shtml?num=38016 – интервью с Алексеем Кузнецовым  http://codecs.multimedia.cx/?p=339 – почему ffmpeg форкнулся на ffmpeg и libav?  http://lib.ru/LINUXGUIDE/bazar.txt_with-big-pictures.html - старый текст «Собор или базар»  http://rus-linux.net/MyLDP/BOOKS/Architecture-Open-Source-Applications/index.html  http://producingoss.com/ – опенсорсная книга об опенсорсе  http://bountysource.com/ – бабло за багфиксинг; http://fossfactory.org/ - то же, но сайт кривой  http://www.theopensourceway.org/book/The_Open_Source_Way- How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html  http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ , http://www.linuxuser.co.uk/news/a-linux-conspiracy-theory – про GTK 3  https://mail.gnome.org/archives/gnome-shell-list/2009-December/msg00052.html, https://mail.gnome.org/archives/gnome-shell-list/2009-December/msg00091.html – старые треды про Gnome 3  https://gerrit.wikimedia.org/r/89141 – ревью примитивного патча с октября по март…  https://gerrit.wikimedia.org/r/#/c/88443/ – 5 строчек и 3 месяца  https://www.reactos.org/forum/viewtopic.php?t=7245#p63965 – «Но в любом случае, как я уже говорил, это не моя вина, что вин32 в транке уже 10 лет пилится и до сих пор недопилен. Значит не так его пилят, пила не та :)»  http://www.linux.org.ru/news/kernel/3918208, https://lkml.org/lkml/2009/7/28/373 – Кокс против Линуса  http://www.thinkdigit.com/forum/chit-chat/81361-why-i-quit-kernel-developer-con-kolivas.html – Con Kolivas 2007, я устал, я ухожу (потом вернулся, но патчи пропихивать уже не стал)  Немного писем CK: https://lkml.org/lkml/2012/3/24/165, https://lkml.org/lkml/2010/12/5/21, https://lkml.org/lkml/2009/9/6/231 54/55
53. Спасибо! Вопросы? Виталий Филиппов filippov@custis.ru 55/55