A korábbi években nem volt ritka, 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, elsődleges mozgatórúgója a technológiai fejlődés és az egyre fokozódó verseny lett, amely párosult a gyorsan növekvő piacokkal, illetve a kereskedelmi korlátozások megszűnésével. A cégek gyors növekedése és terjeszkedése azt eredményezte, hogy azok különböző területekre specializálódtak (például tervezés, gyártás, összeszerelés), továbbá a kereslet-kínálat helye is eltolódott.
E változások jelentős kihívásokat támasztottak a cégekkel szemben, mégpedig szervezeti határokon átnyúló együttműködést igényeltek. 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 teljes projektcsapatokat felállítani.
Ígéretes minta
A nyílt forráskódú szoftverek adják a szervezetek közötti együttműködés leglátványosabb és legmeggyőzőbb módját. Az egyszerű eszközökön történő tapasztalatmegosztás, illetve 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, vannak olyanok, amelyekben 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 úgynevezett 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 például a teljes szervezetben.
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 egy új funkcióval bővíthet. Ha a fejlesztő új fájlt hozott létre, elküldheti azt a projektgazdának. Ha egy létező fájl került módosításra, 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, így végigkísérhető, 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 „megcímkézhetők” például a verziószámokkal. Ezekben a VCS repozitorikban a projektgazdáknak írási joguk van, így 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 komplexitását.
Ehelyett olyan megoldásokkal dolgoznak, amelyek a feladatokat a legkisebb „felhajtással” és a többi felhasználóval való legkevesebb konfliktussal végzik el. Azok az előnyök, amelyek ebből az egyszerűségből fakadnak, mindinkább felkeltik a cégek érdeklődését, és egyre többen cserélik le a komplex és drága eszközeiket olyanra, amelyet a nyílt forráskódú projektek is alkalmaznak. A folyamatok adaptálása mellett el kell fogadni azt a különbséget, hogy a szoftverfejlesztés inkább önálló tevékenység, nem pedig közösségi.
Vannak egyértelmű különbségek a szoftverfejlesztési folyamatok, illetve az elektronikai termékek fejlesztési folyamatai között, de számos értékes információ átvehető, megtanulható a nyílt forráskódú szoftverprojektekből; a könnyed, együttműködésben használt folyamatoktól a pragmatikus technológiáig, amely az interfészfejlesztők között is alkalmazott.
Új kihívásoknak kell megfelelni
Az 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 legegyszerűbb eszközök is megfelelnek a fájlok szerkesztéséhez vagy kommenteléséhez. Ez azonban csak kis részét képezi a hardverfejlesztésnek, és 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. Ezek lehetnek mechanikai rajzok és 3D-s tervek, sematikus ábrák, illetve nyomtatott áramkörök (PCB) elrendezési tervei.
A szükséges eszközök esetenként nagyon drágák, és 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 olyan standardalapú eszköz, amely megpróbál semleges formátumot létrehozni, amellyel tárolhatók a hálózatlisták, sematikus ábrák stb. Eddig mindezt nagyon kevés sikerrel tudták véghezvinni, aminek számos oka van: nagyon laza specifikáció, ami miatt inkompatibilis EDIF verziók jöttek létre, illetve piaci erők, amelyek megakadályozták standardként való elterjedését.
Az ingyenesen elérhető eszközök, mint például a DesignSpark PCB segítséget nyújthatnak, valamint az egyes fejlesztői csoportok ingyenesen telepíthetik, elkerülve a pénzügyi befektetést egy olyan eszközbe, amely csak egy vagy kis számú 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 ez a legtöbb esetben bináris fájlokat jelent, amelyek nem hasonlíthatók össze könnyedén, hogy olyan fájlok is létrehozhatók legyenek, 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írják mentés előtt. A legkisebb módosítás is olyan fájlokat eredményezhet, ahol a teljes tartalmat átírják, és a korábbi verziókkal történő összehasonlítás azt sugallja, 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 folyamatokat újra lehet definiálni, de az is előfordulhat, hogy új folyamatokat kell kidolgozni.
Előnyök az elektronikában is
A SolderPad egy 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 biztosít, ahol megoszthatók, tanulmányozhatók és fejleszthetők az egyes elektronikai tervek, és 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.
| Git Version Control System |
A Git Version Control Systemet alkalmazzák a Linux operációs rendszer fejlesztésénél és támogatásánál. 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, és ezek a kódok több tízezer fájlban találhatók meg, 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 repozitori és fejlesztési előzmény másolatával, és ezt a helyi másolatot vagy klónt fejleszti. Ha a fejlesztőknek írási joguk van a projekt törzsadataiban, amelyek valahol egy szerveren találhatók, akkor időnként feltölthetik azokat a változtatásokat, amelyeket a lokális verzión végrehajtottak. Ha nem rendelkeznek ezzel a joggal, akkor átadhatják valaki másnak, akinek van ilyen jogosultsága. 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 úgynevezett nemlineáris formában, ilyenek például az egyes funkciók tesztelései. Ezek a fejlesztési ágak a későbbiekben beilleszthetők a fejlesztési törzsbe, ha azokat megfelelőnek ítélik, vagy egyszerűen törölhetők; egyszerre több fejlesztési ág is létezhet, amelyek között a váltás egyszerű. 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ámon kérhetőség is biztosított. A Git egyik negatívuma, hogy a tanulási görbe nagyon meredek, ha a felhasználó nem rendelkezik nagyobb tapasztalattal ilyen jellegű rendszerek használata terén. Ennek az akadálynak a leküzdéséhez befektetésre van szükség, ami azonban az produktivitás szempontjából igen kifizetődő. |
A Git VCS technológia áll a platform középpontjában, és ezzel kezelhetők mind a projektfájlok, mind pedig a metaadatok, továbbá lehetőséget nyújt a repozitori tartalmak kezelésére webes API-n keresztül. Az oldal kezdeti kiadása egyszerű lehetőséget biztosít képek és jsom formátumú anyagjegyzékek importálására, továbbá többféle tervezőprogram natív fájljainak kezelésére is alkalmas.
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, amely alkatrészenként kereshető; licenc- és tulajdonjogi információk; szöveges leírások; címkék.
A levonható következtetések
Az elektronikai ipar előtt hatalmas lehetőség áll, amellyel javíthatja rugalmasságát, termelékenységét, illetve szélesebb közreműködéssel valósíthatja meg projektjeit, ha átveszi a könnyen átlátható folyamatokat és a pragmatikus technológiát. Lehet, hogy a megvalósításhoz szükséges gyakorlati ötletek a nyílt forráskódú szoftverprojektek folyamataiban, illetve az egyre inkább feltörekvő hardverfejlesztés folyamataiban találhatók meg.
A SolderPad egy jó példa a nyílt forráskódú technikák ilyen célra történő felhasználására, de ez még csak az „utazás” kezdete, amelynek során esetleg még számos hasonló megoldással találkozhatunk.
