Как да се присъедините проект с отворен код, дори ако не знаете как да се напише код

За да участвате в opensorsnyh проекти, ти дори не знаят как да се програмира, но, след като изпадна в света на свободния софтуер, можете да станете опитен подправки и да намерят подходяща работа. Ето десет съвета, които да ви помогнат да намерите вашия начин.

Анестезиолог против kolivas разработени своя собствена версия на диспечера за Линукс ядрото. защото текущото изпълнение е адаптиран за сървърни задачи и не се справят добре с този потребител.

Алексей Кузнецов, който случайно се превръща в Linux-хакерите. Той промени професията си с теоретичен физик в програмист на системата.

Les Novaselskaya получи специален патолог участва в тестването на проект в с отворен код.

Такива примери са много. Всички тези хора са обединени от едно нещо - те намерили начин да реализират своите интереси в opensorsnyh проекти и да участват в тях и за забавление, и да се натрупа опит. Имаше един вид мит, че проект с отворен код - това е само за програмисти, както и тези, които вече имат богат опит в развитието. Но това не е така. Open проект източник - не само за написването на изходния код, но и тестване, техническа поддръжка, писане документация, маркетинг и др. И това е чудесна възможност да се натрупа опит, изграждане на кариера и да се насладите на комуникацията с връстниците си.

Според сайта на проучване opensource.com, основната пречка за участие в проекта е отворен - всеки, просто не знам как да се присъединят. Ние предлагаме няколко начина за решаване на този световен проблем.

Напишете нов код

За всеки проект се характеризира със свои собствени технически процеси, така че да разберете повече за тях, преди да предложите своя версия. Например, проектът PostgreSQL строго регламентирани всички процеси: промени в кода се изпращат под формата на пластири за изпращане на основните разработчиците, които внимателно да проучат всички промени. От друга страна, има и други видове проекти, като, например, Папагала, където програмистите могат да се ангажират с главният източник. Ако проектът използва GitHub, вероятно процеси доставят чрез искането за дърпане, тоест, и заявки за вписване на промените. Като цяло, не два проекта са едни и същи.

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

приоритет на бъгове

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

Например, проектът за OpenVZ е напълно отворена система работи с дефекти - bugs.openvz.org. където всички известни (коригирани и некоригирани) проблеми по време на живота на проекта (почти десет години). Bug Tracker - един от механизмите за комуникация между разработчици и потребители. Постоянна работа с текущата заявка дава отлична възможност да допринесе за проекта. За да работи системата може да се наложи специални разрешения, които ви дават ръководител на проекта, следвайки принципите на меритокрацията.

Тествани междинни версии

От моя собствен опит мога да кажа, че проекти с отворен код не винаги разполагат с необходимите ресурси, за да имате добър тест нова функционалност. Ето защо, преди да добавите големи промени до главния клон на изходния код хранилището, проектът има за цел да привлече повече хора да се тестват. Тази практика се нарича - поканата за тест (покана за тестване). Собствениците на проекта никога няма да бъде възможно най-много хардуерни и софтуерни конфигурации, като общност. Например, проектът OpenBSD обявим нова функционалност в новините. за да привлекат вниманието на потребителите и тестери. Същото прави проекта OpenVZ.

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

Писане на тестове

Повечето проекти се използват софтуерни системи, предназначени да проверят код и всеки един от тях се предвижда добавянето на нов тест. Използвайте инструментите за изпитване като gcov за C, за да се определи областта на изходния код, който не може да се тества на съществуващите тестове. След това добавете подходящи изпитвания, за да може да се тества функционалността ви трябва.

Корекции на грешки и добавя нови функции

Patch за решаване на проблема или да добавите необходимите характеристики - един вид класически начин за участие в проекта с отворен код (започва се с това като цяло, всички Движението за свободен софтуер). Този метод се препоръчва и известен поддръжник Джеймс Bottomli Linux общността (известен още като - CTO отдел виртуализация на сървъра Один) за тези, които искат да участват в Linux-проекта, но не знам как. Обикновено, той дава пример за случай, когато тя му е да се промени функционалността на SIP-клиент в Android. Намирането, че това не е възможно, той направи кръпка и се изпраща проект SIPdroid.

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

Помага за поддържането на инфраструктурата на проекта

