Мудрість використання відкритого коду в комерційному програмному продукті

Я розглядаю використання відкритого коду у моєму веб-додатку ASP.NET (зокрема, dapper ). Управління не є фанатом, тому що відкритий код розглядається як ризик, який нас покусав раніше. Мабуть попереднім розробникам довелося переписати речі після виходу з ладу компонентів з відкритим кодом.

Плюси, здається, такі:

• Для мене це багато чого, що в протилежному випадку передбачає або багато кодового шаблону, або рекомендоване, але повільніше рішення Microsoft (Entity Framework).

Мінуси:

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

Який тут консенсус? Чи нерозумно використовувати відкритий код у своєму проекті, який я не знаю / не розумію так добре, як і власний код?

Це вибір, який вам доведеться зробити, виходячи з конкретних обставин. Ви можете пом'якшити свої ризики:

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

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

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

Після того, як ви почнете заходити у свій бізнес-домен, вам буде важче знайти ОС, що відповідає вашим потребам. Але не потрібно повторно впроваджувати ще один продукт ORM. Якщо дапер досить складний, що ви не зможете налагоджувати та виправляти їх код, як би ви виправдали витратити всі години людини на його написання з нуля? Крім того, ви могли (повинні?) Завжди дивитись поза коробкою на рішення NoSQL, а ваші на це.

Навіть Лінус зізнався, що намагався знайти рішення SCM, яке відповідало б усім його критеріям, перш ніж розвивати Git. Принаймні, він зміг пояснити, чому жодне з існуючих рішень не було достатньо хорошим.

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

Примітка. Я не є працівником Microsoft. Думка абсолютно особиста. Багато думок за останні 5-7 років використання як відкритого джерела в поєднанні з великими постачальниками в якості розробника.

Монокультура - це добре: моє особисте правило для ASP.NET - надавати перевагу Microsoft та не вибирати код сторонніх розробників (відкритий чи ні), якщо іншого вибору немає. Монокультура є корисною, оскільки вас переносить великий постачальник, і кількість користувачів, які повторюють один і той же досвід, у будь-який час достатньо велика, щоб отримати допомогу та знайти вирішення.

Міста-привиди: Проблема з відкритим кодом у 2012 році полягає в тому, що це вже не 2000 чи 2005 роки. Кількість проектів постійно зростає, коли кількість користувачів, усиновлювачів, учасників - приблизно така сама, як і роки тому. Аудиторії розтягнуті тонкими. Багато цікавих проектів стали несвіжими, покинутими. Не існує такого поняття, як бюджет проекту з відкритим кодом. Тож коли інтерес закінчується, немає кому чесно оголосити, що підтримка закінчена і вимкнути світло. Проекти ніколи не вмирають, щоб зосередити увагу громадськості на чомусь кращому та новому. Тож відкритий код завжди буде рости та фрагментуватися. Не маючи зворотного зв’язку у вигляді грошової винагороди чи фінансової смерті, вони невмирущі сутності, що існують заради вічної слави.

20 ступенів розмежування: кожне прийняття вами нової бібліотеки відокремлює вас від основної течії, перетворює вас на меншість крайових справ. Після 20 кроків, як вибір конфігурації безпеки, використання конкретної версії, фреймворка, плагіна тощо. Ваше рішення стає єдиною глобально унікальною комбінацією деталей. Гуглінг допоможе лише довести, наскільки рідкісна або унікальна проблема. Це завжди якась корисна проблема, чисто технічна. Ніколи навіть не стосується реального бізнесу.

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

Консенсус: Ви запитуєте, чи є консенсус. Можливо, ні. На жаль, велика кількість користувачів з відкритим кодом занадто політизована. Адже відкритим кодом є соціальний рух. Відкритий джерело не застрахований від критики, оскільки дуже часто негативна думка буде сприйматися як антитехнологічна, особиста атака. Мій особистий консенсус: дотримуйтесь Microsoft.

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

Є сотні ліцензій з відкритим кодом, але вони, як правило, поділяються на дві категорії, стиль BSD та GPL. Ліцензії стилю BSD не вимагають від вас відкривати вихідний код власного коду, і, як правило, є лише якесь застереження про атрибуцію. Ліцензії стилю GPL вимагають відкриття вихідного коду власного коду. Більшість компаній (включаючи мою), як правило, дивляться на це, тому ви хочете уникати стилю GPL. Схоже, Dapper використовує ліцензію Apache, що є стилем BSD. Завжди з’ясовуйте, які загальні умови ліцензії, перш ніж розпочати кодування.

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

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

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

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

