Открытый семинар для студентов в компании CUSTIS (20 марта 2014 года). Лектор: Виталий Филиппов, ведущий веб-разработчик. Аннотация: Главное в свободном ПО — это всеобщее сотрудничество. Но правильно его организовать может быть нелегко: и люди, и компании часто не понимают смысл открытости и те преимущества, которые она дает. Это приводит к проблемам взаимодействия — между проектом и пользователями, внутри проекта, между разными проектами... Как с ними справиться? Что нужно для успешности «открытого» проекта? Как организовать разработку с технической точки зрения? Какую лицензию выбрать? И как вообще устроен мир разработки свободного ПО, какие есть интересные Open Source проекты и зачем их создавать? Обо всем этом и пойдет речь на семинаре. Видеозапись семинара: https://vimeo.com/90127303.

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