Створення програми з відкритим кодом
Тут ми обговорюємо основні зауваження щодо створення програми з відкритим кодом.
Що ми маємо на увазі під фразою "з відкритим кодом?".
Програма з відкритим кодом – це більше, ніж загальнодоступний доступ до кодової бази. Мова йде про відкриття живого проекту для участі будь-кого, хто хоче взяти участь. Якщо проект виконується належним чином, програма з відкритим кодом може суттєво покращити якість продукту.
Одна з ключових причин, чому компанії відкривають проекти з відкритим кодом, полягає в тому, що вони хочуть, щоб спільнота брала участь. Популярні проекти отримують значний внесок від спільноти, і вони отримують його безкоштовно.
Це не обов'язково виходить з альтруїзму. Люди та організації споживають проекти, оскільки бачать особисту або ділову вигоду. Якщо проект не відповідає їхнім потребам або очікуванням, він може скористатися можливістю для усунення помилок або додавання функцій. Замість того, щоб утримувати ці вдосконалення в приватних вилках, вони змушені внести свій внесок ці зміни назад у вихідне сховище, щоб стати частиною базового плану проекту. Цей доброчесний цикл вдосконалення полягає в тому, чому багато підприємств виробляють програмне забезпечення за допомогою моделі з відкритим кодом.
Цілі з відкритим кодом
Щоб повторити, є три виміри для участі в програмному забезпеченні з відкритим кодом:
- споживачів, які вивчають або використовують репозиторії інших користувачів.
- співавтори, які активно беруть участь у вдосконаленні репозиторіїв інших користувачів.
- виробники, які будують і підтримують власні репозиторії, відкриті для інших.
Оскільки організації глибше думають про те, що вони хочуть вийти з кожного виміру, це хороша практика, щоб запастися тим, де вони знаходяться сьогодні. У кожному вимірі є п'ять рівнів процесу.
- спеціальні, які не мають процесу на місці. Успіх залежить від окремих зусиль.
- керовані, які мають частково задокументований процес. Успіх залежить від дисципліни.
- Визначені, які мають документований, стандартизований і інтегрований процес. Успіх залежить від автоматизації.
- Вимірювані, які мають кількісно керований процес. Успіх залежить від вимірювання показників від бізнес-цілей.
- Оптимізовані, які мають процес, який постійно і надійно вдосконалюється через інкрементні та інноваційні зміни. Успіх залежить від зниження ризику змін.
Щоб краще зрозуміти, де стоїть ваша організація, перегляньте результати самооцінок з відкритим кодом.
Що слід відкривати?
Багато проектів не призначені для величі з відкритим кодом. Хоча умови можуть відрізнятися залежно від цілей компанії та рівня процесів, нижче наведено кілька рекомендованих умов, які слід враховувати перед відкриттям проекту.
Чи містить проект інтелектуальну власність, яку потрібно захистити? Якщо так, то відкриття його джерела віддасть його значення. Не відкривайте такі проекти, якщо ви не відчуваєте, що переваги переважують ризики.
Проект перебуває в стабільному стані з гарною якістю коду? Проект не обов'язково має бути ідеальним, але потенційні співавтори можуть піти, якщо проект перебуває в жахливій формі, щоб почати з.
Чи корисний проект користувачам за межами компанії? Якщо ні, то ви, ймовірно, не отримуєте ніякої участі.
Чи можуть люди за межами вашої компанії внести свій внесок? Їм потрібен доступ до всіх залежностей проекту, процесів побудови та будь-яких інших даних, потрібних для запуску проекту. Якщо вони не можуть запустити його, вони не можуть внести свій внесок.
Чи має ваша команда смугу пропускання для підтримки програми з відкритим кодом? Якщо ні, зачекайте, доки ви це зробите. Якщо проект із відкритим кодом не підтримується, ви можете втратити можливість створити надійну спільноту.
Ці питання є лише кількома з найбільш поширених міркувань. У вашій організації можуть виникати інші проблеми з веденням бізнесу або відповідністю вимогам, які слід пам'ятати.
Розробка відкритої програми
Запуск відкритої програми схожий на запуск програми InnerSource, але для загальнодоступної аудиторії. В результаті є ще кілька міркувань.
Установлення очікувань спільноти
Такі файли, як README.md та CONTRIBUTING.md, ще важливіші, тому що вони піддаються впливу людей, які не мають контексту вашої організації. Вони повинні бути оцінені з точки зору когось за межами компанії, щоб забезпечити ясність.
Крім того, важливою політикою є кодекс поведінки. Стандарт – додати файл CODE_OF_CONDUCT.md до кореня сховища та використовувати його, щоб пояснити поведінку, очікувану від учасників спільноти. Цей документ має переглядати кілька груп у вашій організації, включно з юридичною групою. На щастя, існує багато стандартних кодексів поведінки, з яких можна почати. У багатьох проектах ці коди as-is без змінення. Докладні відомості див. в посібнику з відкритим кодом поведінки.
Підготовка працівників до ведення сховища
Можливо, працівники не мають досвіду роботи зі спільнотою з відкритим кодом. Щоб допомогти їм підготуватися, ми рекомендуємо компанії запропонувати набір посібників, які охоплюють ключові речі, які повинні знати всі, перш ніж вони приступають до роботи. Ці посібники слід опублікувати у внутрішньому сховищі або на порталі, який регулярно підтримується та доступний лише для працівників компанії. Нижче наведено кілька найважливіших посібників.
Посібник "Чи повинні ми відкривати цей проект?", який надає основу для прийняття рішення про те, чи слід проект-кандидат бути відкритим. Цей посібник можна структурувати як блок-схему, набір запитань або список міркувань.
Контрольний список настроювання , який містить усі робочі елементи, які команда має виконати до та після запуску проекту з відкритим кодом. Цей список має включати отримання схвалення на відкриття проекту, перегляд коду, щоб переконатися, що конфіденційні дані видаляються до виходу проекту в прямий ефір, торговельної марки або пошуку проекту з відкритим кодом, щоб переконатися, що конфлікт іменування не існує тощо.
Список контактів для ключових користувачів у вашій організації, до яких, можливо, знадобиться звернутися, якщо потрібна пряма підтримка від супроводжувачів. До цього списку мають належати люди з безпеки програмного забезпечення, безпеки сайту, юридичних осіб, зв'язків із громадськістю тощо.
Посилання на початкове сховище, яке можна клонувати як відправну точку. Він має містити зразок README, ліцензію, правила поведінки, посібник з надання підтримки та будь-які інші допоміжні файли, які має мати кожен проект з відкритим кодом від вашої компанії. Вона не повинна містити нічого, що ви не хотіли б випадково підштовхнути до публічної аудиторії.
Посібник супровідника, який пояснює обов'язки, які має супроводжувач у підтримці здоров'я сховища. Ці обов'язки включають своєчасне підтримання документації сховища, забезпечення проблем і витягування запитів своєчасно привертають увагу потрібних людей тощо.
Посібник зв'язку, який пропонує супровідні вказівки для сховища для деяких тем, які ви не хочете включати в загальнодоступні файли, як-от
README.md,CONTRIBUTING.mdабоCODE_OF_CONDUCT.md. Ці теми можуть бути конфіденційними для бізнесу, наприклад, не обговорювати конкурентів; або більш загальні теми поведінки, наприклад, як належним чином розпізнати провідних співавторів.внутрішні запитання й відповіді, які надають затверджені відповіді на поширені запитання. Цей список особливо корисний, якщо існують юридичні тонкощі для тем, які ваша компанія може обговорити під час підтримки програми з відкритим кодом.
ліцензійної політики, у якій перелічено ліцензії, які були затверджені або відхилені юридичним відділом для використання або внеску з відкритим кодом.