Здається, ви хочете використовувати зрілі проекти, які пропонують підтримку. Деякі проекти з відкритим кодом пропонують платну підтримку або мають достатньо велику спільноту, на яку можна отримати відповіді на публічному форумі. Можливо, вам слід визначити пріоритети зрілості та критеріїв підтримки при виборі бібліотеки, будь то закрита чи відкрита.

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

Припускаючи, що проблеми з ліцензуванням тут не є жодною проблемою: швидко ознайомившись із Dapper, я помітив, що у ньому було всього 2255 рядків добре задокументованого, читабельного коду . Тобто

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

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

Що ви повинні зробити тут, однак, якщо ви впроваджуєте такий фрагмент з відкритим кодом у свій проект, тоді ви повинні взяти на себе всю відповідальність за цей код так само, як якщо б ви його написали самі. Переконайтесь, що код знаходиться у стані, який ви можете підтримувати, якщо необхідно. Не звинувачуйте "авторів" цього коду, якщо щось не працює, як очікувалося.

В одному з наших проектів ми також представили деякі компоненти з відкритим вихідним кодом - від розмірів, малих як Dapper, до бібліотек, які мали від 20 до 30 К рядків коду. Нам завжди доводилося вносити якісь зміни, виправляти помилки, зменшувати щось тощо, але це було нормально, оскільки ми цього очікували. Навіть час налагодження налагодження, використовуючи відкритий код, заощадив нам багато роботи.

Тут варто задуматися: у вашому випадку ви зазначаєте, що існує широка прийнята альтернатива від великого постачальника (MS Entity Framework, за який вам не доведеться платити додаткові ліцензійні внески!). Ви не хочете використовувати його через міркування щодо продуктивності. Я серйозно рекомендую не допускати, щоб продуктивність була єдиною або первинною точкою, яку слід розглядати. Питання, які вам слід задати тут: чи має Dapper весь функціонал, який вам потрібен зараз, і протягом очікуваного терміну служби вашого програмного забезпечення? Або ви можете передбачити, що ви швидко досягнете меж Dapper, і вам доведеться додати багато відсутньої функціональності навколо нього, чого вам, мабуть, не довелося б, якби ви вирішили використовувати EF в першу чергу? У останньому випадку я рекомендував би не використовувати Dapper. Також запитайте себе: чи дійсно EF не достатньо швидкий для вашої заявки,

Як я бачу, це врівноважуючий акт.

Якщо ви зробите себе залежним від постачальника, майже впевнено, що підтримка зникне недовго

• Оскільки програмісти мають платити, тому їм потрібно продовжувати робити нові версії та переконуватись, що старі неможливо отримати та більше не працюватимуть (на нових платформах), тому нові матимуть ринок.

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

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

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

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

Запитайте у керівництва, чому воно раніше не вдалося, чи було проведено достатню ретельність?

jquery має можливість використовувати ліцензію MIT, тому багато комерційних та урядових веб-сайтів також використовують jquery. Веб-сайт Microsoft також використовує jquery! Тож турбота стосується ліцензування. Уникайте використання GPL / LGPL достатньо.

"Як довго отримати виправлення повідомленого дефекту?" Після повідомлення про помилку вона може бути виправлена ​​протягом декількох хвилин, годин або днів. Для нагальної ситуації персонал може просто "натягнути", щоб дістати джерело і скласти його самостійно. Він просто доповідає керівництву про версію типу "v1.2.3-101-gd62fdae", яка простежується.

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

Ви впевнені, що проблема управління - це технічні проблеми.

Я кажу про це, оскільки змішання ОС та комерційної діяльності - це законне поле для шахт, і більше ніж один менеджер мав "Будь ласка, поясніть" від юридичної команди / генерального директора або ще гірше, від іншої організації. Більшість менеджерів, яких я знаю, навіть ті, хто активно охоплює програмне забезпечення ОС, (по праву) дуже обережні, щоб повністю зрозуміти правові ситуації, до яких вони піддаються. Якщо ви приймаєте програмне забезпечення ОС і вносите зміни, ви зобов'язані повернути ці зміни до спільноти. В одних випадках це зобов’язання є законним, в інших - моральним. У деяких ліцензіях на ОС все, що ви робите, стає ОС лише шляхом посилання на них.

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

І ще один момент, який слід пам’ятати - «Ніхто ніколи не звільнявся, купуючи IBM». (тобто керівництво говорить за "Якщо ви витрачаєте багато грошей, це повинен бути кращий продукт, ніж той, який є безкоштовним"