A héten informatikai fesztivált rendeznek Szentpéterváron . Az egyik előadó Richard Stallman lesz. is részt vesz a fesztiválon, és természetesen nem hagyhattuk figyelmen kívül a szabad szoftverek témáját sem. Ezért hívják egyik jelentésünket . Ez az Embox nyílt forráskódú projektként való fejlesztésének történetét mutatja be. Ebben a cikkben azokról a fő gondolatokról szeretnék beszélni, amelyek véleményem szerint befolyásolják a nyílt forráskódú projektek fejlesztését. A cikk a jelentéshez hasonlóan személyes tapasztalatokon alapul.
Kezdjük valami egyszerűvel, az opensource kifejezés meghatározásával. Nyilvánvaló, hogy a nyílt forráskódú projekt olyan projekt, amely rendelkezik a projekt forráskódjához való hozzáférést lehetővé tevő licencekkel. Ezenkívül a nyitott projekt azt jelenti, hogy a külső fejlesztők változtatásokat hajthatnak végre. Vagyis ha egy cég vagy fejlesztő részben vagy teljesen közzéteszi terméke kódját, attól még nem lesz ez a termék nyílt forráskódú projekt. Végül pedig minden projekttevékenységnek valamilyen eredményhez kell vezetnie, és a projekt nyitottsága azt jelenti, hogy ezt az eredményt nem csak maguk a fejlesztők használják.
Nem térünk ki a nyílt licencek problémáira. Ez túl nagy és összetett téma, amely alapos vizsgálatot igényel. Elég sok jó cikk és anyag született ebben a témában. De mivel én magam nem vagyok szakértő a szerzői jogok területén, csak annyit mondok, hogy a licencnek meg kell felelnie a projekt céljainak. Például az Embox esetében nem véletlenül választották a BSD-t a GPL-licenc helyett.
Az a tény, hogy egy nyílt forráskódú projektnek lehetővé kell tennie a változtatások végrehajtását és a nyílt forráskódú projekt fejlesztésének befolyásolását, azt jelenti, hogy a projekt terjesztett. Kezelése, az integritás és a teljesítmény fenntartása sokkal nehezebb, mint egy központosított irányítású projekt. Felmerül egy ésszerű kérdés: miért nyitnak meg egyáltalán projekteket? A válasz a kereskedelmi megvalósíthatóság területén rejlik; bizonyos projektcsoportok esetében ennek a megközelítésnek az előnyei meghaladják a költségeket. Vagyis nem minden projekthez alkalmas, és a nyitott megközelítés általában elfogadható. Nehéz például elképzelni, hogy nyílt elven működő vezérlőrendszert fejlesztenek egy erőműhöz vagy egy repülőgéphez. Nem, természetesen az ilyen rendszereknek nyílt projekteken alapuló modulokat kell tartalmazniuk, mert ez számos előnnyel jár. De valakinek felelősnek kell lennie a végtermékért. Még ha a rendszer teljesen a nyitott projektek kódjára épül is, a fejlesztő, miután mindent egy rendszerbe csomagolt, és konkrét buildeket és beállításokat végzett, lényegében bezárja azt. A kód nyilvánosan elérhető lehet.
Ezen rendszerek számára is számos előnnyel jár a nyílt forráskódú projektek létrehozása vagy azokhoz való hozzájárulás. Ahogy már mondtam, a végrendszer kódja nyilvánosan elérhető maradhat. Miért, mert nyilvánvaló, hogy nem valószínű, hogy valakinek ugyanaz a repülőgépe lesz a rendszer tesztelésére. Ez igaz, de lehet, hogy valaki ellenőrizni akarja a kód bizonyos szakaszait, vagy például valaki felfedezheti, hogy a használt könyvtár nincs teljesen megfelelően beállítva.
Még nagyobb haszon jelentkezik, ha a vállalat a rendszer valamely alapvető részét külön projektbe foglalja. Például egy könyvtár valamilyen adatcsere protokoll támogatására. Ebben az esetben még akkor is, ha a protokoll egy adott témakörre vonatkozik, a rendszer e részének karbantartási költségeit megoszthatja a terület más cégeivel. Ezen túlmenően azoknak a szakembereknek, akik nyilvánosan tanulmányozhatják a rendszer ezen részét, sokkal kevesebb időre van szükségük a hatékony használathoz. És végül, ha egy darabot független entitássá választunk, amelyet a külső fejlesztők használnak, akkor ezt a részt jobbá tesszük, mert hatékony API-kat kell kínálnunk, dokumentációt kell készítenünk, és a tesztlefedettség javításáról nem is beszélek.
Kereskedelmi előnyökhöz juthat egy vállalat nyílt forráskódú projektek létrehozása nélkül is, elegendő, ha szakemberei részt vesznek a vállalatnál használt külső projektekben. Hiszen minden előny megmarad: a dolgozók jobban ismerik a projektet, ezért hatékonyabban használják azt, a vállalat befolyásolhatja a projekt fejlesztésének irányát, a kész, debuggolt kód használata pedig nyilvánvalóan csökkenti a cég költségeit.
A nyílt forráskódú projektek létrehozásának előnyei ezzel még nem értek véget. Vegyük az üzlet olyan fontos elemét, mint a marketing. Számára ez egy nagyon jó homokozó, amely lehetővé teszi számára a piaci igények hatékony értékelését.
És természetesen nem szabad megfeledkeznünk arról, hogy egy nyílt forráskódú projekt hatékony módja annak, hogy bármely szakterület hordozójaként nyilvánítsuk magunkat. Bizonyos esetekben ez az egyetlen módja a piacra lépésnek. Például az Embox egy RTOS létrehozásának projektjeként indult. Valószínűleg nem kell magyarázni, hogy sok a versenytárs. Egy közösség létrehozása nélkül egyszerűen nem lett volna elegendő erőforrásunk ahhoz, hogy a projektet a végfelhasználókhoz eljuttassuk, vagyis hogy a külső fejlesztők elkezdhessék használni a projektet.
A közösség kulcsfontosságú egy nyílt forráskódú projektben. Lehetővé teszi a projektmenedzsment költségeinek jelentős csökkentését, a projekt fejlesztését és támogatását. Elmondhatjuk, hogy közösség nélkül egyáltalán nem létezik nyílt forráskódú projekt.
Nagyon sok anyagot írtak arról, hogyan lehet nyílt forráskódú projektközösséget létrehozni és kezelni. Hogy ne a már ismert tényeket meséljek újra, megpróbálok az Embox tapasztalataira koncentrálni. Például egy közösség létrehozásának folyamata nagyon érdekes kérdés. Vagyis sokan elmondják, hogyan kell kezelni egy létező közösséget, de a létrejöttének pillanatait néha figyelmen kívül hagyják, ezt adottnak tekintve.
A nyílt forráskódú projektközösség létrehozásakor a fő szabály az, hogy nincsenek szabályok. Úgy értem, nincsenek univerzális szabályok, mint ahogy ezüstgolyó sem, már csak azért is, mert a projektek nagyon eltérőek. Nem valószínű, hogy ugyanazokat a szabályokat használhatja, amikor közösséget hoz létre egy js naplózási könyvtárhoz és néhány speciális illesztőprogramhoz. Ráadásul a projekt (és így a közösség) fejlődésének különböző szakaszaiban a szabályok változnak.
Az Embox diákprojektként indult, mert hozzáférhetett a rendszerprogramozási osztály hallgatóihoz. Valójában egy másik közösségbe léptünk be. Ennek a közösségnek a résztvevőit, hallgatókat a jó ipari gyakorlatban érdekelhetnénk szakterületükön, a rendszerprogramozás területén végzett tudományos munkában, a kurzusokban és a diplomákban. Vagyis a közösségszervezés egyik alapszabályát követtük: a közösség tagjainak valamit kapniuk kell, és ennek az árnak meg kell felelnie a résztvevő hozzájárulásának.
Az Embox következő lépése a külső felhasználók keresése volt. Nagyon fontos megérteni, hogy a felhasználók teljes jogú résztvevői a nyílt forráskódú közösségnek. Általában több a felhasználó, mint a fejlesztő. És ahhoz, hogy egy projekt közreműködője lehessen, először valamilyen módon elkezdi használni.
Az Embox első felhasználói az Elméleti Kibernetikai Tanszék volt. Javasolták egy alternatív firmware létrehozását a Lego Mindstorm számára. És bár ezek még mindig helyi felhasználók voltak (személyesen találkozhattunk velük és megbeszélhettük, hogy mit szeretnének). De akkor is nagyon jó élmény volt. Például olyan demókat fejlesztettünk ki, amelyeket meg lehetett mutatni másoknak, mert a robotok szórakoztatóak és felkeltik a figyelmet. Ennek eredményeként valóban külső felhasználókat kaptunk, akik elkezdték kérdezni, hogy mi az Embox, és hogyan kell használni.
Ebben a szakaszban a dokumentációra, a felhasználókkal való kommunikáció eszközeire kellett gondolnunk. Nem, persze korábban gondolkoztunk ezeken a fontos dolgokon, de ez még korai volt, és nem hozott pozitív hatást. A hatás meglehetősen negatív volt. Hadd mondjak néhány példát. A googlecode-ot használtuk, amelynek wikije támogatta a többnyelvűséget. Több nyelven készítettünk oldalakat, nem csak angolul és oroszul, amelyeken alig tudtunk kommunikálni, hanem németül és spanyolul is. Ennek eredményeként nagyon nevetségesnek tűnik, ha ezeken a nyelveken kérdezik, de nem tudunk válaszolni. Illetve szabályokat vezettek be a dokumentáció írására és kommentálására, de mivel az API elég gyakran és jelentősen változott, kiderült, hogy a dokumentációnk elavult, és inkább félrevezető, mint amennyi segített.
Ennek eredményeként minden erőfeszítésünk, még a rosszak is, külső felhasználók megjelenéséhez vezetett. És még egy kereskedelmi ügyfél is megjelent, aki saját RTOS-t akart neki kifejleszteni. És azért fejlesztettük ki, mert van tapasztalatunk és némi alapmunkánk. Itt a jó és a rossz pillanatokról is beszélni kell. Kezdem a rosszakkal. Mivel sok fejlesztő vett részt ebben a projektben kereskedelmi alapon, a közösség már így is meglehetősen instabil és megosztott volt, ami természetesen nem befolyásolta a projekt fejlődését. További tényező volt, hogy a projekt irányát egy kereskedelmi megrendelő határozta meg, és nem a projekt továbbfejlesztése volt a célja. Legalábbis nem ez volt a fő cél.
Másrészt volt számos pozitív szempont is. Valóban külső felhasználókat kaptunk. Nem csak az ügyfél, hanem azok is, akiknek ez a rendszer készült. A projektben való részvétel iránti motiváció megnőtt. Végül is, ha egy érdekes vállalkozással is tudsz pénzt keresni, az mindig jó. És ami a legfontosabb, egy olyan vágyat hallottunk a vásárlóktól, amely akkoriban őrültnek tűnt számunkra, de amely most az Embox fő gondolata, nevezetesen, hogy már kifejlesztett kódot használjunk a rendszerben. Most az Embox fő ötlete a Linux szoftver Linux nélküli használata. Vagyis a projekt további fejlődéséhez hozzájáruló fő pozitívum az volt, hogy felismerték, hogy a projektet külső felhasználók is használják, és az ő problémáik egy részét meg kell oldania.
Ekkor az Embox már túllépett egy diákprojekt keretein. A projekt diákmodell szerinti kialakításában a fő korlátozó tényező a résztvevők motiváltsága. A hallgatók tanulás közben vesznek részt, és amikor diplomát szereznek, más motivációnak kell lennie. Ha a motiváció nem jelenik meg, a hallgató egyszerűen abbahagyja a projektben való részvételt. Ha figyelembe vesszük, hogy a hallgatókat először képezni kell, akkor kiderül, hogy a diploma megszerzésére jó szakemberekké válnak, de a projekthez való hozzájárulásuk a tapasztalatlanság miatt nem túl nagy.
Általában simán áttérünk a fő pontra, amely lehetővé teszi, hogy beszéljünk egy nyílt forráskódú projekt létrehozásáról - olyan termék létrehozásáról, amely megoldja a felhasználók problémáit. Ahogy fentebb kifejtettem, egy nyílt forráskódú projekt fő tulajdonsága a közössége. Ráadásul a közösség tagjai elsősorban felhasználók. De honnan jönnek, amikor nincs mit használni? Így kiderül, hogy akárcsak egy nem nyílt forráskódú projektnél, itt is egy MVP (minimális életképes termék) létrehozására kell koncentrálni, és ha ez érdekli a felhasználókat, akkor közösség fog megjelenni a projekt körül. Ha csak közösségi PR-n keresztül vesz részt egy közösség létrehozásában, wikit ír a világ minden nyelvén, vagy korrigálja a git munkafolyamatot a githubon, akkor ennek valószínűleg nem lesz jelentősége a projekt korai szakaszában. Természetesen ezek a megfelelő szakaszokban nem csak fontosak, hanem szükségesek is.
Befejezésül szeretném leszögezni , véleményem szerint, tükrözve a felhasználói elvárásokat egy nyílt forráskódú projekttel szemben:
Komolyan gondolkodom azon, hogy átváltok erre az operációs rendszerre (legalábbis próbálja meg. Aktívan folytatják, és remek dolgokat csinálnak).
PS Be Akár három jelentésünk is lesz. Egy a nyílt forráskódról és kettő a beágyazottról (és egy praktikus). A standon mesterkurzust tartunk a mikrokontrollerek programozásáról . Szokás szerint hozzuk a hardvert és hagyjuk, hogy programozzon. Lesz még küldetés és egyéb tevékenységek. Gyere el a fesztiválra és a standunkra, jó móka lesz.
Forrás: will.com