Вие се интересувате от DevOps района? Тази тенденция е много популярен. Добри DevOps инженери в България е много трудно да се намери, ние знаем от опит. Натрупа опит възможно в проектите, в които развитието на инфраструктурата е отворен. Това е проекти като Wikipedia и Fedora Linux. OpenVZ прави само първите стъпки в тази посока.

Създаване на непрекъснат процес на интеграция на компонентите на проекта, опаковъчни компоненти за Linux-дистрибуции, околна среда авто разработчици - всички, включени в задачата на DevOps.

Писане и превод

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

Ако четете документацията по проекта Посещавали ли сте на идеята: "Изглежда, че тя е написана така, сякаш вече знаете как да използвате програмата", тогава знаете какво имам предвид. Много често изглеждат част разкрива недостатъците на сегашната документация, които не могат да видят преките участници в проекта. В допълнение към динамични проекти документация, остарява бързо, и това трябва да се поддържа актуална.

Ако по някаква причина смятате, че да се направи това "не са сериозни", а след това вие грешите. Не "сериозен" или "несериозна" принос към проекта с отворен код. Например, OpenBSD разработчик (в същото време и персонал CERN) Инго Шварц (Инго Schwarze) написа полезност mandoc. която сега се използва за форматиране на страници документация не само в OpenBSD, но в FreeBSD, NetBSD, DragonFly BSD. По пътя, той сложи в ред съществуващата форматирането на страници документация по проекта. Така че всичко зависи от това, което е интересно за вас. Ако проявявате интерес - Beris и направи!

Помага на другите

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

Ако имате блог, споделят своя опит, който сте получили в проекта. Разкажете ми за проблемите, които сте се сблъскали при използване на софтуера, и как да ги решим. Така че можете да убие два заека с един камък: да поддържа вниманието на колегите си в проекта и да предостави полезна база на информация за тези, които ще се присъединят към него в бъдеще и ще се търсят отговори на мрежата вече е описано въпроси към вас. Блог, разказа за своите технически постижения и изтънченост - това е също е чудесен начин да споделят реални преживявания и разработване на решения на технически проблеми, които могат да бъдат полезни при търсенето на нова работа. В много проекти, има студия записи от блогове на участниците в проекта, традиционно наричани "планети": Linux ядрото на планетата, Perl, OpenVZ, freedesktop, GNOME, Debian и др.

се проектират

Дизайн - е проклятието на повечето проекти с отворен код. Досадно уеб сайтове и непривлекателни лога съпътстват проекти, просто защото техническите хората най-вече обсебени от идеята за изпълнение, а не на външен вид. Ето защо, дизайнери участват изключително добре дошли. Членове StackExchange сайт се опита да отговори на въпросите "като графичен дизайнер може да допринесе за проекта с отворен код", "какво мотивира дизайнера да участват в отворения проект", но техните мнения се различават. Дизайнерите на компанията Red Hat също осъзнаха необходимостта от по-активно участие на дизайнери в проекти с отворен код, и се опитаха да се създаде уеб сайт. които ще ви помогнат да отворите даден проект и дизайнери, за да се намери друг, но случаите на успешното изпълнение на проекта все още не е известна.

Потърсете такива, които са от интерес за Вас и полезно за проекта, и да се опитаме да ги решим. Начини за участие могат да бъдат различни, понякога те са описани на специални страници: OpenStack. OpenVZ. FreeBSD. Самото съществуване на такава страница на проекта, казва, че тя е отворена за участие на други хора.

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

Александър Юрченко, разработчик на компанията "Яндекс"

На първата си сериозна работа за пари (разработчик на вградени системи), дойдох повече от една година, независимо от официален разработчик на ядрото безплатно OpenBSD операционната система. Официален - в смисъл, имах достъп за запис в хранилището. И това е все още около година бях "зрител" изпрати петна на разработчиците.

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

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

Кирил Gorkunov, разработчик на проекта и OpenVZ CRIU

