От Анди Лестер

Много хора искат да участват в разработката на свободен софтуер, но не знаят откъде да започнат. Има няколко начина да помогнеш, дори и да имаш съмнения в техническата си компетентност.

Софтуера с отворен код промени изчислителната техника и въобще целия свят. Много от вас искат да се включат. За съжаление, хората се отказват, заради въображаеми пречки. Често чувам да казват, че биха се радвали да участват, обаче не могат поради три причини, които те формулират така:

"Не съм много добър програмист"

"Нямам свободно време."

"Не знам към кой проект да се включа."

Има три основни принципи, които трябва да помните, когато се оглеждате за възможности:

Проектите се нуждаят от хора със всякакви нива на техническа компетентност.

И най-малкия принос е повече от нищо.

Най-добрият проект в който да участвате е този, който вече използвате.

Най-вредната идея, сред новаците в отворения код е, че за да участваш в проект с отворен код, трябва да си някакъв гениален програмист. Това не е вярно. Несъмнено сред разработчиците на свободен софтуер има хора, едва ли не рок звезди, които може и да са гениални програмисти. Обаче, огромното множество не сме такива. Ние сме просто хората, които вършат работата. Понякога правим малко, понякога много. Понякога това е програмиране, а понякога не.

Най-главното, което прави идеята за свободен софтуер да работи е реалната работа. Времето вложено да се свърши работата по проекта. По-голямата част от тази работа не изисква мозъка на Лари Уол, създателя на Perl или Давид Хайнемеер Хенсон, създателя на Rails. За създаването на нов език или уеб фреймуърк може и да се иска вдъхновение, но това, което прави Пърл или Рейлс успешни е упоритата работа вложена в тях. Тази работа може и да не носи слава, но тя все пак е необходима и след време, твоят принос ще бъде забелязан.

Всичко в отворения код включва други хора. Ти се опитваш да се включиш в екип и това значи да разбереш обществото и как то работи. На това да се появиш и да кажеш "Здрасти! Сега ще ви кажа как този проект трябва да изглежда." обикновено не се гледа с добро око. Някои проекти може и да приветстват подобен подход, но ако проекта вече се е развил, шансовете да ви приветстват са малки. Да слушаш е най-добрият начин да научиш от какво проекта има нужда.

За много проекти пощеският списък е главният комуникационен канал между разработчиците. По-големите проекти имат няколко такива списъка. Например проекта PostgreSQL има 12 списъка за потребители и още 6 за разработчиците. В такава ситуация, бих ви посъветвал да следите поне главния списък за потребители и главния за разработчици.

Блоговете на главните разработчици обикновено информират за това какво следва в проекта и какво трябва да се направи за да се стигне до там. Ако има "планетарен" сайт-агрегатор за проекта от вида на planet.gnome.org/ или planet.mysql.com/, започни от там. Просто потърси в Google "planet <projectname>".

Много проекти с отворен код имат чат канал, където потребителите и разработчиците обсъждат проблемите и разработката. Провери сайта на проекта за конкретното име на канала и сървъра, където се намира той.

Кодът е сърцето на всеки проект с отворен код, но не си мисли, че да пишеш код е единствения начин да участваш. Поддръжката на кода и системите около кода често са пренебрегвани в стремежа да се пише повече код и да се оправят бъгове. Да обърнеш внимание на тези системи е добър начин да влезеш в проекта.

Повечето проекти имат публична система за поддръжка (бъгтракер), достъпна обикновено от главната страница на проекта и спомената в документацията. Това е главният начин за комуникация между разработчиците и потребителите. Да я поддържаш в актуално състояние е отличен начин да помогнеш на проекта. Тука може да трябват специални права, но повечето от ръководителите на проект с радост ще ви ги дадат, ако им кажете, че искате да помогнете с разчистването на системата за поддръжка.

Бъговете рядко се докладват на разработчиците. Диагностиката и класификацията на бъговете може да спести на разработчиците време да се ориентират в подробностите. Ако потребителя докладва "Програмата не работи когато направя X", отдели малко време за да разбереш подробностите на проблема. Дали е повтаряем? Можеш ли да определиш точна поредица от действия, която да проявява проблема всеки път? Можеш ли да стесниш границите на проблема? Например, че се проявява в един браузър, а в друг не, или в една дистрибуция, а в друга не?

Даже и да не знаеш както точно предизвиква проблема, усилията, които вложиш в уточняването на подробностите ще направят по-лека работата на този, който ще го оправя. Каквото и да откриеш, добави го към тикета в системата за поддръжка.

Често бъговете се оправят в кода, обаче тикета за този бъг не се обновява. Разчистването на такива остатъци отнема време но е важно за целия проект.

Пусни търсене на системата за бъгове по-стари от една година и провери дали бъга все още съществува. Провери съобщенията в системата за контрол на версиите, дали бъга не е оправен. Ако намериш такива съобщения, провери версията за която се отнася тикета и го затвори.

Опитай се да възпроизведеш бъга с най-новата версия на софтуера. Ако не се проявява, напиши го в тикета и го затвори. Ако се проявява, пак напиши и го остави отворен.

Програмистите с какъвто и да е опит могат да допринесат за кода на проекта. Не си мисли, че трябва да си гениален програмист, за да пишеш код за твоя любим проект.

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

Например PostgreSQL проекта е много взискателен. Промените на кода се изпращат като пач в пощенският списък, където основните разработчици взискателно разглеждат всеки аспект на промяната. А в други проекти, например като Parrot, е много лесно да ти дадат права да пишеш директно в системата за контрол на версиите. Ако проекта използва GitHub, начина на работа обикновено изисква пул-рекуест. В това отношение, няма два еднакви проекта.

