Yn Sint Petersburch wurdt dizze wike in IT-festival hâlden . Ien fan de sprekkers sil Richard Stallman wêze. ek mei oan it festival, en fansels kinne wy net negearje it ûnderwerp fan frije software. Dêrom wurdt ien fan ús rapporten neamd . It sil wijd wurde oan 'e skiednis fan' e ûntwikkeling fan Embox as in iepen boarne-projekt. Yn dit artikel wol ik prate oer de wichtichste ideeën dy't, nei myn miening, de ûntwikkeling fan iepenboarne-projekten beynfloedzje. It artikel, lykas it rapport, is basearre op persoanlike ûnderfining.
Litte wy begjinne mei wat ienfâldich, mei de definysje fan 'e term opensource. Fansels is in iepen boarne-projekt in projekt dat ien fan 'e lisinsjes hat dy't tagong jout ta de boarnekoade fan it projekt. Derneist betsjut in iepen projekt dat ûntwikkelders fan tredden feroaringen kinne meitsje. Dat is, as ien bedriuw of ûntwikkelder de koade fan har produkt publisearret, foar in part of folslein, makket dit dit produkt noch net in iepenboarne-projekt. En úteinlik moat elke projektaktiviteit liede ta in soarte fan resultaat, en de iepenheid fan it projekt ymplisearret dat dit resultaat net allinich wurdt brûkt troch de ûntwikkelders sels.
Wy sille de problemen fan iepen lisinsjes net oanreitsje. Dit is in te grut en kompleks ûnderwerp dat yngeand ûndersyk freget. In protte goede artikels en materialen binne skreaun oer dit ûnderwerp. Mar om't ik sels gjin saakkundige bin op it mêd fan auteursrjocht, sil ik allinne mar sizze dat de lisinsje foldwaan moat oan de doelen fan it projekt. Bygelyks, foar Embox wie de kar fan in BSD ynstee fan in GPL-lisinsje net tafallich.
It feit dat in iepen boarne-projekt de mooglikheid moat leverje om feroaringen te meitsjen en de ûntwikkeling fan it iepen boarneprojekt te beynfloedzjen ymplisearret dat it projekt ferspraat is. It behearen, yntegriteit en prestaasjes behâlde is folle dreger yn ferliking mei in projekt mei sintralisearre behear. In ridlike fraach ûntstiet: wêrom iepenje projekten überhaupt? It antwurd leit op it mêd fan kommersjele helberens; foar in bepaalde klasse fan projekten wegen de foardielen fan dizze oanpak de kosten op. Dat is, it is net geskikt foar alle projekten en in iepen oanpak is algemien akseptabel. Bygelyks, it is dreech om te tinken dat it ûntwikkeljen fan in kontrôle systeem foar in krêftsintrale of in fleantúch basearre op in iepen prinsipe. Nee, fansels moatte sokke systemen modules befetsje op basis fan iepen projekten, om't dit in oantal foardielen sil leverje. Mar immen moat ferantwurdlik wêze foar it einprodukt. Sels as it systeem folslein basearre is op 'e koade fan iepen projekten, slút de ûntwikkelder, nei't alles yn ien systeem ferpakt hat en spesifike builds en ynstellingen makke, it yn essinsje slút. De koade kin iepenbier beskikber wêze.
D'r binne ek in protte foardielen foar dizze systemen fan it meitsjen of bydrage oan iepen boarneprojekten. Lykas ik al sei, kin de einsysteemkoade iepenbier beskikber bliuwe. Wêrom, om't it dúdlik is dat it net wierskynlik is dat elkenien itselde fleantúch sil hawwe om it systeem te testen. Dit is wier, mar d'r kin wol ien wêze dy't bepaalde seksjes fan 'e koade kontrolearje wol, of immen kin bygelyks ûntdekke dat de bibleteek dy't brûkt wurdt net hielendal goed konfigurearre is.
In noch grutter foardiel ferskynt as it bedriuw wat basisdiel fan it systeem tawiist yn in apart projekt. Bygelyks, in bibleteek om in soarte fan protokol foar gegevensútwikseling te stypjen. Yn dit gefal, sels as it protokol spesifyk is foar in bepaald fakgebiet, kinne jo de kosten diele foar it behâld fan dit stik fan it systeem mei oare bedriuwen út dit gebiet. Derneist hawwe spesjalisten dy't dit stik fan it systeem yn it publike domein studearje kinne folle minder tiid nedich om it effektyf te brûken. En as lêste, it skieden fan in stik yn in ûnôfhinklike entiteit dy't ûntwikkelders fan tredden brûke kinne ús dit diel better meitsje, om't wy effektive API's oanbiede moatte, dokumintaasje meitsje, en ik praat net iens oer it ferbetterjen fan testdekking.
In bedriuw kin kommersjele foardielen krije sûnder iepen boarne-projekten te meitsjen; it is genôch foar har spesjalisten om diel te nimmen oan projekten fan tredden dy't yn it bedriuw brûkt wurde. Alle foardielen bliuwe ommers oer: meiwurkers kenne it projekt better, dêrom brûke se it effektiver, it bedriuw kin ynfloed op de rjochting fan de ûntwikkeling fan it projekt, en it brûken fan klearmakke, debuggede koade ferleget fansels de kosten fan it bedriuw.
De foardielen fan it meitsjen fan iepenboarne-projekten einigje dêr net. Litte wy sa'n wichtige komponint fan bedriuw nimme as marketing. Foar him is dit in heul goede sânbak dy't him mooglik makket om merkeasken effektyf te evaluearjen.
En fansels moatte wy net ferjitte dat in opensource-projekt in effektive manier is om josels te ferklearjen as drager fan elke spesjalisaasje. Yn guon gefallen is dit de ienige manier om de merk yn te gean. Bygelyks, Embox begon as in projekt om in RTOS te meitsjen. It is wierskynlik net nedich om út te lizzen dat d'r in protte konkurrinten binne. Sûnder it meitsjen fan in mienskip soene wy gewoan net genôch middels hawwe om it projekt nei de ein brûker te bringen, dat is, foar ûntwikkelders fan tredden om it projekt te brûken.
De mienskip is de kaai yn in iepenboarne-projekt. It lit jo projektbehearkosten signifikant ferminderje, it projekt ûntwikkelje en stypje. Wy kinne sizze dat sûnder in mienskip d'r hielendal gjin opensource-projekt is.
In protte materiaal is skreaun oer hoe't jo in iepen boarne projektmienskip oanmeitsje en beheare. Om al bekende feiten net opnij te fertellen, sil ik besykje te rjochtsjen op 'e ûnderfining fan Embox. Bygelyks, it proses fan it meitsjen fan in mienskip is in heul ynteressant probleem. Dat is, in protte fertelle hoe't jo in besteande mienskip beheare kinne, mar de mominten fan har skepping wurde soms oersjoen, sjoen dit as in gegeven.
De haadregel by it meitsjen fan in iepenboarne-projektmienskip is dat d'r gjin regels binne. Ik bedoel, d'r binne gjin universele regels, lykas d'r gjin sulveren kûgel is, al is it allinich om't de projekten hiel oars binne. It is net wierskynlik dat jo deselde regels kinne brûke by it meitsjen fan in mienskip foar in js-loggingbibleteek en wat heul spesjalisearre bestjoerder. Boppedat feroarje de regels yn ferskate stadia fan ûntwikkeling fan it projekt (en dus de mienskip).
Embox begon as studinteprojekt om't it tagong hie ta studinten fan 'e ôfdieling systeemprogrammearring. Yn feite, wy wiene it ynfieren fan in oare mienskip. Wy koene de dielnimmers fan dizze mienskip, studinten, ynteressearje yn goede yndustriële praktyk yn har spesjaliteit, wittenskiplik wurk op it mêd fan systeemprogrammearring, kursussen en diploma's. Dat is, wy folgen ien fan 'e basisregels fan it organisearjen fan in mienskip: mienskipsleden moatte wat krije, en dizze priis moat oerienkomme mei de bydrage fan 'e dielnimmer.
De folgjende poadium foar Embox wie it sykjen nei brûkers fan tredden. It is heul wichtich om te begripen dat brûkers folsleine dielnimmers binne yn 'e opensource-mienskip. D'r binne normaal mear brûkers dan ûntwikkelders. En om meiwurker wurde te wollen oan in projekt, begjinne se it earst op de ien of oare manier te brûken.
De earste brûkers fan Embox wiene de ôfdieling teoretyske cybernetika. Se stelden foar it meitsjen fan in alternative firmware foar Lego Mindstorm. En hoewol dit noch lokale brûkers wiene (wy koene har persoanlik moetsje en beprate wat se woenen). Mar it wie dochs in hiel goede ûnderfining. Wy hawwe bygelyks demo's ûntwikkele dy't oan oaren toand wurde kinne, om't robots leuk binne en oandacht lûke. As gefolch hawwe wy wirklike brûkers fan tredden krigen dy't begon te freegjen wat Embox is en hoe't jo it brûke.
Yn dit stadium moasten wy tinke oer dokumintaasje, oer kommunikaasjemiddels mei brûkers. Nee, fansels, wy tochten earder oer dizze wichtige dingen, mar it wie te betiid en joech gjin posityf effekt. It effekt wie frij negatyf. Lit my jo in pear foarbylden jaan. Wy brûkten googlecode, wêrfan de wiki meartaligens stipe. Wy makken siden yn ferskate talen, net allinnich Ingelsk en Russysk, dêr't wy amper yn kommunisearje koene, mar ek Dútsk en Spaansk. Dêrtroch sjocht it der hiel bespotlik út as it frege wurdt yn dizze talen, mar wy kinne hielendal net antwurdzje. Of se yntrodusearre regels oer it skriuwen fan dokumintaasje en kommentaar, mar om't de API frij faak en signifikant feroare, die bliken dat ús dokumintaasje ferâldere wie en misliedend wie dan it holp.
As gefolch hawwe al ús ynspanningen, sels de ferkearde, liede ta it ferskinen fan eksterne brûkers. En sels in kommersjele klant ferskynde dy't woe dat syn eigen RTOS foar him ûntwikkele wurde. En wy hawwe it ûntwikkele om't wy ûnderfining en wat grûnwurk hawwe. Hjir moatte jo prate oer sawol de goede mominten as de minne. Ik sil begjinne mei de minne. Sûnt in protte ûntwikkelders wiene belutsen by dit projekt op in kommersjele basis, de mienskip wie al frij ynstabyl en ferdield, wat fansels koe net mar beynfloedzje de ûntwikkeling fan it projekt. In ekstra faktor wie dat de rjochting fan it projekt waard ynsteld troch ien kommersjele klant, en syn doel wie net de fierdere ûntwikkeling fan it projekt. Dit wie teminsten net it haaddoel.
Oan 'e oare kant wiene d'r in oantal positive aspekten. Wy hawwe wirklike brûkers fan tredden. It wie net allinich de klant, mar ek dejingen foar wa't dit systeem bedoeld wie. De motivaasje om mei te dwaan oan it projekt is tanommen. Ommers, as jo ek jild meitsje kinne fan in nijsgjirrich bedriuw, is it altyd moai. En it wichtichste, wy hearden ien winsk fan klanten, dy't op dat stuit like gek foar ús, mar dat is no it haad idee fan Embox, nammentlik te brûken al ûntwikkele koade yn it systeem. No is it haadidee fan Embox om Linux-software te brûken sûnder Linux. Dat is, de wichtichste positive aspekt bydroegen oan de fierdere ûntwikkeling fan it projekt wie it besef dat it projekt wurdt brûkt troch tredden brûkers, en it moat oplosse guon fan harren problemen.
Op dat stuit gie Embox al bûten it berik fan in studinteprojekt. De wichtichste beheinende faktor yn 'e ûntwikkeling fan it projekt neffens it studintemodel is de motivaasje fan' e dielnimmers. Studinten dogge mei wylst se studearje, en as se ôfstudearje, moat d'r in oare motivaasje wêze. As motivaasje net ferskynt, stopt de studint gewoan mei meidwaan oan it projekt. As wy der rekken mei hâlde dat studinten earst oplaat wurde moatte, dan docht bliken dat se op it stuit dat se ôfstudearje goede spesjalisten wurde, mar harren bydrage oan it projekt is troch ûnbelibjen net botte grut.
Yn 't algemien geane wy soepel troch nei it haadpunt dat ús kin prate oer it meitsjen fan in opensource-projekt - it meitsjen fan in produkt dat de problemen fan har brûkers soe oplosse. Lykas ik hjirboppe útlein, is it haadeigendom fan in iepenboarne-projekt har mienskip. Boppedat binne mienskipsleden foaral brûkers. Mar wêr komme se wei as der neat te brûken is? Sa docht bliken dat, krekt as mei in net-iepenboarne projekt, jo moatte rjochtsje op it meitsjen fan in MVP (minimum leefber produkt), en as it ynteresseart brûkers, dan sil in mienskip om it projekt ferskine. As jo dwaande binne mei it meitsjen fan in mienskip allinich fia community-PR, it skriuwen fan in wiki yn alle talen fan 'e wrâld, of it korrekte git-workflow op github, dan is dit net wierskynlik om saken te dwaan yn' e iere stadia fan it projekt. Fansels binne dit yn 'e passende stadia net allinich wichtige, mar ek needsaaklike dingen.
Ta beslút wol ik oanjaan , nei myn miening, wjerspegelje brûkersferwachtingen fan in iepenboarne-projekt:
Ik tink serieus om te wikseljen nei dizze OS (op syn minst besykje. Se binne aktyf neistribbet it en dwaan cool dingen).
PS oan Wy sille wol trije rapporten hawwe. Ien oer iepen boarne en twa oer ynbêde (en ien is praktysk). Op 'e stand sille wy in masterklasse hâlde oer it programmearjen fan mikrocontrollers mei help fan . Lykas gewoanlik sille wy de hardware bringe en jo it programmearje. Der sil ek in speurtocht en oare aktiviteiten wêze. Kom nei it festival en ús stand, it wurdt leuk.
Boarne: www.habr.com