Натиснах OpenVZ съвсем случайно. На работа разглежда основно с програмиране на приложения, почти не разполагат с пресечни точки със системата. В един момент, е придобил първия си 64-битов лаптоп (Acer с AMD Turion 64), както и, тъй като Windows 64-битова версия не е на една ръка разстояние, сложих Gentoo. С Linux, докато познати имаха малко, така че да играе въведе някакъв древен Red Hat, но той не е особено ме впечатли, както и за решаване на текущите проблеми на работниците, тази операционна система не е подходяща. Под Gentoo лаптоп повече или по-малко обработка, но някои шофьори не са стандартно ядро, така че трябваше да се съберат на ядрото от изходен код.

Тук за първи път хвана грешката, макар и не в ядрото, а в програмата на образуване на конфигурацията на ядрото. Poryskat в интернет - решения няма проблем, добре, той се осмели да се опита да го оправя. Оказа се, трябваше да се справят с различни задачи, свързани с (като ще сърцевината на това, което се използват инструменти, и така нататък). Patch е направил, изпратено до пощенския списък. За моя изненада, подържат ядро ​​реагира много благоприятно дори да такава "крива" кръпки (Аз ще ви кажа, че е трябвало да се промени, тъй като кръпка беше отвратително, просто не веднага започна да дава "на порта завой"), не е имало нито смях към начинаещи: обясни какво и как, и показа как да го направя така.

Нещо като това се случи с мен: след няколко години на правилата на нещо в кода, изпратени петна, получени в ръцете на кривата на кода и на одобрението, ако пластирът е добър и красив. Такъв опит е всъщност безценни. И вие можете да бъдете сигурни, че ако започнете да се получи нещо, веднага след това ще има предложение за работа. Така че аз пресече пътя с разработчиците на ядрото на Линукс от OpenVZ. Е, след това решава да работят заедно върху основните и OpenVZ свързани програми, като не забравяме, разбира се, и на ванилия ядро.

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

Александър Поляков, разработчик

Мисля, че моята лична история не е оригинална. Както обикновено се случва - да започнете да използвате някои софтуер, и изведнъж се оказва, че ние бихме искали да направим нещо не се получи много добре, или нещо липсва, или е налице гадни плитчини. В случая с отворен код има възможност да го отстраните и сами. Така беше и с DWM на прозореца за управление, което ме дразнеше през конфигурация config.h в прекомпилирате: Първо, аз добавя довереник чрез xrdb, след това кликнете да се съсредоточи, и така нататък. Тези промени не съответстват на минималистичен дизайн насока, така че трябваше да се направи вилица.

С DragonFly BSD е приблизително една и съща: примамливи текстове в сайта звучаха интересни, FreeBSD уморен, но изведнъж се оказа, че има лоша поддръжка на езици, различни от английски, и за управление на захранването (ACPI). Аз трябваше да предприеме необходимите пренасяне код раздели на по-нова версия на FreeBSD. Значително помогна други разработчици в IRC канал, обясни какво е това, което и помощ сделка с проблеми. Там аз имам известен опит в разработването на ядрото и системни библиотеки. И все пак успя в това да се направи малко пари - имаше един човек от Москва, която се използва в DragonFly BSD prodakshene и също нещо, те искаха да прецизирате в ACPI. Аз ме намери дневник на Git, контакт по пощата.

В OpenBSD, аз съм само на малките неща, някои петна хвърлят - в CWM нещо dopilivat за удобство (в wm'ah нещо, което е специален), в ksh поправени няколко запаси и подобрени VI режим. В този проект, свързан с новите участници не е най-добрият - приема се, че вие ​​ще разберете себе си цял и едва след това, което пишете в бюлетина. висока бариера за навлизане, оцеляват само най-често срещаните, но кода се оказва добро.

Участвал съм в 9front. Променено драйвер за достъп до Wi-Fi и вече е запознат да ми ACPI. Те имат най-вероятно най-малкия работен изпълнението на AML преводач. Самото ядро ​​на сравнително компактна (в сравнение с "нормалните" операционна система), така че по-лесно да се разбере. Той се похвали в интервю, как е помогнал (или обратното) - не знам.

Ето как можете да се натрупа опит в проекти с отворен код. Основното нещо - не се страхувайте да изпрати кода на кривата (това се случва на всички), останете спокойни (когато фламбирани) и подбор на проектите, които ви са наистина интересни. А и приятно, колкото и да се насладите. Все още има шанс, че самият работодател ще намерите на комит или профил в Githabe (здравей, Google!).

Покажете тази статия на приятел: