На якому етапі проекту з відкритим кодом слід запросити внески від громади? [зачинено]

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

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

Отже, питання: на якому етапі проекту з відкритим кодом ви повинні запросити внески від громади?

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

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

Ви можете пом'якшити проблему "дизайн за комітетом", виклавши чітке бачення у своїх початкових повідомленнях до списку розсилки, наприклад

"Отже, ми розглядаємо доменну модель, яка представляє наш зоомагазин (відповідно до JIRA-4). Хтось бачить якісь основні проблеми з цією моделлю?"

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

Крім того, заплачено мати стандарти проекту на Wiki або якийсь такий документ.

Прочитайте http://www.producingoss.org для отримання більш детальної інформації про те, як запустити успішний проект з відкритим кодом.

Про це детально йшлося в дискусійному форумі google IO Myth про геніального програміста Брайана Фіцпатріка та Бена Коллінза-Суссмана з Subversion. Коротше кажучи, вони зробили висновок, що не повинно бути так рано, що там ще нічого немає (т. Е. "Приходьте подивіться на мій дивовижний проект! Тут ще не дуже багато, але заплановано багато дивовижних речей!") Або занадто пізно тому всі рішення вже прийняті (важко домогтися слова в сольному проекті.)

Я згоден з Мартійн Вербург . Слід почати просити внески вже з самого початку. Я раніше про це трохи писав .

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

Насправді це дуже поширена проблема. Існує велика розмова Fat під назвою Що таке відкритий код і чому я відчуваю себе таким винним? У цій розмові (яку я дуже рекомендую вам переглянути) він розповідає історію одного зі своїх проектів OSS, і про те, як з часом він виявив, що проводить більшу частину свого вільного часу, роблячи триаж на квитки та завдання управління. І він говорить про те, наскільки це було згубно. Що я можу повністю співпереживати.

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

Як я кажу в кінці свого допису: "Що важливіше для вашого проекту: особливості чи майбутнє? Виберіть один і відповідно визначте свої зусилля".