Már ezen a héten IT-fesztivál kerül megrendezésre Szentpéterváron . Az egyik előadó Richard Stallman lesz. szintén részt vesz a fesztiválon, és természetesen nem hagyhatjuk figyelmen kívül az SPÓ témáját. Ezért az egyik előadásunk címe . Ez a nyílt forráskódú projekt fejlődésének történetére fog fókuszálni. Ebben a cikkben szeretném bemutatni a főbb elképzeléseket, amelyek véleményem szerint befolyásolják a nyílt forráskódú projektek fejlődését. A cikk, akárcsak az előadás, személyes tapasztalatokra alapoz.
Kezdjük az alapkérdéssel, a nyílt forráskódú terminológiával. Nyilvánvalónak tűnik, hogy egy nyílt forráskódú projekt olyan projekt, amely rendelkezik egy olyan licenccel, amely lehetővé teszi a projekt forráskódjának hozzáférését. Ezenkívül a nyílt projekt lehetőséget teremt arra, hogy harmadik fél fejlesztők módosításokat végezzenek. Tehát ha egy cég vagy fejlesztő közzéteszi a terméke kódját, részben vagy teljesen, az még nem teszi azt nyílt forráskódú projektté. Végül minden projekttevékenységnek valamilyen eredményhez kell vezetnie, és a projekt nyitottsága azt jelenti, hogy ezt az eredményt nemcsak a fejlesztők használják.
A nyílt licenc problémáival most nem foglalkozunk. Ez egy túl nagy és bonyolult téma, amely mélyreható megvizsgálást igényel. Erről a témáról meglehetősen sok jó cikk és anyag készült. De mivel én magam nem vagyok a szerzői jog szakértője, csak annyit mondok el, hogy a licencnek meg kell felelnie a projekt céljainak. Például az Embox esetében a BSD licenc választása, a GPL helyett, nem volt véletlen.
Az a tény, hogy egy nyílt projektnél lehetőség van a módosításokra és a projekt fejlesztésére a nyílt projekt keretein belül, azt jelenti, hogy a projekt elosztott. Az irányítása, valamint a teljesítmény és integritás megőrzése lényegesen nehezebb, mint egy központosított irányítással rendelkező projektnél. Felmerül a joggal kérdés, hogy miért is készítenek nyílt projekteket. A válasz a kereskedelmi életképesség területén rejlik, bizonyos projektosztályok esetében a megközelítés előnyei meghaladják a költségeket. Tehát nem minden projekt számára megfelelő és lehet egyáltalán nyílt megközelítést alkalmazni. Például nehezen képzelhető el egy erőmű vagy repülőgép vezérlőrendszerének a nyílt alapelveken történő fejlesztése. Nem, természetesen az ilyen rendszerekbe érdemes beépíteni nyílt projektek alapú modulokat, hiszen ez számos előnyt nyújt. De valakinek a végtermékért felelnie kell. Még ha a rendszer teljes mértékben nyílt projektek kódján alapul is, a fejlesztő, aki mindezt egyetlen rendszerbe csomagolja és saját beállításokkal ellátja, lényegében lezárja azt. A kód pedig nyilvánosan elérhető lehet.
Ezekhez a rendszerekhez rengeteg előny kapcsolódik a nyílt projektek létrehozásából vagy részvételből. Ahogy már említettem, a végső rendszer kódja nyilvános maradhat. Miért, hiszen nyilvánvaló, hogy valószínűleg senkinek sincs olyan repülőgépe, amellyel tesztelni lehetne a rendszert. Ez igaz, de elképzelhető, hogy van valaki, aki szeretné ellenőrizni a kód egyes szakaszait, vagy például valaki felfedezheti, hogy a használt könyvtár nincs megfelelően konfigurálva.
Még nagyobb előnyök jelentkeznek, ha egy cég egy alapszintű rendszerelemet külön projektté alakít. Például, egy könyvtárat, amely egy adott adatcsere protokoll támogatására szolgál. Ebben az esetben, még ha a protokoll speciális is az adott területen, a költségeket meg lehet osztani más cégekkel az iparágban. Ezen kívül a szakemberek, akik nyílt hozzáférésűvé teszik ezt a rendszerelemet, sokkal rövidebb idő alatt tudják hatékonyan használni. Végül pedig a rész önálló entitásként való elkülönítése, amelyet külső fejlesztők használnak, lehetővé teszi, hogy ez a rész minőségibbé váljon, mivel hatékony API-kat kell kínálni, dokumentációt készíteni, és már nem is beszélve a tesztlefedettség javításáról.
A cég kereskedelmi előnyt szerezhet anélkül is, hogy nyílt projekteket indítana; elegendő, ha szakemberei részt vesznek más projektekben, amelyeket a cég alkalmaz. Hiszen minden előny megmarad: a munkavállalók jobban ismerik a projektet, ezért hatékonyabban használják, a cég befolyásolhatja a projekt fejlesztésének irányát, és a kész, bevált kód használata nyilvánvalóan csökkenti a költségeket.
Ezek a nyílt forráskódú projektekből származó előnyök nem érnek véget itt. Vegyük például a marketinget, amely egy fontos üzleti összetevő. Ez egy nagyon jó játszótér, amely lehetővé teszi a piaci igények hatékony értékelését.
És persze, nem szabad elfelejteni, hogy a nyílt forráskódú projekt hatékony módja annak, hogy hirdessük a specializációnkat. Bizonyos esetekben ez az egyetlen módja a piacra való kilépésnek. Például, az Embox egy OSRV létrehozására irányuló projektként indult. Nyilván nem szükséges magyarázni, hogy sok versenytárs létezik. Közösség létrehozása nélkül egyszerűen nem lett volna elég erőforrásunk ahhoz, hogy a projekt eljusson a végfelhasználóhoz, vagyis hogy a külső fejlesztők használják a projektet.
A közösség kulcsszerepet játszik a nyílt forráskódú projektben. Ez jelentősen csökkentheti a projektmenedzsment költségeit, és fejleszti, valamint fenntartja a projektet. Azt lehet mondani, hogy közösség nélkül nincs nyílt forráskódú projekt.
Számos anyag szól arról, hogyan lehet létrehozni és kezelni egy nyílt forráskódú projekt közösségét. Azért, hogy ne a már jól ismert tényeket ismételjem, az Embox tapasztalataira szeretném helyezni a hangsúlyt. Például nagyon érdekes kérdés a közösség létrehozásának folyamata. Sokak azt mesélik el, hogyan kell kezelni egy meglévő közösséget, de a létrehozásának szempontjai gyakran háttérbe szorulnak, mintha az magától értetődő lenne.
A legfontosabb szabály a nyílt forráskódú projekt közösségének létrehozásakor — nincsenek szabályok. Úgy értem, hogy univerzális szabályok nem léteznek, ahogyan ezüst golyó sem, legalábbis azért, mert a projektek nagyon eltérőek. Nem valószínű, hogy ugyanazokat a szabályokat használhatjuk egy JS naplózó könyvtár közösségének létrehozásakor, mint egy szakosodott illesztőprogram esetében. Továbbá a projekt (és ezáltal a közösség) fejlődésének különböző szakaszaiban a szabályok változnak.
Az Embox diákként kezdődött, mivel hozzáférésünk volt a rendszerprogramozás tanszék diákjaihoz. Lényegében egy másik közösségbe léptünk be. Ennek a közösségnek a tagjait, a diákokat, jó ipari gyakorlattal, tudományos munkákkal a rendszerprogramozás területén, valamint kurzus- és diplomamunkákkal tudtuk motiválni. Tehát egy alapvető szabályt követtünk a közösség szervezésében: a közösség tagjainak valamit kapniuk kell, és ennek az árának meg kell felelnie a tag hozzájárulásának.
Az Embox következő szakasza a külső felhasználók keresése volt. Nagyon fontos megérteni, hogy a felhasználók a nyílt forráskódú közösség teljes értékű tagjai. A felhasználók általában többen vannak, mint a fejlesztők. Ahhoz, hogy valaki hozzájárulóvá akarjon válni a projektnek, először így vagy úgy elkezdik használni.
Az Embox első felhasználói a Teoretikus Kibernetika Tanszék voltak. Javasolták, hogy készítsünk alternatív firmware-t a Lego Mindstormhoz. Habár ők még mindig helyi felhasználók voltak (találkozhattunk velük személyesen, és megbeszélhettük, mire van szükségük), ez mégis nagyon jó tapasztalat volt. Például kidolgoztunk demókat, amelyeket másoknak is be tudtunk mutatni, hiszen a robotok szórakoztatóak és felkeltik a figyelmet. Ennek eredményeként valódi külső felhasználók kerestek meg minket, akik érdeklődtek az Embox iránt és hogy hogyan használhatják azt.
Ebben a szakaszban elkezdtük fontolóra venni a dokumentációt, valamint a felhasználókkal való kommunikációs eszközöket. Természetesen korábban is foglalkoztunk ezekkel a fontos dolgokkal, de akkor még korai volt, és nem volt pozitív hatása. Inkább negatív hatása volt. Hozok pár példát. Használtuk a Google Code-ot, aminek a wikipédiája támogatta a többnyelvűséget. Készítettünk oldalakat több nyelven, nemcsak angolul és oroszul, amelyeken némiképp tudtunk kommunikálni, hanem németül és spanyolul is. Ennek eredményeként nagyon viccesen nézett ki, amikor valaki ezeken a nyelveken kérdezett, de mi egyáltalán nem tudtunk válaszolni. Vagy bevezettük a dokumentáció és a kommentálás írására vonatkozó szabályokat, de mivel az API elég gyakran és jelentősen változott, a dokumentációnk elavult, és több zavart okozott, mint amennyi segítséget nyújtott.
Végül minden erőfeszítésünk, még a nem tökéletesek is, azt eredményezte, hogy megjelentek a külső felhasználók. Sőt, egy kereskedelmi megbízó is megjelent, aki azt szerette volna, hogy készítsünk neki egy saját OSRV-t. Őt is kidolgoztuk, mivel már volt tapasztalatunk és néhány fejlesztésünk. Itt érdemes beszélni a jó és a rossz dolgokról is. Kezdem a rosszakkal. Mivel sok fejlesztőt kereskedelmi alapon vontak be a projekthez, a közösség, amely amúgy is elég instabil volt, megoszlott, ami természetesen nem befolyásolhatta a projekt fejlődését. További tényező volt, hogy a projekt irányát egy kereskedelmi megbízó határozta meg, akinek célja nem a projekt további fejlesztése volt. Legalábbis ez a cél nem volt a fő.
Másrészt voltak pozitív szempontok is. Valóban harmadik fél felhasználókat kaptunk. Ők nemcsak megrendelők voltak, hanem azok is, akiknek ez a rendszer készült. A projektbe való részvétel motivációja nőtt. Hiszen ha egy érdekes dologgal még pénzt is lehet keresni, az mindig kellemes. És a legfontosabb, hogy meghallottuk egy megrendelői kívánságot, ami akkor számunkra nonszensznek tűnt, de amely most az Embox alapötlete, nevezetesen, hogy már meglévő kódot használjunk a rendszerben. Jelenleg az Embox fő ötlete a Linux szoftverek használata Linux nélkül. Vagyis a projekt további fejlődésének fő pozitív szempontja az a felismerés volt, hogy a projektet harmadik fél felhasználók használják, és annak valamilyen problémáikat kell megoldania.
Akkoriban az Embox már túllépett a diákprojekt keretein. A projekt diák-modellel való fejlődésének fő gátló tényezője a résztvevők motivációja. A diákok addig vesznek részt, amíg tanulnak, és amikor diplomáznak, más motivációnak kell megjelennie. Ha a motiváció nem jelenik meg, a diák egyszerűen abbahagyja a projektben való részvételt. Ha figyelembe vesszük, hogy a diákokat először meg kell tanítani, akkor azt látjuk, hogy jó szakemberekké válnak a diploma megszerzésekor, de mivel tapasztalatlanság miatt a projektbe való hozzájárulásuk nem túl nagy.
Összességében lassan áttérünk a nyílt forráskódú projekt létrehozásának alapvető pontjára — egy olyan termék létrehozására, amely megoldja a felhasználói problémákat. Ahogy már fentebb kifejtettem, a nyílt forráskódú projekt legfőbb sajátossága a közössége. Ráadásul a közösség tagjai elsősorban felhasználók. De honnan jöjjenek, ha még nincs mit használniuk? Így hát úgy tűnik, ahogy a nem nyílt forráskódú projektnél is, koncentrálni kell a MVP (minimum életképes termék) létrehozására, és ha ez érdekelni fogja a felhasználókat, akkor közösség alakul a projekt körül. Ha pedig a közösség létrehozását csak a közösség PR-ján, minden nyelven való wiki írásán vagy a megfelelő git munkafolyamat kialakításán keresztül próbáljuk meg, akkor kétséges, hogy ennek bármilyen jelentősége lesz a projekt korai szakaszaiban. Természetesen a megfelelő szakaszokban ezek nemcsak fontosak, hanem szükségesek is.
Végül szeretném idézni , véleményem szerint tükrözi a felhasználói elvárásokat az open source projekttől:
Komolyan fontolgatom a váltást erre az operációs rendszerre (legalábbis egy próbát megér. Nagyon aktívan fejlesztik és menő dolgokat csinálnak vele).
P. S. A három előadásunk lesz. Az egyik az open source-ról, a másik kettő pedig az embeddedről (ráadásul az egyik gyakorlati). A standunknál tartunk egy mesterkurzust mikrovezérlők programozásáról . Hagyományosan hozunk vasakat, és lehetőséget adunk, hogy programozzák őket. Lesz még kvíz és más tevékenységek. Gyere el a fesztiválra és a standunkhoz, jól fogsz szórakozni.
Forrás: habr.com
