Нет (с)

В общем случае это неверно. В частном случае - как повезёт.

Вот ты нашел в проприетарном приложении или ОС какой-то баг. Допустим, ты зарепортил его, но исправлять по очевидным причинам все равно будешь не ты. Поскольку вопрос исправления в конечном счете упирается не в тебя, то с виду кажется, что ты полностью бесправен и вынужден надеяться на дядю-проприетарщика. А в случае со свободным ПО ты вроде бы можешь сам взять и починить, и ни от кого в этом не зависишь.

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

Нюанс первый - в случае с проприетарщиной дядя куда чаще заинтересован в том, чтобы баг был исправлен. Дядя, конечно, не всегда будет ночами впахивать ради его исправления, но в общем и целом при наличии свободных ресурсов вашим багом кто-нибудь да займется. В некоторых случаях (я слышал, что такое практикуется, например, в JetBrains) при наличии трудновоспроизводимого бага клиента просят предоставить удаленный доступ, чтобы инженер технической поддержки мог сам диагностировать проблему. В конторе, где я работаю, разрабатывают проприетарный софт (он жутко специализированный, и его по ряду других причин невозможно сделать free software). У нас во всех без исключения случаях при баг-репорте в случае невозможности воспроизвести баг у разработчиков просят клиента дать удаленный доступ. Если удаленный доступ невозможен - к клиенту за счет конторы-разработчика выезжает инженер технической поддержки, а в некоторых случаях и инженер из команды разработки. Последнее, кстати, бывает очень полезно - ничто не мотивирует писать нормальный код и тестировать его, как необходимость в случае чего лететь через полстраны в какую-нибудь задницу, где, сидя в едущей по российским дорогам машине или неотапливаемом помещении с крысами, нужно на ноуте без питания успеть отладить программу до того, как кончится заряд.

В случае со свободным ПО мне придется или покупать очень недешевый контракт на поддержку у какого-нибудь RedHat, или самому искать баг, писать патч, отсылать его и - главное - убеждать разработчиков в том, что это именно баг, что он может проявиться, и что патч этот баг исправляет и ничего при этом ни у кого не сломает. Первый случай на самом деле не очень-то отличается от работы с проприетарщиками - всё, что мне остается, это надеяться на инженеров RedHat или другой конторы, с которой у меня контракт. Если баг - критический для моего бизнеса, то мои тестикулы опять же в руках у них, а не у меня, и чем это в итоге отличается от работы с каким-нибудь Microsoft?

Что касается второго случая, то здесь тоже будет масса подводных камней. Начнем с того, что все баг-фиксы придется в том или ином виде отправлять в апстрим, потому что в противном случае я стану майнтайнером форка проекта. А мне мое руководство платит отнюдь не за это, а за то, чтобы я решал их бизнес-проблемы. Если же баг-репорты и патчи отправлять в апстрим, как и задумывалось в свободном ПО, то и тут есть масса нюансов. Что делать, если мой баг воспроизводится только у меня? Где гарантии, что мой баг-репорт не закроют со словами "не проявляется" или коронными "это не баг, а фича", "не жми эту кнопку сразу после той, подожди 5 минут"? Что делать, если (как недавно писал здесь Пох на тему ZFS ARC во FreeBSD) в апстриме что-то сломал очень уважаемый человек, коммиты которого не принято подвергать сомнению?

Но это все цветочки. Ягодки - это когда баг происходит или вообще непонятно где, или там, где черт ногу сломит в попытках найти точное место, где он окопался. Вот был у меня случай: при загрузке Линукса на одной из ЭВМ примерно в 15% случаев переставал быть видным корневой раздел, после чего ядро не могло подгрузить нужные модули, и загрузка останавливалась. Причем проблема, если верить гуглу, больше ни у кого именно в таком виде не проявлялась. Ладно, я в общем-то знал, в какую сторону копать и что в таких случаях делать. Что будет делать средний Васян, который может и умеет писать программы на C, и линуксом пользуется лет 10, но конкретно в отладке процесса загрузки Линукса - ни ухом, ни рылом? Что он будет делать, если это происходит на его единственной рабочей станции? Сильно ему поможет наличие исходников?

Ну и наконец третий нюанс. Современное ПО - неважно, свободное ли, проприетарное - столь отвратительно спроектировано и столь ужасно и излишне сложное, что поиск почти любого бага превращается в целый квест. А если этих багов тысячи?

Посмотрите, например, на две смежные экосистемы свободного ПО. Первая - это графическая подсистема Линукса (включая userspace), вторая - это ускорение вычислений на GPU. Вот скажите мне, что именно нужно исправить в первой, чтобы она заработала нормально? Там не исправлять надо, а выкидывать и переписывать заново вообще ВСЁ, включая относительно свежего Вяленого. Не верите - посмотрите на блок-схему, как устроен графический стек в Линуксе. И сравните с тем, как он устроен в винде, макОс, айос или даже в том же Андроиде (Гугл совсем не случайно не стал связываться со всем этим цирком).

То же самое в принципе и со вторым - с GPU compute. Тут не так давно на опеннете была новость с блок-схемой инфраструктуры. Лично мне легче периодическую таблицу им. Менделеева наизусть выучить, чем это! Ну и практика подтверждает: все вменяемые люди, кому нужно считать на видеокартах, пользуются проприетарной CUDA. Почему? Ведь в свободном ROCm в теории легче исправить баг, исходники ведь доступны. Проблема в том, что багов в ROCm и в драйверах AMD столько, что любой, кому нужно все-таки ехать, а не шашечки, махнет рукой на это счастье. И сложность процесса исправления этих багов средним или умеренно крутым Васяном будет такова, что ему легче себя в копчик поцеловать, чем что-то там выправить. Кстати, в ROCm от AMD, который free software и который на днях релизнулся новой версией, до сих пор нет поддержки видеокарт Navi, хотя они вышли на рынок уже год как. И чего-то из миллионов глаз не найдется ни одной ловкой руки, которая бы взяла и добавила поддержку, хотя AMD и спеки на аппаратуру выкладывает.

Я хорошо помню, что писал RMS по поводу причин, побудивших его основать идеологию - про драйвер на принтер, в котором он нашел баг, исправил его, но исходники закрыли, а его послали нафиг. Главное в свободном ПО - это принцип того, что лучше всего именуется испохабленным леваками словом "инклюзивность", т.е. в оригинале - возможность любому принять участие в разработке и не быть отвергнутым. Давайте посмотрим правде в глаза - в 2020 году немало свободного ПО этому главному принципу уже не соответствует. Либо слишком сложно, либо слишком много политики.

Поэтому на первом месте - именно работающий продукт. По крайней мере, для тех, кому все-таки ехать, а не шашечки.