Существуют ли примечательные примеры бизнес-катастроф, непосредственно связанных с программным обеспечением с открытым исходным кодом? [закрыто]

В «корпоративных» средах я наблюдал сильное предубеждение по отношению к проприетарному программному обеспечению. Даже в крупном бизнесе, использующем Java, необычно найти MySQL или PostgreSQL, и WebSphere и WebLogic сильно предпочтительнее JBoss или Tomcat.

Это очень понятно. Хотя многие разработчики предпочитают Tomcat или Postgres WebSphere или Oracle DB, они не являются теми, кто принимает окончательные решения по этим вопросам. Кто бы ни принял решение относительно того, какие БД и серверы приложений будут использоваться в производстве, он обнаружит, что лицензионные платежи кажутся довольно небольшими по сравнению с тем, что его увольняют за выбор бесплатного программного обеспечения, которое вызвало что-то действительно плохое.

Я не задаю вопрос, насколько Postgres так же хорош, как Oracle. Не в этом дело. Oracle не выбирается из Postgres после тщательного анализа возможностей и тестов. Postgres не вступает в разговор, потому что бесплатному программному обеспечению не доверяют в определенных местах.

Мне любопытно, возникла ли эта нехватка доверия в ответ на какие-либо конкретные события. Поэтому мой вопрос таков: есть ли документированные случаи деловых бедствий (сбои, значительная потеря доходов, значительная потеря корпоративных данных и т. Д.), Которые, как было показано, являются результатом недостатков программного обеспечения с открытым исходным кодом?

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

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

1) Поддержка . Обычно, когда крупная корпорация имеет программное обеспечение на миллион долларов, поддержка включается в контракт. Мне не нужно вникать в преимущества поддержки приложений.

2) Кредитное плечо : Дорогое проприетарное программное обеспечение, особенно нишевое, имеет меньше клиентов и независимых пользователей. Если крупный корпоративный клиент решит не продлевать контракт, это может серьезно повлиять на итоговые показатели поставщика. Многие из них используют этот рычаг для поиска функций и исправлений, которые они не могут повлиять на программное обеспечение с открытым исходным кодом. Аргумент в пользу открытого исходного кода утверждает, что крупная корпорация может внести свои изменения и функции в проект на благо всех, но это потребует времени разработчиков, которого они стараются избегать.

3) Безопасность : я не имею в виду шифрование, брандмауэры и прочее. Проекты с открытым исходным кодом приходят и уходят, некоторые широко поддерживаются и превосходят проприетарное программное обеспечение. Многие терпят неудачу или просто теряют вкладчиков со временем. Если они застрянут с этим программным обеспечением в течение 20 лет, будет ли сообщество разработчиков ПО с открытым исходным кодом продолжать поддерживать это? С проприетарным программным обеспечением деньги, которые вы платите как клиент, побуждают продавца оставаться в бизнесе, пока вы продолжаете платить ему.

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

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

Когда вы используете коммерческий продукт для какой-либо задачи и что-то идет не так, у вас обычно есть кто-то, к кому вы можете обратиться за поддержкой. Этот человек (и компания) обычно заинтересованы в том, чтобы помочь вам решить проблему, потому что если они не помогают, всегда есть угроза, что вы перестанете давать им деньги.

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

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

Это барьер, который я всегда видел.

Я подозреваю, что такие компании, как Oracle, в большей степени связаны с другими компаниями "с целью получения прибыли"; они не могут представить, что организация может выпустить продукт, который так же хорош, как Oracle, не имея при этом мотива прибыли. Конечно, PostGres не совсем некоммерческий; Существует целая экосистема поставщиков услуг, которые будут продавать вам поддержку.

Если вы действительно хотите узнать, какова ахиллесова пята любого продукта, вы можете выполнить поиск в Google по запросу «[название продукта] отстой». Это работает для любого продукта, включая Oracle. В случае PostGres вы обнаружите Postgres DDL Transaction Control Sucks , в котором кто-то описывает гипотетическую ситуацию, когда данные были потеряны на тестовом сервере. Конечно, потеря данных возможна в любой базе данных SQL, если с ней неправильно обращаться.

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

Чтобы противостоять аргументу OSS как фактора риска, я хотел бы привести контр-пример SAP, который часто упоминается в качестве основного фактора несостоятельности малых и средних предприятий - один из примеров приведен здесь: http: //www.intl- spectrum.com/article/359/Migration_to_SAP_from_U2_Causes_Bankruptcy_of_Company.aspx

Это претендует на то, чтобы быть списком 10 главных корпоративных сбоев ИТ: http://www.computerworld.com/computerworld/records/images/pdf/44NfailChart.pdf

В нем представлены три введения продуктов SAP.

Это случай использования того, что пользуется популярностью / устоявшимися, а не новыми и предположительно менее проверенными. Кто-нибудь был уволен за использование Apache? Я уверен, что несколько сайтов, на которых он работает, были взломаны до такой степени, что стоили денег, но обвиняли ли они Open Source или тех, кто виновен в плохой установке? Какова альтернатива железного приличия?

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

Большинство компаний не публикуют плохие новости, поэтому вам повезло, если вы можете получить грязную версию с улицы.