Чи є якісь помітні приклади ділових катастроф, безпосередньо спричинених програмним забезпеченням з відкритим кодом? [зачинено]

У "корпоративних" середовищах я спостерігав сильні упередження щодо власного програмного забезпечення. Навіть у великому бізнесі, який використовує Java, незвично знаходити MySQL або PostgreSQL, а WebSphere та WebLogic настійно віддають перевагу JBoss або Tomcat.

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

Я не задаю питання, чи є Postgres настільки ж хорошим, як Oracle. У цьому справа не в цьому. Oracle не обирається після Postgres після ретельного розгляду особливостей та орієнтирів. Postgres не вступає в розмову, оскільки вільне програмне забезпечення в певних місцях не довіряється.

Мені цікаво, якщо ця недовіра виникла у відповідь на якісь конкретні події. Отже, моє запитання таке: чи існують задокументовані випадки нещасних випадків у бізнесі (збої, значна втрата доходу, значні втрати корпоративних даних тощо), які виявились наслідком недоліків програмного забезпечення з відкритим кодом?

Пояснення: Якщо у вас є досвід роботи з компаніями на рівні підприємств, які повністю застосовують ОСЗ, які мають упереджувати питання, але робити вибір, виходячи з потреб конкретної ситуації, тоді добре для вас! Ваш досвід не змінює той факт, що інші підприємства підприємств мають зовсім інше ставлення, і моє питання справедливе, навіть якщо ці компанії є меншиною.

Чи є якісь забобони, так, можливо, в деяких випадках. Однак для великих організацій цей шлях до дорогих фірмових серверів додатків та інших дорогих програмних пакетів надав їм певні переваги та цінні папери, про які рідко думають.

1) Підтримка : Зазвичай, коли велика корпорація має програмне забезпечення на мільйон доларів, підтримка вкладається в контракт. Мені не потрібно заглиблюватися в переваги наявності додатків.

2) Посилення : Дороге власницьке програмне забезпечення, особливо нішеве програмне забезпечення, має менше клієнтів та незалежних користувачів. Якщо великий корпоративний клієнт вирішить не продовжувати контракт, це може серйозно позначитися на нижньому рядку постачальника. Багато з них використовують цей важіль для пошуку функцій та виправлень, на які вони не зможуть вплинути на програмне забезпечення з відкритим кодом. Аргумент для open-source стверджує, що велика корпорація може внести свої власні зміни та особливості в проект на благо всіх, але це залучає розробників час, якого вони намагаються уникати.

3) Безпека . І я не маю на увазі це як шифрування, так і брандмауери та інше. Проекти з відкритим кодом відкриваються, деякі з них широко підтримуються і перевершують фірмове програмне забезпечення. Багато хто провалюється або просто втрачає вкладників з часом. Якщо вони затримаються з цим програмним забезпеченням протягом 20 років вниз, чи буде спільнота з відкритим кодом продовжувати підтримувати це? За допомогою власного програмного забезпечення гроші, які ви платите як клієнт, заохочують продавця залишатися в бізнесі, поки ви продовжуєте його платити.

Що стосується історії, коли відкритий код вибухнув в моїх компаніях, це тривалий проект, який було розпочато на основі нечасто почутого про MapM Mapper, який був відкритим кодом. Проект просто припинився, коли основний довідник помер або щось подібне, тоді компанія залишилася з дорогими зусиллями по реконструкції, щоб переїхати до власної бібліотеки. Трапляється, і подібні сценарії відлякують лайно великих корпорацій.

Я ніколи не чув про якісь проблеми, які були наслідком використання продукту з відкритим кодом. Я думаю, що причина турботи пов’язана не з історичною невдачею, а з чимось іншим.

Коли ви використовуєте комерційний продукт для якогось завдання, а щось піде не так, зазвичай у вас є хтось, кого можна зателефонувати за підтримкою. Ця особа (і компанія) зазвичай зацікавлені у вирішенні проблеми, тому що якщо вони не допоможуть, завжди існує загроза, що ви перестанете давати їм гроші.

До кого ви можете зателефонувати чи зв’язатися із продуктом з відкритим кодом? Спільнота? Оскільки ви нічого не дали їм за використання продукту, ви не можете погрожувати забрати. Ви можете подати звіт і сподіватися, що він буде виправлений у наступному випуску, але дуже важко передати почуття актуальності туманній спільноті людей, які працюють за власним часом .

Отже, продукт з відкритим кодом може значно перевершити комерційну альтернативу, але, принаймні, на моєму досвіді, у корпоративному середовищі, де вам доведеться планувати випадок надзвичайних ситуацій, якщо з цим щось піде не так, не маючи кому отримати підтримку - це велике угода.

Це бар’єр, який я завжди бачив.

Я підозрюю, що такі компанії, як Oracle, більше відносяться до інших компаній з метою отримання прибутку; вони не можуть уявити, що організація може вийти продуктом, який є таким же хорошим, як Oracle, не маючи при цьому прибутку. Звичайно, PostGres не зовсім некомерційний; є ціла екосистема постачальників послуг, яка продаватиме вам підтримку.

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

Враховуючи це, я не чув жодної реальної катастрофи, яка спіткала компанії, тому що вони вирішили використовувати базу даних з відкритим кодом. Якість програмного забезпечення, наявного в цьому просторі, є досить хорошим, конкуруючим і (в деяких випадках) перевершуючи їх комерційні аналоги.

Щоб протиставити аргументацію OSS як фактор ризику, я хочу навести протиприклад SAP, який часто наводять як головний фактор неплатоспроможності малих та середніх підприємств - тут наведено один приклад: http: //www.intl- спектр.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? Я впевнений, що кілька веб-сайтів, які працюють на ньому, були зламані з точки зору затрат грошей, але чи звинувачували вони у відкритих джерелах або тих, хто відповідає за погану установку? Що є альтернативою приналежності залізо?

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

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