>> Community-driven development изначально предполагал, что все члены сообщества вносят свой вклад
> Возможно. А как оно сейчас в реальности?
>> community-driven development ... всегда была в осознанном выборе и поддержке пользователем вполне определённой модели разработки.
> А оно работает сейчас? То что я вижу - все немного по-другому. А как было, так и остаётся. Очевидно, что вы хотите как-то отталкиваться от того, что далеко не все пользователи отправляют баг-репорты. Но это не так уж важно: даже небольшой процент пользователей, клепающих баг-репорты -- это уже большое подспорье производству, потому как больше всего времени и средств уходит именно на интеграционное тестирование. Об этом писал ещё Фредерик Брукс в 75м, и за полвека, прошедшие с тех пор, ситуация нисколько не изменилась.
> И второй вопрос - могут ли вообще разрабатываться настолько большие и сложные проекты используя такой подход?
Вот, это хороший и правильный вопрос. Чтобы на него ответить, надо сделать важное отступление.
Успех любого проекта зависит не столько от выбранного подхода, сколько от наличия в нём носителя воли. Что в соборной среде (company-driven development), что в базарной (community-driven development) -- это человек (или группа людей), который пропускает через себя весь проект и принимает решения по всем архитектурным вопросам. В соборной среде его обычно называют архитектором, в базарной -- по-разному, но зачастую он известен как BDFL. У этих людей есть общая черта -- их что-то мотивирует сделать хороший продукт. Неважно, что именно: перфекционизм, аспергер, тщеславие -- что угодно. Но это не деньги.
Далее, совсем не обязательно выбирать что-то одно. Соборные и базарные методы не противоречат друг другу. В целом разумным подходом является их совмещение. Безусловно, иметь собственную команду QA -- это существенный буст разработки, потому что они дают фидбэк на постоянной основе. Но они всё равно не покроют всех сценариев использования, и не отловят все ошибки. Поэтому полноценное интеграционне тестирование можно произвести только на пользователях. Вопрос лишь в том, на каком этапе какие части этих подходов более необходимы.
Но пора подводить к мысли. Примеры BDFL нам известны в большом количестве: Линус Торвальдс, Ричард Столлман, Ксавьер Лерой, Лэри Уолл, Брэм Коэн... Список можно в принципе продолжать ещё долго. Так что ответ на ваш вопрос -- да, используя базарный подход, можно разрабатывать настолько большие и сложные проекты.
>> частная компания может оплачивать труд разработчиков
> Да, именно так пишутся все (известные мне) большие проекты. Если есть примеры где это "правило" нарушено - с радостью услышу их и поищу что у них за процессы.
Думаю, вас не затруднит самостоятельно найти проекты выше перечисленных людей.
>>> Т.е. разраб должен еще поблагодарить пользователя, который сэкономил свои деньги, за то, что тот соизволил воспользоваться софтом
>> Тогда давайте посчитаем, сколько же пользователь экономит, выбирая бесплатный дистрибутив GNU/Linux
>> Лицензия на Windows 11 стоит 145 евро. Лицензия на RHEL Workstation стоит $180
> Вот только Windows 11 Pro - $199.99 с флешкой. А Microsoft Windows 11 Pro for Workstation стоит €209.95.
> При этом для обычного пользователя что убунта бесплатная, что винда (включена в стоимость ноута со смешным oem прайсом в 10-15 баксов).
Ну что значит "вот только". Вы же и сами видите, что величины по порядку одинаковые: это всё копейки по сравнению с железом. И следовательно тыкать пользователя в то, что он якобы сэкономил -- не имеет смысла. Вполне очевидно, что выбрать то или иное ПО пользователя мотивируют вовсе не деньги.
А отсюда важный вопрос: как вы думаете, что мотивирует пользователя выбрать именно ваш продукт?
>> IT-производство помимо разработки включает в себя и другие шаги, из-за чего ставите одно из звеньев неоправданно высоко.
> Конечно. Проф. QA, автотестирование, разработка тест-кейсов, администрирование и поддержка инфраструктуры.
Значит, по поводу неоправданно завышенной оценки роли разработчиков в производстве IT-продукта -- возражений нет. Если так, то это хорошо: это уже существенный шаг к взаимопониманию.
> все оно требует денег для профессионалов, а не для "вот что-то крешнулось, держи репорт и исправь побыстрее!!1"
А пользователи, посылающие вам баг-репорты, денег не получают вообще никаких. Пользователь всегда может просто перестать пользоваться вашим продуктом, и поставить себе что-нибудь ещё. А он вместо этого тратит своё время, общается с вами, вместе с вами дебажит, предоставляет дополнительную информацию по вашему запросу: словом, помогает сделать вашу программу лучше. Конечно, не все пользователи предоставляют хороший баг-репорт, и не все оперативно отвечают. Но это всё равно лучше, чем не иметь никакой обратной связи.
> Все только поливают шапку и требуют чтобы она продолжила тратить свои деньги чтобы им было хорошо.
Я трижды это повторял в давешней теме про RHEL10, но я не в курсе, тот же ли ты аноним, так что повторю ещё ровно один раз.
Дело вовсе не в Xorg:
- Пользователи плевать хотели на Xorg, их устроит любой аналог, который обеспечит им стабильную работу с их ежедневно используемым софтом
- Пользователи преимущественно обеспокоены тем, что ни одно внедрение нового продукта от компании Red Hat не происходило без косяков
- Пользователи видят, что на данный момент Wayland категорически не готов стать полноценной заменой Xorg
> "вот что-то крешнулось, держи репорт и исправь побыстрее!!1"
А ведь вы начинаете вот такие вот вещи писать при одном только упоминании взаимодействия пользователя с разработчиком. Есть подозрение, что ваш опыт общения с пользователем был какой-то крайне неудачный. Как будто вы работали в коммерческой опенсорс-компании, и у вас был KPI, завязанный на обработку поступающих заявок. Может расскажете, что вас так надломило?