Ĉi-semajne okazos IT-festivalo en Peterburgo . Unu el la prelegantoj estos Richard Stallman. ankaŭ partoprenas en la festivalo, kaj kompreneble ni ne povus ignori la temon de libera programaro. Tial unu el niaj raportoj nomiĝas . Ĝi estos dediĉita al la historio de la evoluo de Embox kiel malfermkoda projekto. En ĉi tiu artikolo mi volas paroli pri la ĉefaj ideoj, kiuj, laŭ mi, influas la disvolviĝon de malfermfontaj projektoj. La artikolo, kiel la raporto, baziĝas sur persona sperto.
Ni komencu per io simpla, per la difino de la termino malfermfonteco. Evidente, malfermfonteca projekto estas projekto, kiu havas unu el la permesiloj, kiuj permesas aliron al la fontkodo de la projekto. Krome, malfermita projekto signifas, ke triaj programistoj povas fari ŝanĝojn. Tio estas, se iu kompanio aŭ programisto publikigas la kodon de sia produkto, parte aŭ tute, tio ankoraŭ ne faras ĉi tiun produkton malfermfonta projekto. Kaj finfine, ajna projekta agado devas konduki al ia rezulto, kaj la malfermiteco de la projekto implicas, ke ĉi tiu rezulto estas uzata ne nur de la programistoj mem.
Ni ne tuŝos la problemojn de malfermitaj permesiloj. Ĉi tio estas tro granda kaj kompleksa temo, kiu postulas profundan esploron. Sufiĉe multaj bonaj artikoloj kaj materialoj estis verkitaj pri ĉi tiu temo. Sed ĉar mi mem ne estas fakulo pri kopirajto, mi nur diros, ke la permesilo devas plenumi la celojn de la projekto. Ekzemple, por Embox la elekto de BSD prefere ol GPL-licenco ne estis hazarda.
La fakto ke malfermfonta projekto devus disponigi la kapablon fari ŝanĝojn kaj influi la evoluon de la malfermfonta projekto implicas ke la projekto estas distribuita. Administri ĝin, konservi integrecon kaj efikecon estas multe pli malfacila kompare kun projekto kun centralizita administrado. Racia demando ŝprucas: kial malfermas projektojn entute? La respondo kuŝas en la areo de komerca farebleco; por certa klaso de projektoj, la avantaĝoj de ĉi tiu aliro superas la kostojn. Tio estas, ĝi ne taŭgas por ĉiuj projektoj kaj malferma aliro estas ĝenerale akceptebla. Ekzemple, estas malfacile imagi disvolvi kontrolsistemon por elektrocentralo aŭ aviadilo bazita sur malferma principo. Ne, kompreneble, tiaj sistemoj devus inkluzivi modulojn bazitajn sur malfermitaj projektoj, ĉar ĉi tio provizos kelkajn avantaĝojn. Sed iu devas respondeci pri la fina produkto. Eĉ se la sistemo estas tute bazita sur la kodo de malfermitaj projektoj, la programisto, enpakinte ĉion en unu sistemon kaj fari specifajn konstruojn kaj agordojn, esence fermas ĝin. La kodo povas esti publike havebla.
Estas ankaŭ multaj avantaĝoj por ĉi tiuj sistemoj de kreado aŭ kontribuado al malfermfontaj projektoj. Kiel mi jam diris, la fina sistema kodo eble restos publike disponebla. Kial, ĉar estas evidente, ke estas neverŝajne, ke iu ajn havos la saman aviadilon por testi la sistemon. Ĉi tio estas vera, sed eble estas iu, kiu volas kontroli iujn sekciojn de la kodo, aŭ, ekzemple, iu povas malkovri, ke la uzata biblioteko ne estas tute ĝuste agordita.
Eĉ pli granda avantaĝo aperas se la kompanio asignas iun bazan parton de la sistemo en apartan projekton. Ekzemple, biblioteko por subteni iun specon de protokolo pri interŝanĝo de datumoj. En ĉi tiu kazo, eĉ se la protokolo estas specifa por difinita temo, vi povas dividi la kostojn de konservado de ĉi tiu peco de la sistemo kun aliaj kompanioj de ĉi tiu areo. Krome, specialistoj, kiuj povas studi ĉi tiun pecon de la sistemo en la publika domeno, postulas multe malpli da tempo por uzi ĝin efike. Kaj finfine, apartigi pecon en sendependan enton, kiun uzas triapartaj programistoj, permesas al ni plibonigi ĉi tiun parton, ĉar ni devas oferti efikajn API-ojn, krei dokumentadon, kaj mi eĉ ne parolas pri plibonigo de testkovrado.
Firmao povas ricevi komercajn avantaĝojn sen krei malfermfontajn projektojn; sufiĉas por ĝiaj specialistoj partopreni en triapartaj projektoj uzataj en la kompanio. Post ĉio, ĉiuj avantaĝoj restas: dungitoj konas la projekton pli bone, tial ili uzas ĝin pli efike, la firmao povas influi la direkton de la evoluo de la projekto, kaj la uzo de preta, elpurigita kodo evidente reduktas la kostojn de la firmao.
La avantaĝoj de kreado de malfermfontaj projektoj ne finiĝas tie. Ni prenu tiel gravan komponanton de komerco kiel merkatado. Por li, ĉi tio estas tre bona sablokesto, kiu permesas al li efike taksi merkatajn postulojn.
Kaj kompreneble, ni ne devas forgesi, ke malfermfonta projekto estas efika maniero deklari vin kiel portanto de ajna specialiĝo. En iuj kazoj, ĉi tiu estas la sola maniero eniri la merkaton. Ekzemple, Embox komenciĝis kiel projekto por krei RTOS. Verŝajne ne necesas klarigi, ke estas multaj konkurantoj. Sen kreado de komunumo, ni simple ne havus sufiĉajn rimedojn por alporti la projekton al la fina uzanto, tio estas, ke triaj programistoj komencu uzi la projekton.
La komunumo estas ŝlosilo en malfermfonta projekto. Ĝi ebligas al vi signife redukti kostojn pri administrado de projektoj, disvolvi kaj subteni la projekton. Ni povas diri, ke sen komunumo tute ne ekzistas malfermkoda projekto.
Multe da materialo estis skribita pri kiel krei kaj administri malfermfontecan projektokomunumon. Por ne rerakonti jam konatajn faktojn, mi provos koncentriĝi pri la sperto de Embox. Ekzemple, la procezo de kreado de komunumo estas tre interesa afero. Tio estas, multaj rakontas kiel administri ekzistantan komunumon, sed la momentoj de ĝia kreado foje estas preteratentitaj, konsiderante tion donita.
La ĉefa regulo dum kreado de malfermfonta projektokomunumo estas ke ne ekzistas reguloj. Mi volas diri, ke ne ekzistas universalaj reguloj, same kiel ne ekzistas arĝenta kuglo, se nur ĉar la projektoj estas tre malsamaj. Estas neverŝajne, ke vi povas uzi la samajn regulojn dum kreado de komunumo por js-logging-biblioteko kaj iu tre specialigita pelilo. Krome, en malsamaj stadioj de evoluo de la projekto (kaj do la komunumo), la reguloj ŝanĝiĝas.
Embox komenciĝis kiel studenta projekto ĉar ĝi havis aliron al studentoj de la sistemo-programadsekcio. Fakte, ni eniris iun alian komunumon. Ni povus interesi la partoprenantojn de ĉi tiu komunumo, studentoj, pri bona industria praktiko en sia fako, scienca laboro en la kampo de sistema programado, kurslaboroj kaj diplomoj. Tio estas, ni sekvis unu el la bazaj reguloj pri organizado de komunumo: komunumanoj devas ion ricevi, kaj ĉi tiu prezo devas respondi al la kontribuo de la partoprenanto.
La sekva etapo por Embox estis la serĉo de triapartaj uzantoj. Estas tre grave kompreni, ke uzantoj estas plenaj partoprenantoj en la malfermfonta komunumo. Estas kutime pli da uzantoj ol programistoj. Kaj por deziri fariĝi kontribuanto al projekto, oni unue komencas uzi ĝin laŭ unu maniero aŭ alia.
La unuaj uzantoj de Embox estis la Sekcio de Teoria Cibernetiko. Ili sugestis krei alternativan firmware por Lego Mindstorm. Kaj kvankam ĉi tiuj ankoraŭ estis lokaj uzantoj (ni povus renkontiĝi kun ili persone kaj diskuti kion ili volas). Sed ĝi estis ankoraŭ tre bona sperto. Ekzemple, ni evoluigis demonstraĵojn kiuj povus esti montritaj al aliaj, ĉar robotoj estas amuzaj kaj altiras atenton. Kiel rezulto, ni ricevis vere triapartajn uzantojn, kiuj komencis demandi kio estas Embox kaj kiel uzi ĝin.
En ĉi tiu etapo, ni devis pensi pri dokumentado, pri komunikiloj kun uzantoj. Ne, kompreneble, ni antaŭe pensis pri ĉi tiuj gravaj aferoj, sed ĝi estis antaŭtempa kaj ne donis pozitivan efikon. La efiko estis sufiĉe negativa. Mi donu al vi kelkajn ekzemplojn. Ni uzis guglokodon, kies vikio subtenis multlingvecon. Ni kreis paĝojn en pluraj lingvoj, ne nur la angla kaj la rusa, en kiuj ni apenaŭ povis komunikiĝi, sed ankaŭ la germana kaj la hispana. Rezulte, ĝi aspektas tre ridinde kiam oni demandas en ĉi tiuj lingvoj, sed ni tute ne povas respondi. Aŭ ili enkondukis regulojn pri skribado de dokumentado kaj komentado, sed ĉar la API sufiĉe ofte kaj signife ŝanĝiĝis, montriĝis, ke nia dokumentaro estas malaktuala kaj pli trompa ol ĝi helpis.
Rezulte, ĉiuj niaj klopodoj, eĉ la malĝustaj, kaŭzis aperadon de eksteraj uzantoj. Kaj aperis eĉ komerca kliento, kiu volis, ke sia propra RTOS estu evoluigita por li. Kaj ni evoluigis ĝin ĉar ni havas sperton kaj iom da bazlaboro. Ĉi tie vi devas paroli pri kaj la bonaj kaj la malbonaj momentoj. Mi komencos per la malbonaj. Ĉar multaj programistoj estis implikitaj en ĉi tiu projekto sur komerca bazo, la komunumo jam estis sufiĉe malstabila kaj dividita, kio kompreneble ne povis ne influi la evoluon de la projekto. Plia faktoro estis, ke la direkto de la projekto estis fiksita de unu komerca kliento, kaj lia celo ne estis la pluevoluigo de la projekto. Almenaŭ tio ne estis la ĉefa celo.
Aliflanke, estis kelkaj pozitivaj aspektoj. Ni havas vere triapartajn uzantojn. Ne nur la kliento, sed ankaŭ tiuj, por kiuj ĉi tiu sistemo estis destinita. La instigo por partopreni en la projekto pliiĝis. Post ĉio, se vi ankaŭ povas gajni monon de interesa komerco, ĝi ĉiam estas agrable. Kaj plej grave, ni aŭdis unu deziron de klientoj, kiu tiutempe ŝajnis al ni freneza, sed kiu nun estas la ĉefa ideo de Embbox, nome uzi jam disvolvitan kodon en la sistemo. Nun la ĉefa ideo de Embbox estas uzi Linuksan programaron sen Linukso. Tio estas, la ĉefa pozitiva aspekto kontribuanta al la plua evoluo de la projekto estis la konstato, ke la projekto estas uzata de triaj uzantoj, kaj ĝi devus solvi kelkajn el iliaj problemoj.
En tiu tempo, Embox jam iris preter la amplekso de studenta projekto. La ĉefa limiga faktoro en la disvolviĝo de la projekto laŭ la studenta modelo estas la instigo de la partoprenantoj. Studentoj partoprenas dum ili studas, kaj kiam ili diplomiĝas, devus esti malsama instigo. Se instigo ne aperas, la studento simple ĉesas partopreni en la projekto. Se ni konsideras, ke studentoj unue devas esti trejnitaj, montriĝas, ke ili fariĝas bonaj specialistoj kiam ili diplomiĝas, sed ilia kontribuo al la projekto, pro malsperto, ne estas tre granda.
Ĝenerale, ni glate transiras al la ĉefa punkto, kiu permesas al ni paroli pri kreado de malfermfonta projekto - kreado de produkto, kiu solvus la problemojn de ĝiaj uzantoj. Kiel mi klarigis supre, la ĉefa propraĵo de malfermfonta projekto estas ĝia komunumo. Krome, komunumanoj estas ĉefe uzantoj. Sed de kie ili venas, kiam estas nenio por uzi? Do rezultas, ke, same kiel kun ne-malfermfonta projekto, vi devas koncentriĝi pri kreado de MVP (minimuma realigebla produkto), kaj se ĝi interesas uzantojn, tiam komunumo aperos ĉirkaŭ la projekto. Se vi okupiĝas pri kreado de komunumo nur per komunuma PR, verkado de vikio en ĉiuj lingvoj de la mondo aŭ korekta git-laborfluo sur github, tiam ĉi tio verŝajne ne gravas en la fruaj stadioj de la projekto. Kompreneble, en la taŭgaj etapoj ĉi tiuj estas ne nur gravaj, sed ankaŭ necesaj aferoj.
Konklude mi ŝatus atentigi , laŭ mi, reflektante uzantajn atendojn de malfermfonta projekto:
Mi serioze pensas pri ŝanĝi al ĉi tiu OS (almenaŭ provu. Ili aktive persekutas ĝin kaj faras bonegajn aferojn).
PS On Ni havos eĉ tri raportojn. Unu pri malferma fonto kaj du pri enigita (kaj unu estas praktika). Ĉe la stando ni faros majstran klason pri programado de mikroregiloj uzante . Kiel kutime, ni alportos la aparataron kaj lasos vin programi ĝin. Ankaŭ estos serĉado kaj aliaj agadoj. Venu al la festivalo kaj nia stando, estos amuze.
fonto: www.habr.com