История изменений

самая главная проблема мантейнеров - нищебродство и недоступность (закрытость или непонтимание) исходников

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

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

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

возникает вопрос, к чему относятся зависимости - к инфраструктуре, или к функциональности приложения. Это фундаментальный вопрос, разграничивающий области ответственности мантейнеров и разработчиков софта. Мне кажется, что зависимости - это дело в первую очередь разработчиков софта. Потому что в зависимости от выбранных зависимостей, приложение может работать по-разному, например, не работать вообще. И установить это смогут только тестировщики компании-производителя, которые сюрприз-сюрприз - обычно не являются мантейнерами дистрибутива.

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

и никаких проблем с этим нет, такой порядок вещей испокон веков уже

самая главная проблема мантейнеров - нищебродство и недоступность (закрытость или непонтимание) исходников

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

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

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

возникает вопрос, к чему относятся зависимости - к инфраструктуре, или к функциональности приложения. Это фундаментальный вопрос, разграничивающий области ответственности мантейнеров и разработчиков софта. Мне кажется, что зависимости - это дело в первую очередь разработчиков софта. Потому что в зависимости от выбранных зависимостей, приложение может работать по-разному, например, не работать вообще. И установить это смогут только тестировщики компании-производителя, которые сюрприз-сюрприз - обычно не являются мантейнерами дистрибутива.

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

и никаких проблем с этим нет, такой порядок вещей испокон веков уже