20 марта 2014

У всех на виду:

нюансы Open Source разработки

Виталий Филиппов

Ведущий веб-разработчик

О себе

Мои доклады и контакты:

http://yourcmc.ru/wiki/User:VitaliyFilippov

Поддерживаю сборку MediaWiki4Intranet:

http://wiki.4intra.net/

Linux’оид уже лет 8, горячий поклонник

свободного софта (FSF! GPL!)

Пишу на разном с младых ногтей

(сейчас в основном веб: PHP/Perl/Python)

2/55

больших (40–100 человеко-лет)

корпоративных

информационных систем

на заказ

занимается разработкой

*Open Source в CUSTIS: библиотеки/фреймворки, внутренняя

инфраструктура (контроль версий, баг-трекер, wiki, сервера)

3/55

Open Source

1. Что такое F/OSS, в чём его фишка?

2. Зачем оно мне?

3. Как вносить вклад?

4. Как вести проект?

5. Всё ли гладко? Как делать не надо?

4/55

О чём это всё?

Да-да, открытые исходники!

5/55

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/55

Смысл свободного ПО

Производитель – потребитель (закрытые

исходники не размножаются…)

Всеобщее сотрудничество – все

дорабатывают, все пользуются

…сбывшийся коммунизм, реальный за счёт

нулевой цены копии

Обмен и накопление опыта,

переиспользование кода

Разработка открыта для пользователя

(а не скрыта ботами в 2-х уровневой ТП…)

8/55

Дилемма заключенного

Аналог «сотрудничать/предать» в мире ПО:

«открыть/закрыть»

1 раз и независимо – оба предадут

Но при повторе – лучше «сотрудничать +

мстить»

Б молчит Б предаёт

А молчит Обоим по 0.5 года А – 10 лет, Б –

свободен

А предаёт А – свободен, Б –

10 лет Обоим по 2 года

11/55

Теория критической массы

ПО развивается довольно медленно ⇒ При (t → +∞) набирается «критическая масса» СПО

Сообщество расширяется*, развитие ускоряется

Закрытое теряет базу для обучения (зачем

студенту Delphi за $1000-$2000?)

Слабые закрытые продукты вымирают («СПО

коммодитизирует рынок»)

* если его правильно готовить

12/55

Собор и Базар

(Эрик Рэймонд, 1997)

13/55

«Собор»

«Иерархическое подчинение»

Централизованное управление

Маленькая «команда экспертов»

Планирование

Закрытое тестирование

…

Аналог из мира Wiki – Nupedia, которую никто

и не помнит

14/55

«Базар»

«Равноправие»

Самоорганизация

Совместная работа большого

сообщества,

Открытость для внесения

правок и тестирования

Модерирование

Компании это, кстати, тоже поняли: Agile, SCRUM…

Аналог из мира Wiki – Wikipedia, её все знают

хорошо

15/55

«Базар», есть и минусы

Меньшая направленность усилий

Редкий/специфический софт пишется медленно

(например, CAD’ы)

Могут отсутствовать «красивости»

Не все вносят большой вклад

Много делают компании / основные

разработчики

Но всем надо помнить: важен каждый

активный пользователь!

16/55

"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

Почему «Базара» не так много?

Надо строить сотрудничество,

а это не так легко

Заинтересовать

Не отпугнуть

(конфликтами, которые «мясом наружу»)

Не плодить лишнюю конкуренцию (форки)

Пропагандировать

Кстати, Github: Social Coding

Грамотный инженер-диктатор во главе… :)

18/55

А от конфликтов страдают все

Сам проект

«Злые вы, уйду я от вас;

пилите сами»

Смежные проекты

«Надоело фиксить чужие баги,

давайте форкнем его уже»

Пользователи

«Отстой этот ваш линупс…»

Компании-разработчики

«Ни хрена оно не делает, это ваше

сообщество – закроем-ка мы проект»

19/55

OK, надо что-то делать

20/55

…и сначала определимся: а зачем?

Ради денежной выгоды?

Будем откровенны – нечасто

и не сразу

Хотя… влезть в закрытое

