Pietarissa järjestetään tällä viikolla IT-festivaali . Yksi puhujista on Richard Stallman. osallistuu myös festivaaleille, emmekä tietenkään voineet sivuuttaa ilmaisten ohjelmistojen aihetta. Siksi yksi raporteistamme on nimeltään . Se on omistettu Emboxin kehityksen historialle avoimen lähdekoodin projektina. Tässä artikkelissa haluan puhua tärkeimmistä ideoista, jotka mielestäni vaikuttavat avoimen lähdekoodin projektien kehitykseen. Artikkeli, kuten raportti, perustuu henkilökohtaisiin kokemuksiin.
Aloitetaan jostain yksinkertaisesta, avoimen lähdekoodin termin määritelmästä. Ilmeisesti avoimen lähdekoodin projekti on projekti, jolla on yksi lisensseistä, joka mahdollistaa pääsyn projektin lähdekoodiin. Lisäksi avoin projekti tarkoittaa, että kolmannen osapuolen kehittäjät voivat tehdä muutoksia. Eli jos joku yritys tai kehittäjä julkaisee tuotteensa koodin osittain tai kokonaan, tämä ei vielä tee tästä tuotteesta avoimen lähdekoodin projektia. Ja lopuksi, minkä tahansa projektitoiminnan on johdettava jonkinlaiseen tulokseen, ja projektin avoimuus merkitsee sitä, että tätä tulosta eivät käytä vain kehittäjät itse.
Emme käsittele avoimien lisenssien ongelmia. Tämä on liian laaja ja monimutkainen aihe, joka vaatii syvällistä tutkimista. Tästä aiheesta on kirjoitettu melko paljon hyviä artikkeleita ja materiaaleja. Mutta koska en itse ole tekijänoikeusalan asiantuntija, sanon vain, että lisenssin tulee täyttää projektin tavoitteet. Esimerkiksi Emboxille BSD:n valinta GPL-lisenssin sijaan ei ollut sattumaa.
Se, että avoimen lähdekoodin projektin tulisi tarjota mahdollisuus tehdä muutoksia ja vaikuttaa avoimen lähdekoodin projektin kehitykseen, tarkoittaa, että projekti on hajautettu. Sen hallinta, eheyden ja suorituskyvyn ylläpitäminen on paljon vaikeampaa kuin keskitetyn hallinnan projekti. Herää järkevä kysymys: miksi projekteja ylipäätään avataan? Vastaus on kaupallisen toteutettavuuden alueella; tietyn luokan projektien osalta tämän lähestymistavan hyödyt ovat kustannuksia suuremmat. Se ei siis sovellu kaikkiin projekteihin ja avoin lähestymistapa on yleisesti hyväksyttävä. Esimerkiksi voimalaitoksen tai lentokoneen ohjausjärjestelmän kehittäminen avoimella periaatteella on vaikeaa kuvitella. Ei, tietenkään tällaisissa järjestelmissä tulisi olla avoimiin projekteihin perustuvia moduuleja, koska tämä tarjoaa monia etuja. Mutta jonkun on oltava vastuussa lopputuotteesta. Vaikka järjestelmä perustuisi täysin avoimien projektien koodiin, kehittäjä, pakattuaan kaiken yhdeksi järjestelmäksi ja tehnyt tietyt koontiversiot ja asetukset, sulkee sen olennaisesti. Koodi voi olla julkisesti saatavilla.
Näille järjestelmille on myös paljon etuja avoimen lähdekoodin projektien luomisesta tai niihin osallistumisesta. Kuten jo sanoin, loppujärjestelmän koodi saattaa jäädä julkisesti saataville. Miksi, koska on ilmeistä, että on epätodennäköistä, että kenelläkään on sama lentokone testaamaan järjestelmää. Tämä on totta, mutta joku saattaa hyvinkin haluta tarkistaa tietyt koodin osat tai esimerkiksi joku saattaa huomata, että käytettävä kirjasto ei ole konfiguroitu aivan oikein.
Vielä suurempi hyöty näkyy, jos yritys allokoi jonkin järjestelmän perusosan erilliseen projektiin. Esimerkiksi kirjasto, joka tukee jonkinlaista tiedonvaihtoprotokollaa. Tässä tapauksessa, vaikka protokolla olisikin tiettyä aihealuetta varten, voit jakaa tämän järjestelmän ylläpitokustannukset muiden tämän alueen yritysten kanssa. Lisäksi asiantuntijat, jotka voivat tutkia tätä järjestelmän osaa julkisesti, tarvitsevat paljon vähemmän aikaa käyttääkseen sitä tehokkaasti. Ja lopuksi, jakamalla kappaleen itsenäiseksi kokonaisuudeksi, jota kolmannen osapuolen kehittäjät käyttävät, voimme tehdä tästä osasta paremman, koska meidän on tarjottava tehokkaita sovellusliittymiä, luotava dokumentaatio, enkä puhu edes testikattavuuden parantamisesta.
Yritys voi saada kaupallisia etuja luomatta avoimen lähdekoodin projekteja, riittää, että sen asiantuntijat osallistuvat yrityksessä käytössä oleviin kolmannen osapuolen projekteihin. Loppujen lopuksi kaikki edut säilyvät: työntekijät tuntevat projektin paremmin, joten he käyttävät sitä tehokkaammin, yritys voi vaikuttaa projektin kehityksen suuntaan ja valmiin, debuggoidun koodin käyttö vähentää selvästi yrityksen kustannuksia.
Avoimen lähdekoodin projektien luomisen edut eivät lopu tähän. Otetaanpa niin tärkeä osa liiketoimintaa kuin markkinointi. Hänelle tämä on erittäin hyvä hiekkalaatikko, jonka avulla hän voi arvioida tehokkaasti markkinoiden vaatimuksia.
Ja tietenkään emme saa unohtaa, että avoimen lähdekoodin projekti on tehokas tapa julistaa itsesi minkä tahansa erikoistumisen kantajaksi. Joissakin tapauksissa tämä on ainoa tapa päästä markkinoille. Esimerkiksi Embox aloitti RTOS:n luomisprojektina. Ei varmaan tarvitse selittää, että kilpailijoita on paljon. Ilman yhteisön luomista meillä ei yksinkertaisesti olisi ollut tarpeeksi resursseja viedäkseen projektia loppukäyttäjälle eli kolmannen osapuolen kehittäjille, jotka voisivat aloittaa projektin käytön.
Yhteisö on avain avoimen lähdekoodin projektissa. Sen avulla voit vähentää merkittävästi projektinhallintakustannuksia, kehittää ja tukea projektia. Voimme sanoa, että ilman yhteisöä ei ole avoimen lähdekoodin projektia ollenkaan.
Avoimen lähdekoodin projektiyhteisön luomisesta ja hallinnasta on kirjoitettu paljon materiaalia. Jotta en kertoisi uudelleen jo tunnettuja tosiasioita, yritän keskittyä Emboxin kokemukseen. Esimerkiksi yhteisön luomisprosessi on erittäin mielenkiintoinen aihe. Toisin sanoen monet kertovat, kuinka olemassa olevaa yhteisöä hallitaan, mutta sen luomisen hetket jäävät toisinaan huomiotta, koska tämä on itsestäänselvyys.
Pääsääntö avoimen lähdekoodin projektiyhteisöä luotaessa on, että sääntöjä ei ole. Tarkoitan, että ei ole olemassa universaaleja sääntöjä, aivan kuten ei ole hopealuotia, vaikka vain siksi, että projektit ovat hyvin erilaisia. On epätodennäköistä, että voit käyttää samoja sääntöjä luodessasi yhteisön js-lokikirjastolle ja jollekin erittäin erikoistuneelle ohjaimelle. Lisäksi säännöt muuttuvat hankkeen (ja siten yhteisön) eri kehitysvaiheissa.
Embox aloitti opiskelijaprojektina, koska sillä oli pääsy järjestelmäohjelmointiosaston opiskelijoille. Itse asiassa olimme astumassa johonkin toiseen yhteisöön. Voisimme kiinnostaa tämän yhteisön osallistujia, opiskelijoita, heidän erikoisalansa hyviä teollisia käytäntöjä, tieteellistä työtä järjestelmäohjelmoinnin alalla, kurssitöitä ja tutkintoja. Eli noudatimme yhtä yhteisön järjestämisen perussääntöä: yhteisön jäsenten on saatava jotain ja tämän hinnan on vastattava osallistujan panosta.
Emboxin seuraava vaihe oli kolmannen osapuolen käyttäjien haku. On erittäin tärkeää ymmärtää, että käyttäjät ovat täysimääräisiä osallistujia avoimen lähdekoodin yhteisössä. Käyttäjiä on yleensä enemmän kuin kehittäjiä. Ja jotta he haluavat tulla projektin avustajaksi, he alkavat ensin käyttää sitä tavalla tai toisella.
Emboxin ensimmäiset käyttäjät olivat teoreettisen kybernetiikan laitos. He ehdottivat vaihtoehtoisen laiteohjelmiston luomista Lego Mindstormille. Ja vaikka nämä olivat edelleen paikallisia käyttäjiä (voimme tavata heidän kanssaan henkilökohtaisesti ja keskustella heidän halustaan). Mutta se oli silti erittäin hyvä kokemus. Kehitimme esimerkiksi demoja, jotka voidaan näyttää muille, koska robotit ovat hauskoja ja herättävät huomiota. Tuloksena saimme todella kolmannen osapuolen käyttäjiä, jotka alkoivat kysyä, mikä Embox on ja miten sitä käytetään.
Tässä vaiheessa piti miettiä dokumentaatiota, kommunikaatiotapoja käyttäjien kanssa. Ei, tietenkään ajattelimme näitä tärkeitä asioita aiemmin, mutta se oli ennenaikaista eikä antanut positiivista vaikutusta. Vaikutus oli melko negatiivinen. Annan teille pari esimerkkiä. Käytimme googlecodea, jonka wiki tuki monikielisyyttä. Teimme sivuja useilla kielillä, ei vain englanniksi ja venäjäksi, joilla tuskin pystyimme kommunikoimaan, vaan myös saksaksi ja espanjaksi. Tämän seurauksena se näyttää erittäin naurettavalta, kun sitä kysytään näillä kielillä, mutta emme voi vastata ollenkaan. Tai he ottivat käyttöön säännöt dokumentaation kirjoittamisesta ja kommentoimisesta, mutta koska API muuttui melko usein ja merkittävästi, kävi ilmi, että dokumentaatiomme oli vanhentunutta ja enemmän harhaanjohtavaa kuin auttoi.
Tämän seurauksena kaikki ponnistelumme, jopa väärät, johtivat ulkopuolisten käyttäjien ilmestymiseen. Ja jopa kaupallinen asiakas ilmestyi, joka halusi, että hänelle kehitetään oma RTOS. Ja kehitimme sen, koska meillä on kokemusta ja pohjatyötä. Täällä sinun on puhuttava sekä hyvistä että huonoista hetkistä. Aloitan huonoista. Koska monet kehittäjät olivat mukana tässä projektissa kaupallisin perustein, yhteisö oli jo melko epävakaa ja jakautunut, mikä ei tietenkään voinut olla vaikuttamatta projektin kehitykseen. Lisätekijänä oli se, että projektin suunnan asetti yksi kaupallinen asiakas, eikä hänen tavoitteenaan ollut hankkeen jatkokehitys. Tämä ei ainakaan ollut päätavoite.
Toisaalta siinä oli monia positiivisia puolia. Meillä on todella kolmannen osapuolen käyttäjiä. Se ei ollut vain asiakas, vaan myös ne, joille tämä järjestelmä oli tarkoitettu. Motivaatio osallistua hankkeeseen on lisääntynyt. Loppujen lopuksi, jos voit myös ansaita rahaa mielenkiintoisesta yrityksestä, se on aina mukavaa. Ja mikä tärkeintä, kuulimme asiakkailta yhden toiveen, joka tuolloin tuntui meistä hullulta, mutta joka on nyt Emboxin pääidea, nimittäin käyttää jo kehitettyä koodia järjestelmässä. Nyt Emboxin pääideana on käyttää Linux-ohjelmistoa ilman Linuxia. Eli tärkein positiivinen puoli projektin jatkokehitykseen oli oivallus, että projekti on ulkopuolisten käyttäjien käytössä ja sen pitäisi ratkaista osa heidän ongelmistaan.
Embox oli tuolloin jo ylittänyt opiskelijaprojektin. Suurin rajoittava tekijä opiskelijamallin mukaisen projektin kehittämisessä on osallistujien motivaatio. Opiskelijat osallistuvat opiskelun aikana, ja valmistuessaan motivaation pitäisi olla erilainen. Jos motivaatiota ei näy, opiskelija yksinkertaisesti lopettaa osallistumisen projektiin. Jos otamme huomioon, että opiskelijat on ensin koulutettava, käy ilmi, että heistä tulee hyviä asiantuntijoita valmistuessaan, mutta heidän panoksensa projektiin kokemattomuuden vuoksi ei ole kovin suuri.
Yleisesti ottaen siirrymme sujuvasti pääkohtaan, jonka avulla voimme puhua avoimen lähdekoodin projektin luomisesta - sellaisen tuotteen luomisesta, joka ratkaisee sen käyttäjien ongelmat. Kuten edellä selitin, avoimen lähdekoodin projektin tärkein ominaisuus on sen yhteisö. Lisäksi yhteisön jäsenet ovat ensisijaisesti käyttäjiä. Mutta mistä ne tulevat, kun ei ole mitään käyttöä? Joten käy ilmi, että aivan kuten ei-avoimen lähdekoodin projektissa, sinun on keskityttävä luomaan MVP (minimaalinen elinkelpoinen tuote), ja jos se kiinnostaa käyttäjiä, projektin ympärille syntyy yhteisö. Jos olet mukana luomassa yhteisöä vain yhteisön PR:n kautta, kirjoittamalla wikiä kaikilla maailman kielillä tai korjaamalla git-työnkulkua githubissa, tällä ei todennäköisesti ole merkitystä projektin alkuvaiheessa. Tietenkin asianmukaisissa vaiheissa nämä eivät ole vain tärkeitä, vaan myös välttämättömiä asioita.
Lopuksi haluaisin huomauttaa mielestäni heijastaa käyttäjien odotuksia avoimen lähdekoodin projektilta:
Harkitsen vakavasti vaihtamista tähän käyttöjärjestelmään (ainakin yritä. He pyrkivät aktiivisesti siihen ja tekevät hienoja asioita).
PS Päällä Meillä on jopa kolme raporttia. Yksi avoimesta lähdekoodista ja kaksi upotetusta (ja toinen on käytännöllinen). Osastolla pidämme mestarikurssin mikro-ohjainten ohjelmoinnista . Kuten tavallista, tuomme laitteiston ja annamme sinun ohjelmoida ne. Luvassa on myös seikkailua ja muuta toimintaa. Tule festivaaleille ja osastollemme, se on hauskaa.
Lähde: will.com