Ez az időszak nem csak a MetaMatrix stratégiai fontosságú felvásárlása miatt nagyon fontos a Red Hat és a JBoss számára, hanem azért is, mert továbbfejlesztik a fejlesztési, terejsztési és támogatási modelljüket.
Korábban a JBoss a projektek fejlesztése és támogatása során az ún. egyágú modellt alkalmazta, ami azt jelentette, hogy minden JEMS projekt minden megjelenését támogatták. Ez egy természetes feszültséget teremtett a közösség és a vállalatok között, mivel mind a két oldalnak különböző céljai vannak. A közösség célja az innováció, új jellemzők fejlesztése és azok minél korábbi és minél gyakoribb megjelentetése. A vállalatok szerepe pedig a már feltelepített megoldások támogatása a lehető legkevesebb zavaró hatással, és visszafelé kompatibilis hibajavítások biztosítása hosszútávon.
Például, ha a múltban egy projekt vezetése két fontos frissítést tett közzé egy héten valami miatt, ez azt jelentette, hogy a JBoss támogatási csapatának ezeket a megjelenéseket több évig kellett volna támogatnia. Képzeljük csak el, hogy milyen összetetté válik ez, amikor minden lehetséges projekt verziót minden lehetséges JEMS szoftverrel ötvözünk (például JBoss AS JBoss Cache-sel jBPM-mel Drools-szal Hibernate-tel), olyan kombinációs zűrzavar keletkezik, amit nehéz kezelni, és ez annál inkább igaz, minél jobban nő az ügyfelek száma, és ez pont az, ami a JBoss és Red Hat egyesülése után történik.
Ahelyett, hogy ezzel a növekvő feszültséggel foglalkoznának, jobb megoldás ennek kiküszöbölése. A JBoss ezentúl két ágban fog működni: az egyik a JBoss.org közösség ága, a másik a vállalati ág. Mi is a kettő közötti kapcsolat?
A JBoss.org szoftver az a JBoss, amit eddig is ismertünk: minden eddigi ismert és megszokott JBoss, amire ezentúl JBoss.org-ként vagy közösségként fognak utalni. Ezzel kapcsolatban semmi sem fog változni, kivéve azt, hogy a termék/platform csoportok további növekedésével a projektek fejlesztőinek több ideje lesz az innovációra és a tisztán fejlesztői munkára, mivel kevesebb, a termékesítési folyamatból eredő korlátjuk lesz.
Ami igazi újdonságot jelent, azok az „Enterprise” megjelenések. Ez úgy működik, hogy bizonyos időpontokban (általában, amikor egy JBoss.org projekt befejeződik és bizonyítottan stabil, de legalább minden 12-18 hónapban), egy „termék csoport” a kód bázisát elágaztatja majd. Ez a különálló termék csoport a projekt csoport segítségével háromféle tevékenységet fog ebben az ágban folytatni:
- Szanálás: ez a tevékenység az alap forráskódból azon jellemzők eltávolítását jelenti, melyekről a fejlesztők azt feltételezik, hogy az ügyfeleknek nem lenne célszerű használniuk éles környezetben. A legtöbb projekt alap forráskódjának részeként rendelkezik opcionális vagy kísérleti szintű jellemzőkkel. Fontos megbizonyosodni arról, hogy ezek a jellemzők nincsenek jelen vagy nincsenek elérhetővé téve az „Enterprise” ágban azért, hogy a JBoss támogatás szervezeti mottójának megfeleljen: „ha szállítjuk, akkor támogatjuk.” A Tomcat natív klaszterezés ennek tökéletes példája. A JBoss több technikai okból tipikusan azt ajánlja az ügyfeleinek, hogy Tomcat klaszterezés helyett JBoss klaszterezést használjanak. A szanáláson keresztül elkerülhető ez a zűrzavar, és meg lehet arról bizonyosodni, hogy a vállalati környezetre jóváhagyott Tomcat verzió a klaszterezés „ajánlott” verzióját tartalmazza, jelen esetben a JBoss-t.
- Termékesítési folyamat: ebben a lépésben a szoftverek finomhangolása és továbbfejlesztése zajlik azért, hogy azok az ügyfelek elvárásainak tökéletesen megfeleljenek. Minden változtatás, javítás először a közösségi ág részévé válik (upstreaming), így a szoftver következő verziója (mind a közösségi mind a vállalati) tartalmazza majd azokat a bővítéseket.
- Aggregáció/Csomagolás (opcionális): a szoftverek csomagolása is továbbfejlődik több projekt „Enterprise” platformokba való aggregálásával, így a termékek a speciális technikai jellemzők helyett a valós felhasználói eseteket helyezik középpontba. Lényegében a termékesítési folyamatban résztvevő csoportok a legáltalánosabban használt JEMS komponensek legjobb verzióit gyűjtik össze, integrálják őket és kereszttesztelést hajtanak végre a komponensekre nézve. Minden platform elérhető lesz egyéni letöltésként és minden komponenssel garantáltan, zavartalanul működik majd.
A terjesztés szempontjából a forráskód és bináris a közösségi verziókban továbbra is változtatások nélkül elérhetők lesznek. A vállalati verziók esetén a forráskód egyértelműen szabadon hozzáférhető, de a binárisok csak akkor lesznek elérhetők, ha valaki magának „build-eli” őket vagy előfizet a fejlesztői előfizetésen, termék előfizetésen vagy Red Hat Developer Studio-n keresztül.
Fontos tisztázni, hogy az „Enterprise” szoftver nem egy „kevert” verzió, melybe közösségi és nem nyílt forráskódú jellemzők is beletartoznak, hanem valójában ennek pont az ellenkezője. Az „Enterprise” verzió a közösségi verzió része, ami vállalati felhasználásra kész és akár 7 éves támogatás is garantált hozzá. Ez az új fejlesztési, terjesztési és támogatási modell nagyon hasonló a jó öreg RHEL/Fedora modellhez, mely a Red Hat Linux disztribúciójára lett alkalmazva, de mégsem teljesen ugyanaz. Míg a szabályok ugyanazok a binárisokat tekintve, a JBoss forráskód nyilvános és folymatosan elérhető a teljes vállalati életciklus tevékenység alatt, nem csak specifikus „pillanatfelvételekben”.
A támogatás csak a szoftver vállalati „Enterprise” verziójához jár. Ez lehetővé teszi a mégjobb, hosszabbtávú támogatást, negyedévenkénti kumulatív frissítésekkel (csak hibajavítások) és kétéventi frissítésekkel. Emellett fejlesztési előfizetések is vannak, amelyekben a szoftver néhány közösségi verziója támogatott, de nem ugyanazzal a szolgáltatási szinttel. A JBoss 3.x vagy 4.x jelenlegi felhasználói mindhárom verzió támogatását megkapják majd. Az új szabályok csak az Enterprise platformokra és keretrendszerekre vonatkoznak, így a korábbi verziókat ez a változás nem érinti.
A lényeg az, hogy az Enterprise platformokra való koncentrálás miatt a JBoss.org közösség több energiát tud majd az innovációra fordítani és nagyobb szabadsággal, rugalmassággal rendelkezik majd. A JBoss.org-nál történik majd a JBoss Enterprise Middleware innovációja. A projektek most már nincsenek a termékesítési ciklusokhoz kötve. Ez azt jelenti, hogy sokkal újabb technológiákat várhatunk, sokkal gyakrabban. Amint ezek a technológiák vállalati bevetésre készek, a JBoss Enterprise platformokba lesznek integrálva.