тоже трудно

(а то и невозможно)

21/55

Монетизация

Отсюда – куча странных

гибридных вариантов

монетизации:

Продажа поддержки –

RedHat, очень успешно

Коммерческое лицензирование –

Qt, ExtJS

Быстрые платные багфиксы – ExtJS

Отдельные несвободные версии,

Open Core –

GitLab, nginx, SugarCRM, MariaDB…

22/55

Монетизация

Инвестиции (MongoDB, CyanogenMod)

Их, правда, надо как-то отбивать…

Сервисы (OwnCloud)

Donation (туго)

Принудительный Donation – 5$ за

скачивание (O_o, но Parted Magic)

Заказные доработки, Crowdfunding

Timothy Arceri + Mesa3D – молодец

http://www.bountysource.com

23/55

Зачем ещё?

Отличная база для обучения – код

открыт!

Файловые системы?

Видеодрайвера? СУБД?

Компиляторы? 3D редакторы?

WELCOME! …всё лучше, чем под

битрикс учиться писать

Дипломные работы (открыть? на

базе открытого?)

Крайний случай: Con Kolivas,

анестезиолог из Австралии

24/55

NIH?

В обе стороны:

Прямая: всё, что есть, имеет «Фатальный

Недостаток» ⇒ создаётся новый проект

Обратная: доработки могут не принимать

потому же (LLVM/GCC?)

Canonical (Bazaar, Mir, Unity)

«не то, что чего-то не хватало, а было

много того, что не нужно»

«некоторые разработчики Wayland ранее

отрицательно высказывались о Canonical»

Lennart Poettering из RedHat

Уже поутихло, но: PulseAudio, systemd…

25/55

То, что и так нужно!

Вам или вашей компании

Самый частый и самый простой путь.

В открытость нужно вложиться чуть-чуть,

профит придёт сам

В конце концов, ПО – лишь инструмент,

закрывать его нет смысла

26/55

Писать своё? Допиливать? Форкать?

Варианты:

Отправлять патчи в апстрим

Поддерживать набор патчей

??? Поддерживать форк

Форк = когда уже живого места нет

справа – форк КАМАЗа

Писать с нуля своё (конечно, дольше)

Нюансов хватает в любом случае

27/55

Зачем вносить вклад?

Если нашёл баг / нужна фича – не жалуйся

…будь мужиком, напиши патч! :)

28/55

Зачем вносить вклад?

Не бойтесь допиливать/отлаживать всё

подряд!

Это интересно и полезно, и ничего там

сложного нет

Опыт незаменимый – «…умение понимать

чужой код…»

«Просто поучиться» – тоже можно

Если у вас форк/патчи – чтобы переложить

поддержку на апстрим

…и все остальные «зачем» сюда тоже

подходят 29/55

Вклад = не только код!

Пользоваться, тестировать, искать баги

Хорошие отчёты об ошибках всегда полезны

Написать документацию

(разобрался сам – разъяснил другим)

Перевести на свой язык

Оценить удобство интерфейса,

нарисовать макетик

Пиар/пропаганда

30/55

Если всё-таки код…

Пытаться принять чужие устои

31/55

Чужие устои

Стиль кода

Разбивать кодовые бомбы на отдельные

патчи

Архитектура (совместимое побеждает)

Встречается излишняя диктатура…

Тогда решайте, надо ли оно вам

32/55

Можно форкнуть

(если не удаётся сотрудничать)

Набор патчей

Небольшие доработки –

предпочтительный вариант!

Форк

Когда уже живого места не осталось

Дальше форка – только свой проект с нуля

Сначала пробуйте отправлять патчи!

33/55

Свой проект

34/55

Что нужно проекту

(маленькому, большому ли)

Организация Инфраструктура

35/55

Организация

36/55

Чёткая цель и ценность

«Зачем», «какие/чьи задачи решает»

(кстати, это верно для всех проектов,

не только F/OSS)

(Привет, ReactOS, привет, «Русские

Линуксы»!..)

37/55

Пиар/пропаганда

Общаться с людьми!

Пользоваться своим продуктом

