’n IT-fees word vandeesweek in St. Petersburg gehou . Een van die sprekers sal Richard Stallman wees. neem ook aan die fees deel, en ons kon natuurlik nie die onderwerp van gratis sagteware ignoreer nie. Daarom word een van ons verslae genoem . Dit sal gewy word aan die geskiedenis van Embox se ontwikkeling as 'n oopbronprojek. In hierdie artikel wil ek praat oor die hoofgedagtes wat na my mening die ontwikkeling van oopbronprojekte beïnvloed. Die artikel is, soos die verslag, op persoonlike ervaring gebaseer.
Kom ons begin met iets eenvoudig, met die definisie van die term opensource. Uiteraard is 'n oopbronprojek 'n projek wat een van die lisensies het wat toegang tot die bronkode van die projek toelaat. Boonop beteken 'n oop projek dat derdeparty-ontwikkelaars veranderinge kan maak. Dit wil sê, as een of ander maatskappy of ontwikkelaar die kode van sy produk, gedeeltelik of volledig publiseer, maak dit nog nie hierdie produk 'n oopbronprojek nie. En uiteindelik moet enige projekaktiwiteit tot 'n soort resultaat lei, en die openheid van die projek impliseer dat hierdie resultaat nie net deur die ontwikkelaars self gebruik word nie.
Ons sal nie die probleme van oop lisensies aanraak nie. Hierdie is 'n te groot en komplekse onderwerp wat 'n diepgaande ondersoek verg. Heelwat goeie artikels en materiaal is oor hierdie onderwerp geskryf. Maar aangesien ek self nie 'n kenner op die gebied van kopiereg is nie, sal ek net sê dat die lisensie aan die doelwitte van die projek moet voldoen. Byvoorbeeld, vir Embox was die keuse van 'n BSD eerder as 'n GPL-lisensie nie toevallig nie.
Die feit dat 'n oopbronprojek die vermoë moet bied om veranderinge aan te bring en die ontwikkeling van die oopbronprojek te beïnvloed, impliseer dat die projek versprei word. Die bestuur daarvan, die handhawing van integriteit en prestasie is baie moeiliker in vergelyking met 'n projek met gesentraliseerde bestuur. 'n Redelike vraag ontstaan: hoekom maak oop projekte hoegenaamd oop? Die antwoord lê op die gebied van kommersiële haalbaarheid; vir 'n sekere klas projekte weeg die voordele van hierdie benadering die koste. Dit wil sê, dit is nie geskik vir alle projekte nie en 'n oop benadering is algemeen aanvaarbaar. Dit is byvoorbeeld moeilik om 'n beheerstelsel vir 'n kragsentrale of 'n vliegtuig te ontwikkel wat op 'n oop beginsel gebaseer is. Nee, sulke stelsels moet natuurlik modules insluit wat op oop projekte gebaseer is, want dit sal 'n aantal voordele bied. Maar iemand moet verantwoordelik wees vir die finale produk. Selfs al is die stelsel heeltemal gebaseer op die kode van oop projekte, die ontwikkelaar, wat alles in een stelsel verpak en spesifieke bouwerk en instellings gemaak het, sluit dit in wese. Die kode kan publiek beskikbaar wees.
Daar is ook baie voordele vir hierdie stelsels om oopbronprojekte te skep of by te dra. Soos ek reeds gesê het, kan die eindstelselkode publiek beskikbaar bly. Hoekom, want dit is duidelik dat dit onwaarskynlik is dat iemand dieselfde vliegtuig sal hê om die stelsel te toets. Dit is waar, maar daar kan wel iemand wees wat sekere afdelings van die kode wil nagaan, of iemand kan byvoorbeeld ontdek dat die biblioteek wat gebruik word nie heeltemal korrek opgestel is nie.
'n Selfs groter voordeel blyk as die maatskappy 'n basiese deel van die stelsel in 'n aparte projek toewys. Byvoorbeeld, 'n biblioteek om 'n soort data-uitruilprotokol te ondersteun. In hierdie geval, selfs al is die protokol spesifiek vir 'n gegewe vakgebied, kan u die koste van die instandhouding van hierdie deel van die stelsel met ander maatskappye uit hierdie area deel. Daarbenewens benodig spesialiste wat hierdie deel van die stelsel in die publieke domein kan bestudeer, baie minder tyd om dit effektief te gebruik. En laastens, om 'n stuk te skei in 'n onafhanklike entiteit wat derdeparty-ontwikkelaars gebruik, stel ons in staat om hierdie deel beter te maak, want ons moet doeltreffende API's bied, dokumentasie skep, en ek praat nie eers van die verbetering van toetsdekking nie.
'n Maatskappy kan kommersiële voordele ontvang sonder om oopbronprojekte te skep; dit is genoeg vir sy spesialiste om deel te neem aan derdepartyprojekte wat in die maatskappy gebruik word. Al die voordele bly immers: werknemers ken die projek beter, daarom gebruik hulle dit meer effektief, die maatskappy kan die rigting van die projek se ontwikkeling beïnvloed, en die gebruik van klaargemaakte, ontfoutingskode verminder uiteraard die maatskappy se koste.
Die voordele van die skep van oopbronprojekte eindig nie daar nie. Kom ons neem so 'n belangrike komponent van besigheid as bemarking. Vir hom is dit 'n baie goeie sandbak wat hom in staat stel om markvereistes effektief te evalueer.
En natuurlik moet ons nie vergeet dat 'n oopbronprojek 'n effektiewe manier is om jouself as 'n draer van enige spesialisasie te verklaar nie. In sommige gevalle is dit die enigste manier om die mark te betree. Embox het byvoorbeeld begin as 'n projek om 'n RTOS te skep. Dit is waarskynlik nie nodig om te verduidelik dat daar baie mededingers is nie. Sonder om 'n gemeenskap te skep, sou ons eenvoudig nie genoeg hulpbronne gehad het om die projek na die eindgebruiker te bring nie, dit wil sê vir derdeparty-ontwikkelaars om die projek te begin gebruik.
Die gemeenskap is die sleutel in 'n oopbronprojek. Dit laat jou toe om projekbestuurskoste aansienlik te verminder, die projek te ontwikkel en te ondersteun. Ons kan sê sonder 'n gemeenskap is daar glad nie 'n oopbronprojek nie.
Baie materiaal is geskryf oor hoe om 'n oopbronprojekgemeenskap te skep en te bestuur. Om nie reeds bekende feite oor te vertel nie, sal ek probeer fokus op die ervaring van Embox. Die proses om 'n gemeenskap te skep is byvoorbeeld 'n baie interessante kwessie. Dit wil sê, baie vertel hoe om 'n bestaande gemeenskap te bestuur, maar die oomblikke van die skepping daarvan word soms oor die hoof gesien, aangesien dit as 'n gegewe beskou word.
Die hoofreël wanneer 'n oopbronprojekgemeenskap geskep word, is dat daar geen reëls is nie. Ek bedoel daar is geen universele reëls nie, net soos daar geen silwer koeël is nie, al is dit net omdat die projekte baie verskillend is. Dit is onwaarskynlik dat u dieselfde reëls kan gebruik wanneer u 'n gemeenskap vir 'n js-logboekbiblioteek en 'n hoogs gespesialiseerde bestuurder skep. Boonop verander die reëls in verskillende stadiums van ontwikkeling van die projek (en dus die gemeenskap).
Embox het as 'n studenteprojek begin omdat dit toegang tot studente van die stelselprogrammeringsafdeling gehad het. Trouens, ons het 'n ander gemeenskap betree. Ons kan die deelnemers van hierdie gemeenskap, studente, interesseer in goeie industriële praktyk in hul spesialiteit, wetenskaplike werk op die gebied van stelselprogrammering, kursuswerk en diplomas. Dit wil sê, ons het een van die basiese reëls van die organisasie van 'n gemeenskap gevolg: gemeenskapslede moet iets ontvang, en hierdie prys moet ooreenstem met die deelnemer se bydrae.
Die volgende fase vir Embox was die soektog na derdeparty-gebruikers. Dit is baie belangrik om te verstaan dat gebruikers volle deelnemers aan die opensource-gemeenskap is. Daar is gewoonlik meer gebruikers as ontwikkelaars. En om 'n bydraer tot 'n projek te wil word, begin hulle dit eers op een of ander manier gebruik.
Die eerste gebruikers van Embox was die Departement Teoretiese Kubernetika. Hulle het voorgestel om 'n alternatiewe firmware vir Lego Mindstorm te skep. En hoewel dit steeds plaaslike gebruikers was (ons kon hulle persoonlik ontmoet en bespreek wat hulle wou hê). Maar dit was steeds 'n baie goeie ervaring. Ons het byvoorbeeld demonstrasies ontwikkel wat aan ander gewys kan word, want robotte is pret en trek aandag. Gevolglik het ons werklik derdeparty-gebruikers gekry wat begin vra het wat Embox is en hoe om dit te gebruik.
Op hierdie stadium moes ons dink aan dokumentasie, oor kommunikasiemiddele met gebruikers. Nee, ons het natuurlik voorheen oor hierdie belangrike dinge gedink, maar dit was voortydig en het nie 'n positiewe uitwerking gegee nie. Die effek was taamlik negatief. Kom ek gee jou 'n paar voorbeelde. Ons het googlecode gebruik, wie se wiki veeltaligheid ondersteun het. Ons het bladsye in verskeie tale geskep, nie net Engels en Russies nie, waarin ons skaars kon kommunikeer, maar ook Duits en Spaans. Gevolglik lyk dit baie belaglik as dit in hierdie tale gevra word, maar ons kan glad nie antwoord nie. Of hulle het reëls oor die skryf van dokumentasie en kommentaar ingestel, maar aangesien die API redelik gereeld en aansienlik verander het, het dit geblyk dat ons dokumentasie verouderd was en meer misleidend was as wat dit gehelp het.
As gevolg hiervan het al ons pogings, selfs die verkeerde, gelei tot die verskyning van eksterne gebruikers. En selfs 'n kommersiële klant het verskyn wat wou hê dat sy eie RTOS vir hom ontwikkel moet word. En ons het dit ontwikkel omdat ons ondervinding en 'n bietjie grondwerk het. Hier moet jy oor beide die goeie oomblikke en die slegte praat. Ek sal by die slegtes begin. Aangesien baie ontwikkelaars op 'n kommersiële basis by hierdie projek betrokke was, was die gemeenskap reeds redelik onstabiel en verdeeld, wat natuurlik nie anders kon as om die ontwikkeling van die projek te beïnvloed nie. 'n Bykomende faktor was dat die rigting van die projek deur een kommersiële klant bepaal is, en sy doel was nie die verdere ontwikkeling van die projek nie. Dit was darem nie die hoofdoel nie.
Aan die ander kant was daar 'n aantal positiewe aspekte. Ons het werklik derdeparty-gebruikers. Dit was nie net die kliënt nie, maar ook diegene vir wie hierdie stelsel bedoel was. Die motivering om aan die projek deel te neem het toegeneem. As jy ook geld kan maak uit 'n interessante besigheid, is dit immers altyd lekker. En die belangrikste is dat ons een begeerte van kliënte gehoor het, wat op daardie stadium vir ons mal gelyk het, maar wat nou die hoofgedagte van Embox is, naamlik om reeds ontwikkelde kode in die stelsel te gebruik. Nou is die hoofgedagte van Embox om Linux-sagteware sonder Linux te gebruik. Dit wil sê, die belangrikste positiewe aspek wat bygedra het tot die verdere ontwikkeling van die projek was die besef dat die projek deur derdepartygebruikers gebruik word, en dit behoort sommige van hul probleme op te los.
Op daardie stadium het Embox reeds buite die bestek van 'n studenteprojek gegaan. Die belangrikste beperkende faktor in die ontwikkeling van die projek volgens die studentemodel is die motivering van die deelnemers. Studente neem deel terwyl hulle studeer, en wanneer hulle gradueer, moet daar 'n ander motivering wees. Indien motivering nie verskyn nie, hou die student eenvoudig op om aan die projek deel te neem. As ons in ag neem dat studente eers opgelei moet word, blyk dit dat hulle goeie spesialiste word teen die tyd dat hulle gradueer, maar hul bydrae tot die projek is weens onervarenheid nie baie groot nie.
Oor die algemeen gaan ons glad voort na die hoofpunt wat ons toelaat om te praat oor die skep van 'n opensource-projek - die skep van 'n produk wat die probleme van sy gebruikers sal oplos. Soos ek hierbo verduidelik het, is die hoofeienskap van 'n oopbronprojek sy gemeenskap. Boonop is gemeenskapslede hoofsaaklik gebruikers. Maar waar kom hulle vandaan as daar niks is om te gebruik nie? Dit blyk dus dat jy, net soos met 'n nie-oopbronprojek, moet fokus op die skep van 'n MVP (minimum lewensvatbare produk), en as dit gebruikers interesseer, dan sal 'n gemeenskap rondom die projek verskyn. As jy betrokke is by die skep van 'n gemeenskap slegs deur gemeenskap PR, die skryf van 'n wiki in alle tale van die wêreld, of die korrekte git-werkvloei op github, dan is dit onwaarskynlik dat dit saak maak in die vroeë stadiums van die projek. Natuurlik, in die toepaslike stadiums is dit nie net belangrike dinge nie, maar ook noodsaaklike dinge.
Ten slotte wil ek daarop wys , na my mening, wat gebruikersverwagtinge van 'n oopbronprojek weerspieël:
Ek dink ernstig daaraan om na hierdie bedryfstelsel oor te skakel (probeer ten minste. Hulle streef dit aktief na en doen oulike dinge).
PS Aan Ons sal soveel as drie verslae hê. Een oor oopbron en twee oor ingebed (en een is prakties). By die staanplek sal ons 'n meesterklas hou oor programmering van mikrobeheerders wat gebruik word . Soos gewoonlik sal ons die hardeware bring en jou dit laat programmeer. Daar sal ook 'n soektog en ander aktiwiteite wees. Kom na die fees en ons stand, dit gaan pret wees.
Bron: will.com