Както и да работиш върху кода, действай като отговорен член на колектива и спазвай стила който е приет в проекта. Кода който ти добавяш или променяш трябва да изглежда като останалия. Може да не харесваш стила на скобите, използването на табове и шпации или отместването на блоковете, но е грубо да събмитваш промяна в кода, която не съответства на вече приетите стандарти. Това е все едно да кажеш "Не харесвам вашият стил и мисля, че моят е по-добър, затова вие трябва да го правите по моя начин."

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

Обикновено, това се свежда до сваляне и компилиране на програмата, но приносът към проекта може да се окаже огромен, особено ако работиш на рядко срещана дистрибуция или хардуер. Дори доклада, че проекта може да се компилира и работи помага на ръководителя на проекта да се увери, че предстоящия релийз е стабилен.

Обикновено хората искащи да помогнат започват именно с това. Просто е: Намери бъг, който ти изглежда интересен в бъгтракера и се опитай да го оправиш в кода. Документирай промените ако е нужно.

Добра идея е да добавиш тест, който да проверява мястото е кода, което си оправил. За някои проекти това е задължително. Води си бележки, докато бърникаш из кода. Дори и да не успееш да оправиш бъга, напиши в тикета какво си открил, докато си се опитвал да го оправиш. Това, което си открил ще помогне на тези, които идват след тебе.

Повечето проекти имат комплект тестове, които проверяват кода. Тестовете обаче никога не са много. Използвай инструменти като gcov за C или Devel::Cover за Пърл, за да откриеш местата, които не се проверяват от съществуващите тестове. Добави тест, който да покрива някое от тези места.

Често компилаторът генерира много предупредителни съобщения, които не сигнализират за реален проблем, но изглеждат като такъв. Когато такива съобщения са твърде много, компилаторът изглежда все едно вълк вие към луната.

Провери, дали зад такова предупреждение не се крие реален бъг. Ако не, модифицирай кода, така че предупреждението да не излиза. Това помага да се избегнат такива лъжливи съобщения за проблем.

Когато се ровиш из кода, може да намериш места, които са объркващи и неясни. Ако ти се объркваш, то и другите ще се объркват. Напиши коментари в кода, които да поясняват нещата и публикувай промяната.

Документацията е частта от проекта, към която се отнасят много грубо. Тя може да страда и от това, че е написана от гледната точка на хора, които познават проекта в детайли, вместо от гледната точка на човек, който тепърва се запознава с него. Ако сте чели някога документация и сте си мислили "Това е писано като за хора, които вече знаят как да използват програмата", то разбирате какво имам предвид. Често, свеж поглед отстрани може да открие пропуски в документацията, които тези които са отдавна в проекта не могат да забележат.

Няма такова нещо като прекалено много примери. Няма значение дали това е уеб API, библиотека, GUI програма или конзолна такава, подходящ пример за правилно използване може да обясни правилното използване на софтуера по-ясно и по-бързо, отколкото десетки страници текстова документация.

За API или библиотека, напиши примерна програма, която ги използва. Този пример може даже да е измъкнат от ваша по-голяма програма и максимално съкратен за по-голяма яснота. За друга програма, покажи пример от практиката, как използваш тази програма в работата си. Ако предпочиташ визуалните форми, запиши екранно филмче как се прави нещо важно - например правилната инсталация.

Свободния софтуер не е само кода. Обществото прави отвореният код да работи. Това са начините да го развием.

Най-добрият начин за развитие на обществото е да помагаш на другите. Отговаряйки на въпрос, особено на някой начинаещ е жизнено важно за растежа и процъфтяването на проекта. Времето, което отделиш да помогнеш на n00b, даже и въпросът му да си проси "RTFM" се изплаща в бъдеще с появяването на нови членове на обществото. Всеки започва отнякъде и проектите се нуждаят от свежо попълнение за да оцеляват.

Ако имаш блог, напиши за опита си с проект, който използваш. Разкажи за проблемите, които си срещнал и какво си направил за да ги решиш. Така ти помагаш по два начина едновременно. Едно, че напомняш на хората за проекта и второ, че помагаш на някой, който е срещнал същия проблем и търси в уеб решение. (И обратно, блог за твоите техно приключения е чудесен начин да покажеш реалния си опит с въпросния софтуер, когато следващия път си търсиш работа с използването на този проект).

Повечето програмисти са доста скапани графични дизайнери и малко са уеб сайтовете на проекти, които не биха ползвали помощ по дизайна. Ако разбираш от уеб дизайн и можеш да подобриш уеб сайта и от тук и публичния имидж на проекта, то не си си загубил времето напразно. Или пък проекта има нужда от основен ремонт на графиката, или пък ново лого, за по-добра идентификация на проекта. Това може да са умения липсващи в обществото. Аз поне знам, че в моите уеб проекти бих се радвал на помощ в дизайна.

Главно, вслушвай се какво обсъждат хората около тебе. Виж дали не можеш да разпознаеш някаква належаща нужда. Така например, наскоро в пощенския списък на разработчиците от проекта Parrot беше решено да се използва GitHub като система за следене на проблеми, изоставяйки старата система Trac, която се използваше по-рано. Някои хора бяха против преместването, защото нямаше начин да се конвертират съществуващите тикети към системата на GitHub. След ден препирни аз се намесих и казах - "Какво ще кажете да напиша конвертор?". Хората горещо приеха идеята. Аз отделих малко време да напиша конвертор за повече от 450-те тикета в системата и така не загубихме старите тикети. И това беше голям успех. Аз успях да помогна, а основните разработчици останаха фокусирани на основната работа върху Parrot.

Има толкова много начини да участваш в разработката на свободен софтуер, ако гледаш отвъд очевидното написване на "more features". Всеки, който използва продукти с отворен код може да използва способностите си за да се запази отворения код важна част от света на компютрите.