„Feljövőben” a közösségi hardverfejlesztés
Egyre ritkábban találkozunk olyan megoldással, amiben az adott termék fejlesztése teljes egészében egy fedél alatt történik. Ez a „vertikális dezintegráció” vezetett az elektronikai ipar átalakulásához, a specializálódott cégek közötti egyre szorosabb együttműködéshez és az országokon átnyúló koordinációhoz. Mivel továbbra is nagy a nyomás az alkatrészgyártókon, egyre inkább szükség van a közösségi hardverfejlesztésre.
A korábbi években az volt a jellemző, hogy a gyártás és a tervezés egy fedél alatt, egy szervezeten belül történt. Ez a helyzet idővel megváltozott, amelynek elsődleges mozgatórúgója a technológiai fejlődés és az egyre fokozódó verseny, a gyorsan növekvő piac és a kereskedelmi korlátozások részleges vagy teljes leépülése. A cégek gyors növekedése és terjeszkedése azt eredményezte, hogy a tevékenység különböző fázisai – a tervezés, a gyártás, az összeszerelés, de még a kereslet-kínálat helye is (intézményi és/vagy földrajzi értelemben) más területeken realizálódnak. Ezek a változások jelentős kihívásokat is támasztottak a cégekkel szemben, egyebek közt a szervezeti határokon átnyúló együttműködést is beleértve. Olyan esetekben, amikor különböző időzónákról, anyanyelvekről, tervezőeszközökről és munkafolyamatokról beszélünk, nem praktikus vagy költséghatékony egész projektcsapatokat felállítani.
Ígéretes minta
A nyílt forráskódú szoftverek a szervezetek közötti együttműködés leglátványosabb és legmeggyőzőbb példái. A tapasztalatmegosztás egyszerűsége és a leegyszerűsített folyamatok tették lehetővé az olcsó együttműködést és a közösségi technológiafejlesztést. A projektek mérete is nagyban eltérhet egymástól: egyesekben csak egy beszállító működik közre, de vannak nagyon komplex, több ezer beszállítóval működő folyamatok is. Nincs egyetlen programozási nyelv, fejlesztési környezet vagy irányadó struktúra a nyílt forráskódú szoftverprojektekben, továbbá a felhasznált verziók is nagyban függnek a technikai követelményektől, a személyes ízléstől vagy az adott közösség által szabott irányelvektől. Ennek ellenére általában ugyanazokat az alapfolyamatokat alkalmazzák. A projektekben részt vesznek az ún. „projektgazdák” (committers), akik „minőségellenőrként” vannak jelen, és eldöntik, hogy milyen mértékű közreműködés az elfogadható, illetve ők delegálják a munkát és határozzák meg a felelősségi köröket akár a teljes szervezetben is. A nyílt forráskódú szoftverek fejlesztésénél a forráskódot mindenki számára elérhetővé teszik, amelyet aztán a fejlesztő javíthat vagy új funkcióval bővíthet.
Ha a fejlesztő új fájlt hozott létre, elküldheti azt a projektgazdának. Ha a fejlesztő egy létező fájlt módosít, ez a módosítás összehasonlítható a már meglévő fájllal, és létrehozható az úgynevezett „diff” vagy „patch” fájl, amelyet szintén el lehet küldeni a projektgazdának. Mivel a patch fájl csak a változásokat tartalmazza, sokkal kisebb; a projektgazda ezt bemásolhatja az eredeti fájlba, és létrehozhatja a frissített verziót. A Version Control System (VCS) kulcsfontosságú a nyílt forráskódú szoftverprojektek nyomon követésében. Egyebek között követhető, hogy ki és milyen módosításokat hajtott végre, szükség esetén ezek visszavonhatók, és a fejlesztés egyes pontjain a fájlok – például a verziószámokkal – „megcímkézhetők”. Ezekben a VCS „szoftverváltozat-raktárakban” (repository) a projektgazdáknak írási joguk van, tehát a frissítéseket is elvégezhetik. A nyílt forráskódú szoftverprojektek alapvető működése nagyon egyszerű, és sikerük titka abban rejlik, hogy kikerülik az együttműködéshez szükséges eszközök és gyakorlatok szükségtelen elbonyolítását. Ehelyett olyan megoldásokkal dolgoznak, amelyek a feladatokat minimális „felhajtással” és a többi felhasználóval való legkevesebb konfliktussal végzik el. Az egyszerűségből fakadó előnyök mindinkább felkeltik a cégek érdeklődését, és egyre többen cserélik le komplex és drága eszközeiket a nyílt forráskódú projekteknél is használt módszerekre. A folyamatok adaptálása mellett el kell fogadni azt a különbséget is, hogy a szoftverfejlesztés maga sokkal inkább önálló tevékenység, nem pedig közösségi jellegű. Vannak ugyan egyértelmű különbségek a szoftverfejlesztési folyamatok és az elektronikai termékek fejlesztési folyamatai között, de számos értékes módszer átvehető, megtanulható a nyílt forráskódú szoftverprojektekből; a könnyed együttműködésben használt folyamatoktól a pragmatikus és „hiúság nélküli” technológiáig, amely például az interfészfejlesztők közötti munkamegosztásra is jellemző.
Új kihívások
Az olyan együttműködéseknél, ahol csak szöveges dokumentumok vannak, mint például specifikációk, anyagjegyzékek, HDL- és szoftverforráskódok, a fájlok szerkesztéséhez vagy kommenteléséhez a legegyszerűbb eszközök is megfelelnek. Azonban ez a hardverfejlesztésnek csak kis részét adja. Ezenkívül számos olyan input és output van, ahol a képi megjelenítés is fontos, illetve ahol speciális fájlformátumok kezelése is szükséges, például mechanikai rajzoknál és 3D-terveknél, sematikus ábráknál, illetve nyomtatott áramkörök elrendezési terveinél. A szükséges eszközök nagyon drágák is lehetnek, de a helyzetet tovább bonyolítja, hogy számos fájlformátum létezik, és az adott eszközök általában csak ezek egy részével boldogulnak. Az Electronic Data Interchange Format (EDIF) egy standard eszköz, amely megpróbál olyan semleges formátumot létrehozni, amellyel a hálózatlisták, sematikus ábrák stb. tárolhatók. Eddig mindezt nagyon kevés sikerrel tudták véghezvinni, amelynek számos oka van: nagyon „laza” a specifikáció, amely miatt inkompatibilis EDIF-verziók jöttek létre, illetve bizonyos piaci érdekek is akadályozták standardként való elterjedését. Segítséget nyújthatnak az ingyenesen elérhető eszközök, mint például a DesignSpark PCB [1], amelyet az egyes fejlesztői csoportok ingyenesen telepíthetnek, elkerülve a pénzügyi befektetést egy olyan eszközbe, amely csak egy vagy néhány projektnél használható. A nyílt forráskódú együttműködéseknél további kihívást jelent a tervezői fájlformátum, mivel ezek a legtöbb esetben bináris fájlok, és nem könnyen hasonlíthatók össze olyan fájlok létrehozása érdekében, amelyek csak a különbségeket tartalmazzák. Még a szöveges fájloknál is előfordul, hogy a teljes szöveget át kell írni mentés előtt. A legkisebb módosítás is olyan fájlokat eredményezhet, ahol a teljes tartalmat átírják, emiatt a korábbi verziókkal való összehasonlítás azt a látszatot kelti, hogy jelentős változások történtek, holott erről szó sincs. Ahhoz, hogy olyan hatékonyságot és gyorsaságot lehessen elérni, mint a nyílt forráskódú szoftverprojekteknél, a hardverek fejlesztésénél használt szoftvereknek is ugyanolyan könnyednek és pragmatikusnak kell lenniük. Vannak közös területek, és a nyílt forráskódú szoftverprojekteknél használt folyamatokhoz nagyon hasonló módszereket lehet – szinte csak egyszerű „újradefiniálással” – létrehozni, de az is előfordulhat, hogy új folyamatokat kell kidolgozni.
SolderPad
A SolderPad [2] olyan online szolgáltatás, amely megpróbálja a nyílt forráskódú szoftverprojektek előnyeit átültetni az elektronikai tervezésbe. Olyan felületet kínál, ahol megoszthatók, tanulmányozhatók és fejleszthetők az egyes elektronikai tervek. Az aktuális verziókat nyilvánosan elérhetővé teszi, amelynek célja egyértelműen a nyílt forráskódú hardverfejlesztés. A Git VCS technológiája áll a platform középpontjában: ezzel kezelhetők mind a projektfájlok, mind pedig a metaadatok, továbbá lehetőséget nyújt a repository-tartalmak kezelésére web API-n keresztül. Már a weboldal első kiadása is egyszerű lehetőséget ad képek és JSON-formátumú anyagjegyzékek importálására, továbbá többféle tervezőprogram natív fájljainak kezelésére is.
A tervek adatlapként kerülnek megjelenítésre a következőképpen:
-
sematikus ábrák és PCB-elrendezések, amelyek lapozhatók, nagyíthatók a megfelelő interfészen;
-
anyagjegyzék, amelyik alkatrészenként kereshető;
-
licenc és tulajdonjogi információk;
-
szöveges leírások;
-
címkék.
A Git Version Control System A Linux operációs rendszer fejlesztésénél és támogatásánál a Git Version Control System-et alkalmazzák, amelyben még Linus Torvalds eredeti munkája is megtalálható. A rendszer nagy hangsúlyt fektet a teljesítményre és a nem megfelelő felhasználás elleni védelemre, de ez nem is meglepő, ha figyelembe vesszük, hogy a Linux kernel több, mint 11 millió sorból áll, amelyek több tízezer fájlban találhatók meg, és amelyeket fejlesztők ezrei állítottak össze frissítéseikkel. A Git VCS egyre népszerűbb termék, amely természetes úton fejlődik és terjed. Minden fejlesztő rendelkezik a teljes repository és fejlesztési előzmény másolatával, és ezt a helyi másolatot vagy „klónt” fejleszti. Azok a fejlesztők, akik írási joggal is rendelkeznek a projekt „valahol egy szerveren” tárolt törzsadataihoz, akkor időnként feltölthetik a lokális verzión végrehajtott változtatásaikat. Ha nem rendelkeznek ezzel a joggal, akkor átadhatják valaki másnak, aki rendelkezik ilyen jogosultsággal. A Git számos fejlesztési gyakorlatot támogat. Alacsony költséggel létrehozhatók fejlesztési ágak, ahol a párhuzamos fejlesztés biztonságosan megtörténhet ún. nemlineáris formában is, mint például az egyes funkciók tesztelésénél. Ezek a fejlesztési ágak a későbbiekben – ha azokat megfelelőnek ítélik – a fejlesztési törzsbe illeszthetők, vagy egyszerűen törölhetők. Egyszerre több fejlesztési ág is létezhet, amelyek között a váltás több mint egyszerű. Más, kevésbé látható, de ugyanolyan fontos tulajdonságok közé tartozik az előzmények titkosított autentikációja, ahol a korábbi változatok nem módosíthatók, és a számonkérhetőség is biztosítva van. A Git egyik negatívuma, hogy tanulási görbéjét „nagyon meredeknek” találják azok a felhasználók, akik nem rendelkeznek nagyobb tapasztalattal az efféle rendszerek használatában. Bár ennek az akadálynak a leküzdéséhez befektetésre is szükség van, ez produktivitásban később bőven kifizetődik. A Linux kernel támogatására született rendszer most már rendkívüli népszerűségnek örvend, és 2011 áprilisában a projekt hosting tulajdonosa, a GitHUB azt jelentette, hogy egyedül náluk egymillió projekt futott, és ez a szám napi 4500-zal emelkedett. Ez nem tartalmazza a többi szolgáltató és az egyéni kezdeményezések eredményeit, valamint azokat a cégeket, amelyek saját Git repository-t használnak. Ha szeretne többet tudni a Git-ről, látogasson el a következő oldalra: http://git-scm.com/ |