«Eat your own dog food»

Подчёркивать ценность

Подчёркивать свободу

Планы разработки

Анонсы новых версий

38/55

Модульная архитектура

1. Полезно в целом

2. Даёт распределять задачи

3. Стимулирует сообщество к росту

39/55

Слушать мнение пользователей

Иначе частый конфликт – «Особое Видение»

Linus: “If you think your users are idiots, only idiots

will use it”

Обратная сторона – «Шумное Меньшинство»

(тролли?)

Нет дыма без огня! – прислушиваться всё равно

надо

Примеры:

KDE: «Nepomuk’у требуется Akonadi» (кто все эти люди?!!)

Gnome 3: стильно, модно… Но что-то люди не спешат

юзать :(

Gimp: однооконный режим, разделение Save/Export

40/55

Стабильность, совместимость

Особенно для библиотек!

(например, GTK 3.x: «мы libgnome, а не графический

тулкит»)

KDE 4: Plasma не падает! А аккуратно

ложится, медленно снимает с себя core и

постанывает в syslog…

(к 4.11 всё-таки, вроде, пофиксили)

41/55

Конфликты

Решать конструктивно

Бан – крайняя мера

Взаимодействовать с форками

Потеряли интерес? Отдайте

кому-нибудь

42/55

Инфраструктура

43/55

Система контроля версий

Только DVCS!

(бэкап, веточки, pull request’ы…)

Самая популярная – Git

Можно Mercurial

Главное – НЕ Bazaar

44/55

Лицензия

Лучше копилефт

Если копилефт – GPL 3

Если разрешительная – Apache

Коммерческое лицензирование? Либо

GPL+CLA, либо Apache

Главное – не своя и не малоизвестная!

45/55

Стиль кода, цикл релизов

Стиль кода:

Должен быть!

Хотя бы кратко описан

Лучше популярный

MediaWiki: регулярные

проблемы с review

mc: перешли на вменяемый стиль кода

Не увлекаться «дизайном ради дизайна»

Цикл релизов:

Лучше – регулярный

46/55

Список рассылки – оружие

пролетариата

Минусы: Неудобные архивы, навигация… «не модно» :)

Хочешь написать? Подпишись на ВСЁ! А ещё спам

Длинные обсуждения неудобны

>100 писем в день — беда; digest’ы не спасают

Плюсы: Всё вместе — новости, форум, багтрекер, code review

Подписка на ВСЁ может стимулировать взаимопомощь

Примитивные архивы «вечны»

Не зависят от хостинга/движка форума…

Индексируются gmane’ами, google’ом

47/55

Баг-трекер

48/55

Баг-трекер

Открытый!

На баги — реагировать!

Хотя не все баги одинаково полезны

Bugzilla, Trac, Redmine…

49/55

Code Review

На патчи — реагировать ещё активнее!

Иначе отпугиваете контрибьюторов

Можно жить в списке рассылки или багтрекере

Обязательное ревью — с осторожностью

Плохой пример — MediaWiki (обсуждают коммиты

по полгода)

Хороших опенсорсных систем Code Review я не

видел (Phabricator?)

Хорошие примеры — многие мелкие проекты

50/55

Сайт

Хотя бы минимальная страничка

Статус проекта

Ссылки на багтрекер, список рассылки и т. п.

README

Документация

Публичная Wiki

51/55

Хостинги

Простейший вариант для старта

Некоторая зависимость от хостинга

Github, Gitorious, Google Code, Bitbucket

Всё сразу: VCS, веб-интерфейс,

багтрекер, Pull Request’ы, дополнительная

раскрутка

Слабые Wiki и багтрекер, нет списка

рассылки, форума

SourceForge: обилие рекламы, есть

списки рассылок

52/55

Заключение

Не бойтесь отлаживать и улучшать всё, что вам

интересно!

Слушайте пользователей, цените вклад, и его

будет больше

Многое актуально лишь для крупных проектов:

помните, если сделаете таковой

53/55

Ссылки

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/23154/55

Спасибо!

Вопросы?

Виталий Филиппов

filippov@custis.ru

55/55