Redan denna vecka kommer det att hÄllas en IT-festival i Sankt Petersburg . En av talarna kommer att vara Richard Stallman. deltar ocksÄ i festivalen, och sjÀlvklart kunde vi inte bortse frÄn Àmnet öppen kÀllkod. DÀrför heter ett av vÄra föredrag . Det kommer att handla om historien bakom utvecklingen av Embox som ett projekt med öppen kÀllkod. I den hÀr artikeln vill jag berÀtta om de centrala idéerna som, enligt min mening, pÄverkar utvecklingen av open source-projekt. Artikeln, liksom föredraget, bygger pÄ personlig erfarenhet.
LÄt oss börja med det enkla, med en definition av termen öppen kÀllkod. Uppenbarligen Àr ett projekt med öppen kÀllkod ett projekt som har en av de licenser som tillÄter Ätkomst till projektets kÀllkod. Dessutom innebÀr ett öppet projekt möjligheten för externa utvecklare att göra Àndringar. Med andra ord, om ett företag eller en utvecklare publicerar koden för sin produkt, helt eller delvis, gör det fortfarande inte produkten till ett open source-projekt. Slutligen bör varje projektaktivitet leda till resultat, och öppenheten hos projektet innebÀr att detta resultat anvÀnds inte bara av utvecklarna sjÀlva.
Vi kommer inte att ta upp problemen kring öppna licenser. Det Àr ett för stort och komplext Àmne som krÀver djupgÄende granskning. Det har skrivits ganska mycket bra artiklar och material om detta Àmne. Men eftersom jag sjÀlv inte Àr specialist pÄ upphovsrÀtt kommer jag bara att sÀga att licensen mÄste motsvara projektets mÄl. Till exempel valde Embox BSD-licensen i stÀllet för GPL av en anledning.
Att faktum att ett öppet projekt mĂ„ste ge möjlighet att göra förĂ€ndringar och pĂ„verka utvecklingen av det öppna projektet antyder att projektet Ă€r distribuerat. Att hantera det, upprĂ€tthĂ„lla integritet och funktionalitet Ă€r mycket svĂ„rare jĂ€mfört med ett projekt med centraliserad kontroll. En rimlig frĂ„ga uppstĂ„r: varför skapa öppna projekt överhuvudtaget? Svaret ligger inom omrĂ„det kommersiell lönsamhet; för en viss klass av projekt övervĂ€ger vinsterna av en sĂ„dan metod kostnaderna. Det vill sĂ€ga, öppet tillvĂ€gagĂ„ngssĂ€tt passar inte alla projekt och Ă€r överhuvudtaget inte tillĂ„tet. Till exempel Ă€r det svĂ„rt att förestĂ€lla sig utvecklingen av ett system för styrning av ett kraftverk eller ett flygplan baserat pĂ„ ett öppet koncept. Nej, sjĂ€lvklart bör sĂ„dana system inkludera moduler baserade pĂ„ öppna projekt, eftersom det ger en rad fördelar. Men för den slutliga produkten mĂ„ste nĂ„gon ta ansvar. Ăven om systemet helt och hĂ„llet Ă€r baserat pĂ„ kod frĂ„n öppna projekt, stĂ€nger utvecklaren, genom att paketera allt i ett system och göra specifika versioner och instĂ€llningar, i princip av det. Koden kan Ă€ndĂ„ vara offentligt tillgĂ€nglig.
För dessa system finns det ocksÄ mÄnga fördelar med att skapa öppna projekt eller delta i dem. Som jag redan har sagt kan koden för det slutliga systemet hÄllas offentligt tillgÀnglig. Varför? För det Àr uppenbart att det knappast finns nÄgon annan som har ett likadant flygplan för att testa systemet. Det Àr sant, men det kan mycket vÀl finnas nÄgon som vill kontrollera specifika delar av koden, eller sÄ kan nÄgon upptÀcka att det anvÀnda biblioteket inte Àr helt korrekt konfigurerat.
En Ànnu större fördel uppstÄr nÀr ett företag avsÀtter en viss grundlÀggande del av systemet till ett separat projekt. Till exempel, ett bibliotek för att stödja ett visst protokoll för datautbyte. I detta fall, Àven om protokollet Àr specifikt för detta ÀmnesomrÄde, kan kostnaderna för att upprÀtthÄlla denna del av systemet delas med andra företag inom omrÄdet. Dessutom krÀver det av specialister som kan studera denna del av systemet i öppen tillgÄng mycket mindre tid för att effektivt anvÀnda det. Slutligen, att avsÀtta en del som en oberoende enhet som anvÀnds av externa utvecklare, gör att denna del kan bli mer kvalitativ, eftersom det krÀvs effektiva API:er, dokumentation, och jag nÀmner knappt förbÀttringen av testtÀckningen.
Ett företag kan ocksÄ fÄ kommersiella fördelar utan att skapa öppna projekt, det rÀcker med att dess specialister deltar i externa projekt som anvÀndas inom företaget. Alla fördelar kvarstÄr: anstÀllda kÀnner projektet bÀttre, vilket betyder att de anvÀnder det mer effektivt, företaget kan pÄverka projektets utvecklingsinriktning, och anvÀndningen av fÀrdig, stabil kod minskar tydligt företagets kostnader.
Fördelarna med att skapa opensource-projekt slutar inte hÀr. LÄt oss ta en sÄ viktig del av affÀrsverksamheten som marknadsföring. För den Àr det en mycket bra sandlÄda som effektivt lÄter en bedöma marknadens krav.
Och naturligtvis bör man inte glömma att ett opensource-projekt Àr ett effektivt sÀtt att göra sig kÀnd som bÀrare av en viss specialisering. I vissa fall Àr detta faktiskt den enda vÀgen till marknaden. Till exempel började Embox som ett projekt för att skapa ett OSRV. Det Àr nog onödigt att förklara att det finns massor av konkurrenter. Utan att skapa ett samhÀlle skulle vi helt enkelt inte ha haft resurserna att fÄ projektet till den slutliga anvÀndaren, det vill sÀga att externa utvecklare börjar anvÀnda projektet.
Gemenskapen Àr avgörande i ett opensource-projekt. Den möjliggör en betydande minskning av kostnaderna för projektledning och utvecklar samt stöder projektet. Man kan sÀga att utan gemenskap finns det överhuvudtaget inget opensource-projekt.
Det finns en mÀngd material om hur man skapar och hanterar ett community för ett projekt med öppen kÀllkod. Jag, för att inte ÄterberÀtta redan kÀnda fakta, kommer att fokusera pÄ erfarenheterna frÄn Embox. Till exempel Àr en mycket intressant frÄga processen för att skapa ett community. MÄnga pratar om hur man hanterar ett existerande community, men momentet för dess skapande glöms ibland bort, som om det Àr en sjÀlvklarhet.
Det viktigaste reglerna nÀr man skapar ett community för ett opensource-projekt Àr att det inte finns nÄgra regler. Jag menar att det inte finns nÄgra universella regler, precis som det inte finns nÄgon silverkul, dels för att projekten Àr mycket olika. Det Àr tveksamt om man kan anvÀnda samma regler nÀr man skapar ett community för ett logging-bibliotek i js och en specifik drivrutin. Dessutom förÀndras reglerna i takt med att projektet (och dÀrmed communityt) utvecklas.
Embox började som ett studentprojekt, eftersom vi hade tillgÄng till studenter frÄn avdelningen för systemprogrammering. I praktiken gick vi in i en annan community. Deltagarna i denna community, studenterna, kunde vi intressera med bra industriell praktik relaterad till deras specialitet, forskningsarbeten inom systemprogrammering, samt kandidatuppsats och examensarbeten. Med andra ord följde vi en av de grundlÀggande reglerna för att organisera ett community: deltagarna mÄste fÄ nÄgot, och detta mÄste motsvara den insats som deltagaren gör.
NÀsta steg för Embox var att söka efter externa anvÀndare. Det Àr mycket viktigt att förstÄ att anvÀndarna Àr fullvÀrdiga deltagare i ett opensource-community. Det finns vanligtvis fler anvÀndare Àn utvecklare. Och för att vilja bli en bidragsgivare till projektet mÄste man först börja anvÀnda det pÄ ett eller annat sÀtt.
De första anvÀndarna av Embox var institutionen för Teoretisk Cybernetik. De föreslog att skapa en alternativ firmware för Lego Mindstorm. Och Àven om det fortfarande var lokala anvÀndare (vi kunde trÀffa dem personligen och diskutera vad de ville). Men det var ÀndÄ en mycket bra erfarenhet. Till exempel utvecklade vi demoer som kunde visas för andra, eftersom robotar Àr roliga och drar till sig uppmÀrksamhet. I slutÀndan fick vi riktigt externa anvÀndare som började frÄga vad Embox Àr och hur man anvÀnder det.
I det hÀr skedet började vi fundera pÄ dokumentation och kommunikationsverktyg med anvÀndarna. SjÀlvklart hade vi tÀnkt pÄ dessa viktiga saker tidigare, men det var för tidigt och gav inget positivt resultat. Effekten var snarare negativ. LÄt mig ge nÄgra exempel. Vi anvÀnde googlecode, vars wiki stödde flersprÄkighet. Vi gjorde sidor pÄ flera sprÄk, inte bara engelska och ryska, dÀr vi kunde kommunicera, utan Àven tyska och spanska. Resultatet sÄg vÀldigt löjligt ut nÀr nÄgon frÄgade pÄ dessa sprÄk, men vi kunde överhuvudtaget inte svara. Eller vi introducerade regler för att skriva dokumentation och kommentera, men eftersom API:et förÀndrades ganska ofta och pÄtagligt, blev vÄr dokumentation förÄldrad och gav mer förvirring Àn hjÀlp.
I slutÀndan ledde alla vÄra insatser, Àven de felaktiga, till att externa anvÀndare dök upp. Och till och med en kommersiell kund som ville att vi skulle utveckla ett eget OSR. Och vi utvecklade det eftersom vi har erfarenhet och nÄgra resurser. HÀr mÄste jag nÀmna bÄde positiva och negativa aspekter. Jag börjar med de negativa. Eftersom mÄnga utvecklare drogs till detta projekt pÄ kommersiell basis, blev gemenskapen och sÄ redan ganska instabil, delad, vilket sjÀlvklart pÄverkade projektets utveckling. En ytterligare faktor var det faktum att projektets inriktning bestÀmdes av en kommersiell kund, vars mÄl inte var fortsatt utveckling av projektet. à tminstone var det mÄlet inte huvudsakligt.
à andra sidan fanns det flera positiva aspekter. Vi fick verkligen externa anvÀndare. Det handlade inte bara om bestÀllaren, utan ocksÄ om de som systemet var avsett för. Motivation att delta i projektet ökade. För om man kan tjÀna pengar pÄ nÄgot intressant Àr det alltid trevligt. Och viktigast av allt, vi hörde en önskan frÄn bestÀllarna som vid den tidpunkten verkade oss fÄnig, men som nu Àr huvudidén i Embox, nÀmligen att anvÀnda redan utvecklad kod i systemet. Nu Àr huvudidén med Embox att anvÀnda programvara frÄn Linux utan Linux. Det vill sÀga, den viktigaste positiva aspekten som bidrog till projektets vidare utveckling var insikten om att projektet anvÀnds av externa anvÀndare, och att det mÄste lösa deras problem.
Vid den tidpunkten hade Embox redan gÄtt bortom studentprojektets ramar. Den huvudsakliga hindret för projektets utveckling enligt studentmodellen Àr motivationen hos deltagarna. Studenter deltar sÄ lÀnge de studerar, och nÀr de har examen mÄste en annan motivation uppstÄ. Om motivationen inte dyker upp slutar studenten bara att delta i projektet. Med tanke pÄ att studenter först mÄste utbildas blir det sÄ att de blir bra specialister nÀr de gÄr ut, men deras bidrag till projektet Àr, pÄ grund av bristande erfarenhet, inte sÀrskilt stort.
Sammanfattningsvis övergĂ„r vi smidigt till huvudpunkten som gör det möjligt att prata om skapandet av ett opensource-projekt â att skapa en produkt som löser anvĂ€ndarnas problem. Som jag redan förklarade ovan Ă€r den viktigaste egenskapen hos ett opensource-projekt dess gemenskap. Och deltagarna i gemenskapen Ă€r frĂ€mst anvĂ€ndare. Men hur ska de kunna komma dit om det inte finns nĂ„got att anvĂ€nda? SĂ„ det visar sig att precis som med ett icke-opensource-projekt mĂ„ste man fokusera pĂ„ att skapa en MVP (minimalt livskraftig produkt), och om den vĂ€cker anvĂ€ndarnas intresse kommer en gemenskap att uppstĂ„ runt projektet. Om man istĂ€llet försöker skapa en gemenskap enbart genom PR, skriva wiki pĂ„ alla vĂ€rldens sprĂ„k, eller ha en korrekt git-arbetsflöde pĂ„ GitHub, Ă€r det osannolikt att det kommer att ha betydelse i projektets tidiga skeden. Naturligtvis Ă€r dessa saker viktiga och nödvĂ€ndiga pĂ„ relevanta stadier.
Avslutningsvis vill jag nÀmna , i min mening Äterspeglar anvÀndarens förvÀntningar pÄ ett opensource-projekt:
Jag övervÀger seriöst att byta till detta OS (Ätminstone att prova. Det utvecklas verkligen aktivt och görs coola grejer).
P. S. PÄ vi kommer att ha hela tre förelÀsningar. En om open source och tvÄ om embedded (och en av dem Àr praktisk). PÄ vÄr monter kommer vi att hÄlla en workshop om programmering av mikrokontrollers med hjÀlp av . Traditionellt tar vi med oss hÄrdvara och lÄter folk programmera. Det kommer ocksÄ vara ett quiz och andra aktiviteter. Kom till festivalen och till vÄr monter, det kommer bli roligt.
KĂ€lla: habr.com
