Upplýsingatæknihátíð verður haldin í Pétursborg í vikunni . Einn fyrirlesara verður Richard Stallman. tekur einnig þátt í hátíðinni og auðvitað gátum við ekki hunsað umræðuefnið um frjálsan hugbúnað. Þess vegna heitir ein af skýrslum okkar . Það verður tileinkað sögu þróunar Embox sem opins uppspretta verkefnis. Í þessari grein vil ég tala um helstu hugmyndir sem að mínu mati hafa áhrif á þróun opinna verkefna. Greinin, eins og skýrslan, er byggð á persónulegri reynslu.
Við skulum byrja á einhverju einföldu, með skilgreiningu á hugtakinu opinn uppspretta. Augljóslega er opinn uppspretta verkefni verkefni sem hefur eitt af leyfunum sem leyfir aðgang að frumkóða verkefnisins. Að auki þýðir opið verkefni að forritarar frá þriðja aðila geta gert breytingar. Það er að segja, ef eitthvert fyrirtæki eða þróunaraðili birtir kóðann fyrir vöru sína, að hluta eða öllu leyti, gerir þetta þessa vöru ekki enn að opnu verkefni. Og að lokum, hvers kyns verkefnastarfsemi verður að leiða til einhvers konar niðurstöðu, og hreinskilni verkefnisins gefur til kynna að þessi niðurstaða nýtist ekki aðeins af framkvæmdaraðilum sjálfum.
Við munum ekki snerta vandamál opinna leyfa. Þetta er of stórt og flókið efni sem krefst ítarlegrar rannsóknar. Margar góðar greinar og efni hafa verið skrifaðar um þetta efni. En þar sem ég sjálfur er ekki sérfræðingur á sviði höfundarréttar, segi ég aðeins að leyfið verður að uppfylla markmið verkefnisins. Til dæmis, fyrir Embox var valið á BSD frekar en GPL leyfi ekki tilviljun.
Sú staðreynd að opinn uppspretta verkefni ætti að veita möguleika á að gera breytingar og hafa áhrif á þróun opins uppspretta verkefnisins gefur til kynna að verkefninu sé dreift. Að stjórna því, viðhalda heilindum og frammistöðu er mun erfiðara miðað við verkefni með miðstýrðri stjórnun. Eðlileg spurning vaknar: hvers vegna eru opin verkefni yfirleitt? Svarið liggur á sviði viðskiptahagkvæmni; fyrir ákveðinn flokk verkefna er ávinningurinn af þessari nálgun meiri en kostnaðurinn. Það er, það hentar ekki öllum verkefnum og opin nálgun er almennt ásættanleg. Til dæmis er erfitt að ímynda sér að þróa stjórnkerfi fyrir orkuver eða flugvél sem byggir á opinni meginreglu. Nei, auðvitað ættu slík kerfi að innihalda einingar sem byggjast á opnum verkefnum, því það mun veita ýmsa kosti. En einhver verður að bera ábyrgð á lokaafurðinni. Jafnvel þótt kerfið sé algjörlega byggt á kóða opinna verkefna, þá lokar verktaki því í raun og veru, eftir að hafa pakkað öllu inn í eitt kerfi og gert sérstakar byggingar og stillingar. Kóðinn gæti verið aðgengilegur almenningi.
Það er líka mikill ávinningur fyrir þessi kerfi af því að búa til eða leggja sitt af mörkum til opinn uppspretta verkefna. Eins og ég sagði þegar, gæti lokakerfiskóðinn verið aðgengilegur almenningi. Hvers vegna, vegna þess að það er augljóst að það er ólíklegt að einhver hafi sömu flugvél til að prófa kerfið. Þetta er satt, en það getur vel verið að einhver vilji athuga ákveðna hluta kóðans, eða til dæmis gæti einhver uppgötvað að bókasafnið sem verið er að nota er ekki alveg rétt stillt.
Enn meiri ávinningur birtist ef fyrirtækið úthlutar einhverjum grunnhluta kerfisins í sérstakt verkefni. Til dæmis, bókasafn til að styðja einhvers konar gagnaskipti siðareglur. Í þessu tilviki, jafnvel þó að siðareglur sé sértækur fyrir tiltekið efnissvið, geturðu deilt kostnaði við að viðhalda þessu stykki af kerfinu með öðrum fyrirtækjum frá þessu svæði. Að auki þurfa sérfræðingar sem geta rannsakað þennan hluta kerfisins á almenningi miklu minni tíma til að nota það á áhrifaríkan hátt. Og að lokum, að aðskilja hlut í sjálfstæða einingu sem þriðju aðilar nota gerir okkur kleift að gera þennan hluta betri, vegna þess að við þurfum að bjóða upp á skilvirk API, búa til skjöl og ég er ekki einu sinni að tala um að bæta prófunarumfang.
Fyrirtæki getur fengið viðskiptalegan ávinning án þess að búa til opinn uppspretta verkefni; það er nóg fyrir sérfræðinga þess að taka þátt í verkefnum þriðja aðila sem notuð eru í fyrirtækinu. Þegar öllu er á botninn hvolft eru allir kostir eftir: starfsmenn þekkja verkefnið betur, þess vegna nota þeir það á skilvirkari hátt, fyrirtækið getur haft áhrif á stefnu þróunar verkefnisins og notkun á tilbúnum, kembiforrituðum kóða dregur augljóslega úr kostnaði fyrirtækisins.
Ávinningurinn af því að búa til opinn uppspretta verkefni endar ekki þar. Tökum svo mikilvægan þátt í viðskiptum sem markaðssetningu. Fyrir hann er þetta mjög góður sandkassi sem gerir honum kleift að meta kröfur markaðarins á áhrifaríkan hátt.
Og auðvitað megum við ekki gleyma því að opið verkefni er áhrifarík leið til að lýsa því yfir að þú sért burðarmaður hvers kyns sérhæfingar. Í sumum tilfellum er þetta eina leiðin til að komast inn á markaðinn. Til dæmis byrjaði Embox sem verkefni til að búa til RTOS. Það þarf líklega ekki að útskýra að það eru margir keppendur. Án þess að búa til samfélag hefðum við einfaldlega ekki haft nægt fjármagn til að koma verkefninu til endanotandans, það er að segja að forritarar frá þriðja aðila gætu byrjað að nota verkefnið.
Samfélagið er lykillinn í opnu verkefni. Það gerir þér kleift að draga verulega úr verkefnastjórnunarkostnaði, þróa og styðja við verkefnið. Við getum sagt að án samfélags sé alls ekkert opið verkefni.
Mikið efni hefur verið skrifað um hvernig eigi að búa til og stjórna opnum uppspretta verkefnasamfélagi. Til þess að endursegja ekki þegar þekktar staðreyndir mun ég reyna að einbeita mér að upplifuninni af Embox. Til dæmis er ferlið við að búa til samfélag mjög áhugavert mál. Það er að segja, margir segja til um hvernig eigi að stjórna núverandi samfélagi, en stundum er litið framhjá augnablikum við stofnun þess, þar sem þetta er sjálfgefið.
Meginreglan þegar stofnað er opið verkefnasamfélag er að það eru engar reglur. Ég meina það eru engar algildar reglur, rétt eins og það er engin silfurkúla, þó ekki væri nema vegna þess að verkefnin eru mjög ólík. Það er ólíklegt að þú getir notað sömu reglur þegar þú býrð til samfélag fyrir js skráningarsafn og einhvern mjög sérhæfðan bílstjóra. Þar að auki, á mismunandi stigum þróunar verkefnisins (og þar af leiðandi samfélagsins), breytast reglurnar.
Embox byrjaði sem nemendaverkefni vegna þess að það hafði aðgang að nemendum úr kerfisforritunardeild. Reyndar vorum við að fara inn í annað samfélag. Við gætum vakið áhuga þátttakenda þessa samfélags, nemendur, á góðri iðnvenju í sérgrein sinni, vísindastörfum á sviði kerfisforritunar, námskeiðahalds og prófskírteina. Það er að segja, við fylgdum einni af grunnreglunum við að skipuleggja samfélag: meðlimir samfélagsins verða að fá eitthvað og þetta verð verður að samsvara framlagi þátttakandans.
Næsti áfangi fyrir Embox var leitin að notendum þriðja aðila. Það er mjög mikilvægt að skilja að notendur eru fullir þátttakendur í opensource samfélaginu. Það eru venjulega fleiri notendur en forritarar. Og til að vilja gerast þátttakandi í verkefni byrja þeir fyrst að nota það á einn eða annan hátt.
Fyrstu notendur Embox voru fræðileg netfræðideild. Þeir lögðu til að búa til annan fastbúnað fyrir Lego Mindstorm. Og þó að þetta væru enn staðbundnir notendur (við gátum hitt þá í eigin persónu og rætt hvað þeir vildu). En þetta var samt mjög góð reynsla. Við þróuðum til dæmis kynningar sem hægt væri að sýna öðrum, því vélmenni eru skemmtileg og vekja athygli. Fyrir vikið fengum við raunverulega þriðja aðila notendur sem fóru að spyrja hvað Embox er og hvernig á að nota það.
Á þessu stigi þurftum við að hugsa um skjöl, um samskipti við notendur. Nei, auðvitað hugsuðum við um þessa mikilvægu hluti áður, en það var ótímabært og gaf ekki jákvæð áhrif. Áhrifin voru frekar neikvæð. Leyfðu mér að gefa þér nokkur dæmi. Við notuðum googlecode, þar sem wiki styður fjöltyngi. Við bjuggum til síður á nokkrum tungumálum, ekki aðeins ensku og rússnesku, þar sem við gátum varla átt samskipti, heldur líka þýsku og spænsku. Þess vegna lítur það mjög fáránlega út þegar spurt er á þessum tungumálum, en við getum alls ekki svarað. Eða þeir settu reglur um að skrifa skjöl og athugasemdir, en þar sem API breyttist nokkuð oft og verulega, kom í ljós að skjölin okkar voru úrelt og villandi en það hjálpaði.
Þess vegna leiddi öll viðleitni okkar, jafnvel röng, til þess að utanaðkomandi notendur birtust. Og meira að segja viðskiptavinur birtist sem vildi að hans eigið RTOS yrði þróað fyrir hann. Og við þróuðum það vegna þess að við höfum reynslu og grunnvinnu. Hér þarf að tala um bæði góðu og slæmu augnablikin. Ég ætla að byrja á þeim slæmu. Þar sem margir framkvæmdaraðilar tóku þátt í þessu verkefni á viðskiptalegum grunni var samfélagið þegar nokkuð óstöðugt og sundrað, sem auðvitað gat ekki annað en haft áhrif á þróun verkefnisins. Aukaatriði var að stefna verkefnisins var sett af einum viðskiptavini og markmið hans var ekki frekari þróun verkefnisins. Þetta var allavega ekki aðalmarkmiðið.
Á hinn bóginn var ýmislegt jákvætt. Við fengum raunverulega þriðja aðila notendur. Það var ekki bara viðskiptavinurinn heldur líka þeir sem þetta kerfi var ætlað. Hvatning til þátttöku í verkefninu hefur aukist. Þegar öllu er á botninn hvolft, ef þú getur líka þénað peninga frá áhugaverðum viðskiptum, þá er það alltaf gott. Og síðast en ekki síst, við heyrðum eina löngun frá viðskiptavinum, sem á þeim tíma fannst okkur klikkuð, en sem er nú meginhugmynd Embox, nefnilega að nota þegar þróaðan kóða í kerfinu. Nú er meginhugmynd Embox að nota Linux hugbúnað án Linux. Það er að segja að helsti jákvæði þátturinn sem stuðlaði að frekari þróun verkefnisins var að átta sig á því að verkefnið er notað af þriðja aðila notendum og það ætti að leysa sum vandamál þeirra.
Á þeim tíma var Embox þegar farið út fyrir verksvið nemenda. Helsti takmarkandi þátturinn í þróun verkefnisins samkvæmt nemendalíkaninu er hvatning þátttakenda. Nemendur taka þátt á meðan þeir eru í námi og þegar þeir útskrifast ætti að vera önnur hvatning. Ef hvatning kemur ekki fram hættir nemandinn einfaldlega að taka þátt í verkefninu. Ef tekið er tillit til þess að fyrst þarf að þjálfa nemendur kemur í ljós að þeir verða góðir sérfræðingar þegar þeir útskrifast, en framlag þeirra til verkefnisins, vegna reynsluleysis, er ekki mjög mikið.
Almennt séð förum við vel yfir í aðalatriðið sem gerir okkur kleift að tala um að búa til opinn uppspretta verkefni - að búa til vöru sem myndi leysa vandamál notenda sinna. Eins og ég útskýrði hér að ofan er aðaleign opins verkefnis samfélag þess. Þar að auki eru samfélagsmeðlimir fyrst og fremst notendur. En hvaðan koma þeir þegar ekkert er til að nota? Svo kemur í ljós að, rétt eins og með verkefni sem ekki er opinn uppspretta, þarftu að einbeita þér að því að búa til MVP (lágmarks viable vara) og ef það vekur áhuga notenda þá mun samfélag birtast í kringum verkefnið. Ef þú tekur þátt í því að búa til samfélag aðeins í gegnum PR-samfélag, skrifa wiki á öllum tungumálum heimsins eða leiðrétta git vinnuflæði á github, þá er ólíklegt að þetta skipti máli á fyrstu stigum verkefnisins. Auðvitað, á viðeigandi stigum, eru þetta ekki aðeins mikilvægir, heldur líka nauðsynlegir hlutir.
Að lokum vil ég benda á , að mínu mati, sem endurspeglar væntingar notenda frá opnu verkefni:
Ég er alvarlega að hugsa um að skipta yfir í þetta stýrikerfi (reyndu allavega. Þeir eru virkir að sækjast eftir því og gera flotta hluti).
PS á Við munum hafa allt að þrjár skýrslur. Einn um opinn uppspretta og tveir um embed in (og einn er hagnýtur). Á básnum munum við halda meistaranámskeið um forritun örstýringa með því að nota . Eins og venjulega munum við koma með vélbúnaðinn og leyfa þér að forrita hann. Einnig verður leit og önnur verkefni. Komdu á hátíðina og á básinn okkar, það verður gaman.
Heimild: www.habr.com