Як дізнатися, чи проект з відкритим кодом достатньо зрілий для використання у продукті?

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

Тепер я трохи стурбований кількістю ризику, якому я піддаюся, використовуючи проект з відкритим кодом joe-blow. Якщо мені потрібно 95% шляху, можливо, решту 5% легко додати чи виправити. Можливо, це нетривіально.

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

Це не хобі-проект, тому стабільність, ремонтопридатність тощо є першорядними.

Я використовую критерії, якщо проект відповідає моїм вимогам:

1. Чи існує активна спільнота з людьми, здатними надати допомогу?
2. Чи відповідає ліцензія моєму розвитку?
3. Чи все ще продукт активно розвивається?
4. Це загальновживаний фреймворк?
5. Чи можу я знайти будь-які відгуки / повідомлення в блогах / тощо продукту та як люди інтегруються з ним?

4 і 5 насправді не допомагають нішевим проектам, які, схоже, є вашими.

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

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

1. Що стосується фреймворку, то, як правило, я маю лише великі та зрілі рамки з великою кількістю попередньо написаних модулів та великою спільнотою. Взагалі, вибір одного фрейму над іншим насправді не значно зменшить кількість роботи, яку потрібно витратити на власний код, деякі рамки можуть сприяти більш красивому коду, інші можуть полегшити певні операції, але вони, як правило, підсумовують дуже незначна різниця в загальних зусиллях з розвитку. Однак популярні фреймворки мали б більше заздалегідь написаних модулів, на які ви можете скористатися, і саме так ви можете заощадити набагато більше часу та зусиль.
2. Для невеликої бібліотеки, яка не є рамковою, зазвичай ви можете самостійно вносити зміни, якщо це потрібно без особливих проблем, тому зазвичай я вважаю, що спільнота є додатковим бонусом. Більшістю невеликих бібліотек керує лише одна людина, але вони все ж краще, ніж самі будувати. Однак для великих бібліотек важливо мати зріле, активне співтовариство та документацію, оскільки ви навряд чи зможете самостійно вносити зміни.
3. Ліцензія є важливою. Для бібліотек, що мають одну людину, ймовірно, вам потрібно буде внести зміни в бібліотеку, тому важливо, щоб їх ліцензія дозволяла робити це за умовами, з якими ви погоджуєтесь.

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

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

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

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

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

Новини не є гарними, але це не означає, що вони невірні: ти не знаєш.

Якби у виробництві були аналогічні реалізації, ви знаєте, що це можливо, але, як ви сказали, жодні «основні гравці» не використовують проекти.

Якби ви розвивалися вдома, то знали б, але, як ви сказали, у вас немає ресурсів.

Розумно хочеться знати, але ... ви цього не робите.

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

Питання потрібно ставити інакше. Що ви насправді запитуєте - це використання цього проекту з відкритим кодом найкращим способом розробки продукту?

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

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