Коли проект з відкритим кодом готовий до виробництва?

Коли ви знайдете нову бібліотеку / проект із відкритим кодом, на які критерії ви звернете увагу, перш ніж включити його у свою вихідну базу.

• Чи є юридичні питання, на які потрібно відповісти?

• Ви шукаєте певну швидкість розвитку?

• Чи є спільнота гулом досить вагомою причиною?

• Чи змінюється ваше рішення, якщо ви є тим, хто на лінії проекту?

• Чи змінюється складність домену чи коду, як ви думаєте про це?

Ось мій контрольний список щодо терміну дозрівання проекту:

Чи досяг проект початковий рубіж?

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

Чи є відповідна документація?

Ідеальний проект запропонував би:

• Посібник користувача з прикладами
• Посібник з інтеграції / розширення, якщо це бібліотека
• Документація API
• Повністю задокументований вихідний код
• Відстежувач публічних випусків

Чи розробники все ж прихильні до проекту?

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

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

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

Чи доступні розробники?

• Чи відповідають вони на помилки?
• Чи надають вони інші засоби зв’язку, крім загального трекера випуску? Це незначний пункт у контрольному списку, однак для окремих проектів розробників альтернативні засоби зв’язку можуть допомогти у випадках, таких як "справа відсутнього розробника" .

Тепер для ваших більш конкретних питань:

Швидкість

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

Сумісність ліцензії

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

Суспільний галас

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

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

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

ВР мудрий: введення нових речей ніколи не повинно здійснюватися без якоїсь форми етапу підготовки / навчання.