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

Насегодняшний день опенсорс набирает все больше и больше оборотов, писать под опенсорс считается проявлением хорошего тона и предписывается каждому разработчику(и я полностью это поддерживаю). Многие гиганты софт индустрии начали открывать свой код для общего доступа. В общем если посмотреть с этой стороны то кажется что все идет в лучшую сторону. И оно конешно так если не одна серйозная проблема в опенсорс. И проблема эта – отсутствие контроля за происходящим. И по большей мере проблема эта проявляется в веб разработке.

Для примера возьмем WordPress и его немаленькое комьюнити.

Как бы его не рекламировали и не прославляли но каждый специалист по веб разработке скажет вам что это просто хлам. В проекте вообще отсутсвует какаято жесткая типизация. Вот к примеру часть текста из руководства по написанию плагинов:

Все функции вашего плагина должны иметь уникальные имена, отличные от имен функций ядра WordPress, других плагинов или тем. По этой причине, хорошая идея — использовать уникальный префикс для имен функций вашего плагина. Другая возможность — объявлять ваши функции внутри класса (который тоже должен иметь уникальное имя).

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

Многие говорят “Зато у вордпреса все есть, скачал плагин, поставил и используешь”. Так то оно так, только вот потом не стоит удивлятся что блог не выдерживает больше 10 пользователей, что постоянно падает БД, что скорость загрузки страницы исчесляется минутами и прочие неприятности.

И вся эта каша из-за полного осутствия жестких стандартов. И если для обычных закрытых проектов стандарты несут скорее информативный характер(так как присутсвует сторонний контроль), то для опенсорс стандарты – это костяк на котором держится весь проект.

Итак давайте ответим на вопрос каким должен быть качественный опенсорс.

1. Проект должен иметь постоянную группу разработчиков
2. Должны быть описаны стандарты по разработке проекта
3. Каждая даже самая малая часть проекта не должна включатся в общий билд если присутсвует хоть одно нарушение стандарта разработки.
4. Плагины, Виджиты и прочие части программы не относящиеся к ядру приложения должны основыватся на жестко структурированом АПИ и не должны подключатся к основной программе если их структура не соответсвует стандартам.
5. Все дополнения к программе должны делится на ветки. Допустим “Разработка основной группы”, “Разработка комьюнити”, “Сторонняя разработка”. При этом каждая ветка является гарантом качества дополнения.

Проще говоря жесткость стандартов должна быть пропорциональна растоянию между разработчиками.

ЗЫ: Не так важно количество, как качество (о комьюнити)