Савети за дељење пројеката

Аутор: Никола Харди

Лепотa слободног софтвера лежи у дељењу решења и сарадњи. Због тога је пожељно да негујемо културу дељења кода. Наравно, код је увек боље поделити него га само сачувати, али сам код не значи много. Пројекат је успео тек онда када се око њега створи заједница корисника и програмера, а да бисмо дошли до тог стадијума потребни су неки предуслови. Ево неколико добрих савета.

Као што смо већ рекли, код је увек боље објавити него га чувати само за себе. Ако кажемо себи да ћемо код објавити тек када он буде завршен, то најчешће значи да никада неће бити објављен. Софтверски пројекти готово никада нису завршени. Постоји неколико контрапримера (Докер, Андроид…) где су велике компаније одлучиле да свој код не објаве одмах. То су изузеци који су оправдани код великих компанија које желе да убрзају пласирање свог производа.

Након што сте објавили код, потрудите се да га и одржавате. Уколико имате среће и неко се заинтересује за парче софтвера које сте створили, тај неко ће прво погледати када је постављена последња измена. У случају да је пројекат напуштен, корисници га најчешће неће ни испробати. Дакле, објављујте измене темпом којим их и чините, а не одједном у пакету. Групишите измене у верзију или издање, ако је то потребно.

Сваки пројекат тежи ка томе да има неки свој интерни кодекс. Уколико и оснивач пројекта и његови најближи сарадници крше та (неписана) правила, онда ће то радити и корисници и други програмери. Важно је да се грешке увек пријављују на једном месту, документација скупља на другом, а сугестије прихватају на трећем месту. Макар се дописивали сами са собом, запишите поруку о грешци. Можда ће то неко приметити и послати исправку чак и пре вас!

Важно је имати велике циљеве, али је још важније имати било какве резултате. Боље је имати једну скромну функционалност него ниједну од десет најмодернијих. Због тога се тежи да се што пре стигне до неке функционалности, како би што пре почела да се гради заједница која ће слати повратне информације и помоћ.

„Тресла се гора, родио се миш.” Ако не обећавате много, онда вас нико неће оптуживати да своја обећања нисте испунили и цeниће се било шта штo направите. Због тога је најпаметније хвалити се само урађеним стварима и у вестима објављивати оно шта је до сада направљено, а не оно шта је планирано да буде урађено. ЛиБРЕ! је сјајно место да се похвалите својим пројектом, али тек када имате нешто да покажете.

Пројекат који нема ни *рид-ми* (енг. readme) фајл ће у старту одбити и прве кориснике (енг. early adopters). Наглашавамо, први корисници су ти који ће рад на пројекту учинити лакшим и занимљивијим. Документација не мора да буде опширна. Неки професори се шале и кажу да опширна документација може чак да буде и пресудан фактор при избору софтверског решења по принципу: што тежа документација (у килограмима), то је софтвер бољи. Наравно, то је само шала и документација пре свега треба да буде употребљива, ажурна и поуздана. Треба да обухвата опис функционалности које су имплементиране, пример употребе, начин како се може тестирати, како инсталирати и како се укључити у пројекат. Ово је први контакт са будућим корисницима и рид-ми мора да буде сажет, али садржајан.

Одлучите како желите да прихватите нечију помоћ и дајте примере каква вам је све помоћ потребна. Помоћ може бити у облику тестирања, писања документације, рекламирања, превода, па све до саме имплментације. Неки пројекти очекују измене на одређеној имејл адреси у облику закрпе (енг. patch), а неки други на дописним листама, системима за праћење проблема (енг. bug/issue tracker) или у облику захтева за укључење измена (енг. pull request). Кажите јасно како очекујете измене јер неко неодлучан може да одлучи да продужи својим путем уместо да допринесе пројекту.

Кориснике занима како могу да испробају ваше парче софтвера. Редослед је углавном следећи:

• желим да прочитам шта пројекат ради;
• желим да на снимку екрана видим како то изгледа;
• желим да испробам демо (у случају веб-апликација);
• желим да преузмем код и испробам га на својем рачунару.

Потрудите се да процес преузимања кода, компајлирања, покретања и евентуално инсталације буде аутоматизован и добро описан. Постоје стандардизовани алати у зависности од изабране технологије као што су Пајтон сетаптулс, Нод пакиџ менаџер, Ц-мејк, Аутотулс… Идеје за организацију кода и подешавање тзв. билд система (енг. build system) је увек отворена тема и врло је специфична у зависности од изабране технологије. Свакако заслужује посебан текст у нашем часопису.

И програмери су у први мах корисници. Oни ће прво желети да покрену и користе ваш програм а тек онда покушати да га унапреде. Добра пракса је да пројекат садржи и скуп тестова којим ће програмери моћи да провере да нису својим изменама нешто покварили. Осим тестова, ту су и постављање развојног окружења (база података, библиотеке зависности…). Модерно је тај терет скинути са леђа програмера и процес подешавања радног окружења аутоматизовати помоћу алата као што су Вагрант, Папет (енг. Puppet), Шеф (енг. chef) и Aнсибл или Докер, о којима је већ било речи. Све у свему, покушајте да се поставите у ситуацију новог члана свог тима. Шта он све мора да уради након што клонира гит репозиторијум? Да ли можете тај део посла да аутоматизујете? Ако можете, урадите то.

Опен-сорс модел развоја софтвера је врло необичан. Грађење заједнице је један од приоритета. Добра заједница ће и од лошег кода направити нешто корисно. Добар код без заједнице умире. Не постоје неки јасни шаблони како се ствара заједница, али можемо да препоручимо неколико књига које се баве тим проблемом.

• Open Advice http://open-advice.org/
• The Art of Community http://www.artofcommunityonline.org/