На минулому в Остіні конференції OSCON (Open Source Convention) з доповіддю, присвяченому специфіці великомасштабних відкритих розробок, виступила Джессі Фрезелье, яка брала ключове участь в проектах Docker, Kubernetes і Golang. Таким чином, вона дуже добре знайома з проблемою і її рекомендації заслуговують найпильнішої уваги.
«Зоряний інженер» Джессі Фрезелье відома не тільки своїми технічними внеском в найбільш затребувані відкриті програми, але і принциповою життєвою позицією. Зокрема, в минулому році вона покинула проект Docker через дискримінацію за статевою ознакою.
У своєму виступі вона поділилася з учасниками конференції деякими рекомендаціями, заснованими на багатому особистому досвіді. Поради експерта можна розбити на кілька груп.
Поради по залученню і утриманню учасників
Фрезелье вважає, що важливу роль в залученні нових учасників грає організація трекера проекту. Зокрема, маркування деяких питань, які можуть зацікавити новачків і допоможуть їм швидше інтегруватися в команду.
Особливу увагу слід приділяти відкритості проекту, причому не тільки в технічній галузі. Зокрема, якщо розробка почалася всередині компанії, то напевно їй передувала якась внутрішня дискусія, матеріали яких повинні бути доступні всім.
Зрозуміло справа тут не тільки в відкритості заради відкритості. Учасники проекту повинні бути в курсі динаміки прийняття тих чи інших рішень. В іншому випадку неминучі повернення до того, що вже давно обговорювалося, причому з тими ж самими аргументами. Подібні безглузді витрати часу явно не йдуть на користь проекту.
До того ж рано чи пізно ветеранам набридне пояснювати новачкам одне і те ж. Нещодавно підключилися до проекту учасникам така поведінка може здатися зневажливим, і вони втратять інтерес до розробки.
Обов'язково слід визначити умови для учасників, які планують займатися не програмуванням, а документацією, дизайном або популяризацією рішення. Їх роль не менш важлива і вони також потребують стимулювання.
Чи не кожен новий учасник стає постійним членом команди. Процес переходу слід продумати і в деякому сенсі формалізувати. Добровільні помічники не повинні сумніватися у власному статусі - він повинен бути очевидний.
Час учасників слід поважати. На жаль, про це правило лідери проектів забувають занадто часто. Вони вважають, що очевидне їм автоматично є очевидним всім. Зрозуміло це не так - слід максимально позбавити добровільних помічників від всіляких «накладних витрат».
З цього випливає, що всі внутрішні для проекту процеси слід визначити заздалегідь. Наприклад, якщо який-небудь новий учасник бажає стати мантейнером, він повинен мати можливість зрозуміти, яким чином це досягається.
Поради по вихованню мантейнеров
Очевидно, що мантейнери грають ключову роль в кожному проекті. Тому їх формування слід приділяти особливу увагу. По суті, лідер повинен прийняти якусь політику, спрямовану на підтримку саме таких учасників.
Перш за все, в проекті повинні бути прийняті критерії, яким повинен відповідати мантейнер. Причому НЕ розпливчасті, а максимально конкретні і зрозумілі навіть новачкові.
Лідерам важливо розуміти, що відкритих проектів багато і конкуренція за учасників висока. Якщо амбітному новачкові щось незрозуміло з самого початку, то найімовірніше він знайде іншу розробку, а не витрачатиме час на вивчення організаційних питань.
Мантейнер - це серйозне навантаження і велика відповідальність. Щоб учасники брали це на себе, в проекті повинна бути передбачена система заохочень. Якщо є така можливість, то не тільки моральних, але і матеріальних.
Оскільки великі проекти так чи інакше пов'язані з комерційними компаніями, то останнє особливо важливо. Наївно вважати, що всі учасники будуть альтруїстами - багато хто хоче отримувати за свою роботу гроші і це абсолютно нормально.
Зокрема, потенційний мантейнер повинен мати якісь перспективи переходу з добровільних помічників в штат зацікавленої корпорації. Очевидно, що бізнесу це теж вигідно - фактично він отримує вже повністю підготовленого співробітника, на практиці довів свою компетентність і кваліфікацію.
У великих проектах неможливо зосередити весь контроль в одних руках. Це повинна бути розподілена і досить складна система управління, яку слід створити.
Управління проектом має вирішальне значення. Проблема полягає в тому, що чим проект крупніше, тим складніше реалізувати виконання суто адміністративних функцій, а специфіка Open Source не дозволяє використовувати деякі корпоративні принципи, засновані на суворої ієрархії і матеріальної зацікавленості.
Фрезелье закликає приділяти питанню управління проектом особливу увагу. Саме він може стати тим самим слабкою ланкою, яке помітно знизить ефективність спільної роботи.
Поради по роботі з уразливими
Вразливостей в великому ПО уникнути не можна. Це відноситься як до продуктам великих компаній, так і до відкритих розробок.
Фрезелье вважає, що перш за все процес знаходження і усунення вразливостей слід зробити максимально відкритим. В хорошому результаті зацікавлені всі учасники розробки, тому вони постійно повинні бути в курсі справи.
Зловмисники і так знають про помилки в ПЗ значно більше, ніж хотілося б. Тестери і розробники повинні знати як мінімум не менше. До того ж не виключено, що таким чином вийде залучити в команду людей, що балансують на межі - багато кваліфікованих програмістів займаються пошуком вразливостей «просто так», вони ще не знають, в який бік спрямувати свої сили: до добра чи зла.
Можливо деяких з них ще не пізно перетягнути на «сторону світла». Досить наочно показати, що хакерські навички затребувані суспільством і робота над корисним проектом в складі хорошої команди значно цікавіше.
Окреме питання - інформування користувачів. Керівники проекту повинні бути впевнені, що всі вони знають, як і коли необхідно оновлювати ПО, щоб відчувати себе у відносній безпеці. Звідси особливу важливість набувають учасники, зайняті не написання коду, а популяризацією і технічною підтримкою.
У будь-якому проекті необхідна група технічних письменників, яка буде оперативно і в зрозумілій формі доводити до користувачів важливу інформацію. В іншому випадку зусилля навіть дуже кваліфікованих розробників будуть зведені нанівець звичайної необізнаністю більшості зацікавлених осіб.
Відкритість не повинна мати винятків. Навіть якщо хтось просить «притримати» інформацію до якоїсь важливої конференції, на компроміс йти не варто.
Якщо в процесі роботи з уразливими відбувається якийсь навіть незначний збій, то це повинно стати приводом для серйозного розслідування. Безпека - занадто важлива складова проекту, ставиться до неї легковажно неприпустимо.
Поради по роботі з компаніями
«Just for fun» - це прекрасно. Але значно краще, якщо ентузіазм підживлюється грошима від комерційних компаній. Практично всі великі відкриті проекти працюють саме за таким принципом.
Одна з головних завдань лідера відкритого проекту - знайти баланс між корпоративними потребами і інтересом спільноти. Якщо вийде досягти розумного компромісу, то це вирішить більшість можливих проблем.
Перш за все слід переконати керівництво компаній розглядати співтовариство в якості кадрового резерву. Зробити це, до речі, нескладно - мова йде про людей, про професійні якості яких можна судити не тільки по резюме.
З іншого боку, учасники проекту повинні розуміти, що їх добровільна робота сама по собі нічого не гарантує. Прийом на постійну роботу треба ще заслужити. Open Source - це нові можливості, але не більше того.
Alfresco - платформа ECM, призначена для вирішення завдань управління всім контентом організації. На базі цієї ...
Говорячи про ТСО системи постачальники, як правило, вважають тільки вартість ліцензій. У цьому випадку ціна виглядає більш ...