054.1 Lecke 1
Tanúsítvány: |
Open Source Essentials |
---|---|
Verzió: |
1.0 |
Témakör: |
054 Nyílt forráskódú üzleti modellek |
Fejezet: |
054.1 Szoftverfejlesztési üzleti modellek |
Lecke: |
1/1 |
Bevezetés
Hagyományosan a jogvédett szoftvereket (más néven zárt forráskódú szoftvereket) forgalmazó vállalatok üzleti modellje viszonylag egyszerű volt: a szoftver használatára vonatkozó licencet adták el, akár egyszeri díjazással, akár folyamatos alapon, előfizetéses modellben.
Az évtizedek során azonban a szoftverek piaca gyökeresen megváltozott, az ügyfelek ma már elvárják, hogy néhány dollárt fizessenek egy alkalmazásért, majd életük végéig ingyenes frissítéseket kapjanak.
Ennek eredményeképpen a szabadalmaztatott szoftverek régimódi megközelítése már nem nyereséges, és még azok a vállalatok is, amelyek korábban a teljes üzleti modelljüket a szoftverlicencek értékesítésére építették, mára a szállítói integráció, a támogatás, a szolgáltatások, a Software-as-a-Service (SaaS), a felhő/konténer hosting és a szoftvereket futtató hardvertermékek (telefonok, laptopok, szerverek, nyomtatók, autók, okosórák stb.) felé diverzifikálódtak.
Ezzel szemben a szabad és nyílt forráskódú szoftverek licencei bárkinek jogot adnak a szoftver használatára, tanulmányozására, módosítására és újraelosztására díjfizetés nélkül. A nyílt forráskódra épülő vállalkozásoknak tehát soha nem volt lehetőségük arra, hogy a szoftver használatához licencet adjanak el. Nem várhatjuk el, hogy egyszerűen átvegyük mások munkáját egy nyílt forráskódú projektből, és hatalmas profitot termeljünk azzal, hogy ezt a nyilvánosan elérhető munkát az ügyfeleinknek adjuk, mert ők ugyanazt a szoftvert ingyenesen megkaphatják közvetlenül a projektből. Ehelyett az ingyenes és nyílt forráskódú szoftvereket kínáló vállalatok alternatív üzleti modelleket alkalmaznak. A legsikeresebb szoftver üzleti modellek gyakran az ügyfélérték többféle formáját ötvözik.
Ez a lecke azt vizsgálja, hogy egy vállalat miért választja a nyílt forráskódú szoftverekkel kapcsolatos üzleti modellek némelyikét, és milyen kompromisszumokkal járnak ezek a lehetőségek.
A szoftver vagy tartalom nyílt licenc alatt történő kiadásának céljai és okai
Számos oka van annak, hogy a fejlesztők a nyílt forráskódra épülő vállalkozást választják: a szoftver kielégíthet egy igényt, megoldhat egy problémát, vagy biztosíthat bizonyos funkciókat, amelyeket a fejlesztők az ügyfeleknek szállítanak. Egy vállalat időt és pénzt takaríthat meg azzal, hogy a szoftveren végzett munkát megosztja más fejlesztőkkel, ahelyett, hogy ugyanazt a szoftvert a nulláról írná meg. A projektben való részvétel egy befektetés, amely remélhetőleg használható, stabil, megbízható, biztonságos, jól karbantartott szoftverben térül meg.
Sok nyílt forráskóddal dolgozó fejlesztő reméli, hogy hibajavításokat kap az ügyfelektől. Néhány ügyfél még magasabb szintre emeli a hozzájárulását azzal, hogy új funkciókat ad hozzá, új környezetbe portolja a szoftvert, vagy más jelentős fejlesztéseket hajt végre. Mind a hibajavítások, mind a magasabb szintű fejlesztések javítják az eredeti szoftvert. Ha az ügyfelek ezeket visszaadják az eredeti fejlesztőknek, a változtatások a kódot vonzóbbá tehetik más potenciális ügyfelek számára, és ösztönzik annak adaptálását.
Egy vállalat azonban nem számíthat hozzájárulásra és figyelemre pusztán azzal, hogy a kódját egy olyan webhelyen helyezi el, mint a GitHub vagy a GitLab. Egy dolog a fejlesztőket arra ösztönözni, hogy csatlakozzanak egy projekthez, de sokkal nagyobb kihívás őket lelkesedésükben tartani — ezért ne becsüljük alá a közösségi hozzájárulások által megkövetelt munka mennyiségét. Egy vállalatnak erőfeszítéseket kell tennie a fejlesztők toborzására, mentorálására, motiválására és a kódjuk hibakeresésére.
Egy másik ok a kód nyílttá tétele mellett egy ipari szabvány létrehozása. A kód nyílt módon történő megosztása jobb interoperabilitást és egyéb előnyöket eredményezhet. A kódot fejlesztő csapat értékes szakértelemmel rendelkezik, amely lehetővé teheti számukra, hogy irányítsák a projekt jövőjét, és fizetést kapjanak a kódot használók támogatásáért.
Egyes vállalatok azért nyitják meg kódjukat, hogy bizalmat keltsenek az ügyfelek körében. Először is, az ügyfelek tudják, hogy továbbra is használhatják és fejleszthetik a kódot, ha a vállalat kudarcot vall, vagy úgy dönt, hogy más piacra lép, és hátrahagyja a kódot. Másodszor, az ügyfelek maguk is ellenőrizhetik a kód minőségét és biztonságát, vagy független szakértőt kérhetnek fel egy audit elvégzésére, ami a zárt, védett szoftverek esetében általában nem lehetséges.
Végül pedig előfordulhat, hogy egy vállalat már nyílt forráskódú kódbázist fogad el, és kereskedelmi üzletet tervez rá építeni. A licenc előírhatja a vállalat számára, hogy a változtatások forráskódját a program bármely végfelhasználója számára terjessze.
Röviden, néhány ok, amiért érdemes nyílttá tenni egy cég kódját:
-
Egy meglévő szabad szoftver projektre építkezés
-
Az ügyfelek innovációjának és hozzájárulásainak kihasználása
-
Bizalom kialakítása az ügyfelek körében
-
A kód ipari szabványként való népszerűsítése
Gyakori üzleti modellek és bevételi források
A szoftveripar az elmúlt évtizedek során számos üzleti modellt fedezett fel, amelyek alkalmasak a saját tulajdonú és a nyílt forráskódú vállalkozások számára egyaránt. Ez a szakasz a nyílt forráskódú fejlesztők körében jelenleg használt legnépszerűbbekre összpontosít.
Az egyik üzleti modell, amely a szabadalmaztatott és a nyílt forráskódú szoftverek esetében egyaránt elterjedt, a támogatásért felszámított díj. Az ügyfeleknek gondot okozhat a szoftver telepítése és konfigurálása, a hibák kijavítása, amint azok előkerülnek, új funkciók hozzáadása a saját kizárólagos használatukra, valamint a rendszerük kezelése. A szoftvert fejlesztő munkatársak kiváló támogatási források. Valószínűleg ez a csapat már most is ingyenes támogatást nyújt azokon a fórumokon, ahol a szoftvert megvitatják.
Így a támogatási modellben az ügyfél fizet a szállítónak, hogy telepítse a nyílt forráskódú szoftvert az ügyfél hardverére (ezt nevezik self-hosting disztribúciónak), vagy hozzáférést kap a szoftverhez a szállító hardverén (felhőalapú modell). A támogatási szerződések biztosítják, hogy az ügyfelek időben segítséget kapjanak a vállalattól a bonyolultabb igényeikhez. Az ezt a modellt alkalmazó vállalatok általában előfizetéseket kínálnak, amelyekért az ügyfelek rendszeresen fizetnek.
A szabadalmaztatott szoftverek egy másik üzleti modellje — valójában egy sor egymást átfedő modell — az úgynevezett freemium, amelyet 2009-ben a szerző és szerkesztő Chris Anderson népszerűsített, és amely egy sokkal régebbi üzleti modellen, a razor and blades-en (borotva és pengék) alapul. A razor and blades modellben az ügyfelek nagyon keveset fizetnek az alaptermékért (mint egy borotváért vagy egy nyomtatóért), majd felárat fizetnek a szükséges, elhasználódásra tervezett alkatrészekért (pengék a borotvához, tintapatronok a nyomtatóhoz).
A freemium modellben az ügyfelek egy bizonyos szinten ingyenesen használhatják a terméket, és arra ösztönzik őket, hogy fizessenek a további funkciókért, ha hasznosnak találják a terméket. Bizonyára ismerjük azokat az online híroldalakat, amelyek bizonyos számú ingyenes cikket kínálnak, és arra kérik az olvasókat, hogy a teljes hozzáférésért fizessenek elő; ez a freemium modell jól ismert példája. Egy másik példa egy olyan játékplatform, amely az alapjátékot ingyenesen biztosítja, de pénzt kér az egyes eszközökért.
Más szabadalmaztatott szoftvercégek a freemium modelljüket az időre alapozzák: három hónapig ingyenesen ki lehet próbálni a szoftvert, majd fizetni kell a további használatért.
A szabadalmaztatott szoftvercégek néha a freemium modell egy változatát használják, amelyet open core néven ismerünk. Az open core esetében bizonyos alapfunkciók (a termék “magja” (core)) nyílt forráskódúak, és a további saját fejlesztésű funkciók licencelhetők.
Gyakran előfordul, hogy a nyílt rész teljesen működőképes, de kutatók vagy az egyéni felhasználók számára működik a legjobban, és nehezen kezelhetővé válik, ha sokan megosztják azt egy vállalaton belül. Ezért a védett funkciók tartalmazhatnak kényelmes webes felületeket az adminisztrációhoz, számviteli és együttműködési eszközöket, valamint egyéb, a nagy létesítmények számára különösen érdekes dolgokat.
Még ha a nyílt üzleti modellek némi nyílt forráskódú szoftvert is használnak, az ügyfelek elég okosak ahhoz, hogy felismerjék, hogy az egész termék tulajdonképpen védett. Így, bár a nyílt magnak megvan az az előnye, hogy meglévő nyílt forráskódú projektre épül, a nyílt forráskódú szoftverek egyéb előnyeit nem biztosítja. Az open core üzleti modell nem épít bizalmat az ügyfelekkel, nem ösztönzi őket arra, hogy hozzájáruljanak az alapszoftverhez, nem ad hozzáférést az ügyfeleknek a kód vizsgálatához, nem épít ki a fő vállalaton kívüli képzett fejlesztők hálózatát, és nem működik iparági szabványként. Még rosszabb, hogy az open core fejlesztési modellnek ugyanazok a fejlesztési költségei vannak, anélkül, hogy olyan előnyökkel járna, amelyek miatt megérné. Azok a vállalatok, amelyek kipróbálják az open core üzleti modellt, általában csalódnak az eredményekben, és sokan később áttérnek a tisztán szabadalmaztatott modellre.
A vállalatok nyílt forráskódú vagy jogvédett kódbázisra is építhetnek webszolgáltatást, a Software as a Service (SaaS) modellben. Az ügyfelek pedig havi vagy éves alapon fizetnek.
Sok SaaS webes szolgáltatást nyújtó vagy mobilalkalmazásokat kínáló vállalat a hirdetéseken keresztül keres pénzt. Egyes vállalatok a szolgáltatáson vagy alkalmazáson keresztül adatokat is gyűjtenek a felhasználókról, és ezeket az adatokat harmadik feleknek adják el, akik azokat reklámozásra használhatják. A reklámok azonban idegesítőnek is tekinthetők. Az adatok értékesítése ellentmondásos, és egyes országok korlátozzák az adatgyűjtést.
Végezetül a vállalatok fejleszthetnek és kiadhatnak nyílt forráskódú szoftvereket anélkül, hogy egyáltalán megpróbálnának bevételre szert tenni belőlük. Ez a modell olyan vállalatok számára elérhető, amelyek a szoftveren kívül más dolgokból is bevételre tesznek szert. Például az autógyárak együttműködnek, hogy nagy mennyiségű szabad szoftvert hozzanak létre, amelyek az autóikban futnak (amelyek ma már igen csak komputerizáltak).
Azok a nagy szoftvercégek, amelyek bevételeiket saját fejlesztésű ajánlatokból szerzik, mint például a Google és az Amazon, néha nyílt forráskódú szoftvereket vagy más hasznos eszközöket adnak ki, mivel ezek a nyílt forráskódú eszközök nem játszanak központi szerepet az alaptevékenységükben. Azok a szervezetek, amelyek nyílt licenc alatt adják ki a kódot, profitálnak a nyílt forráskódú közösség által nyújtott visszajelzésekből, hibajelzésekből és funkciófejlesztésekből.
Nyílt forráskódú szoftverek használata más technológiákban és szolgáltatásokban
Sok vállalat épít be nyílt forráskódú szoftvereket termékeibe vagy webes platformjaiba. Elvégre a nyílt forráskódú szoftverek ingyenesek! De nem ez a legfontosabb (és talán nem is a legjobb) ok az adaptálásukra. Sokkal fontosabb, hogy sok ilyen szoftver kiváló minőségű (bár a fejlesztőcsapatnak alaposan át kell vizsgálnia, mielőtt implementálná), és akár iparági szabvány is lehet.
A nyílt forráskódú szoftverek másik előnye, hogy akkor is elérhetőek maradnak, ha a fejlesztők vagy az őket körülvevő közösség megszűnik.
A szabad és nyílt forráskódú szoftverek azonban felelősséggel járnak. Ebben a szakaszban röviden felsoroljuk a legfontosabb kérdéseket, amelyeket figyelembe kell venni, mielőtt adaptálnánk.
Az első kérdés minden olyan harmadik féltől származó szoftverre vagy eszközre vonatkozik, amelynek adaptálását fontolgatják: megfelel-e a felhasználók igényeinek most és a vállalat fejlődése során? Támogatja-e a szoftvert egy erős közösség, amely technikai támogatást tud nyújtani és továbbfejleszti a szoftvert? Vannak-e a szoftverben jelentős biztonsági rések?
Ezután a vezetőségnek mérlegelnie kell a vállalat felelősségét, ha egy nyílt forráskódú projektet beépít a saját szoftverébe. Ha a fejlesztők új kódot építenek a nyílt forráskódú kód köré, akkor ellenőrizniük kell, hogy a nyílt forráskódú szoftver licencének értelmében mit kell tenniük. Egyes licencek megkövetelik a fejlesztőktől, hogy a saját változtatásaik forráskódját ugyanolyan szabad licenc alatt osszák szét a végfelhasználók között, mint az eredeti kódbázist.
Még ha egy fejlesztőnek nem is kell a módosított forráskódját terjesztenie, és a nyílt forráskódra építve egy saját terméket hoz létre, lehet, hogy bizonyos dolgokat vissza akar adni, például hibajavításokat és fejlesztéseket a nyílt forráskódhoz. Azzal, hogy a fejlesztő hozzájárul ezekhez a javításokhoz és fejlesztésekhez, lehetővé teszi, hogy a projekt beépítse azokat (ha a fő fejlesztők úgy döntenek, hogy így tesznek) és karbantartsa őket. Azoknak a fejlesztőknek, akik nem járulnak hozzá visszaadással a fejlesztésekhez, esetleg újra kell csinálniuk a javításokat és fejlesztéseket minden alkalommal, amikor az eredeti kód új verziójára frissítenek.
Emiatt a függőség miatt és más okokból is a vállalat munkatársainak fontolóra kell venniük, hogy aktív tagjai legyenek a kódot fejlesztő közösségnek. A fejlesztők a részvétel révén sokat tanulhatnak a kódról, és segíthetnek meghatározni a jövőbeli fejlesztés irányát. Természetesen a szervezetnek fizetnie kell a fejlesztők közösségi tevékenységekkel töltött idejéért. Egy olyan vállalat számára, amely komolyan gondolja a szabad szoftverek használatát, ez nincs ingyen.
A nyílt forráskódú szoftverek szempontjai az ügyfél szemszögéből
A nyílt kód több okból is nagyon előnyös az ügyfelek számára, de más kapcsolatra van szükség a vállalat és az ügyfelek között. Az ügyfeleknek meg kell érteniük a kapcsolat előnyeit és következményeit is.
A leckében korábban említett fő előnye az ügyfél számára az, hogy jobban megbízhat a szoftverben. Tudják, hogy az nem fog eltűnni. Sok szabadalmaztatott cég bezár vagy hirtelen új irányba indul el, magára hagyva az ügyfeleket, akiknek talán csak rövid idő áll rendelkezésükre, hogy áttérjenek egy olyan termékre, amelyet esetleg nem szeretnek. A nyílt forráskódú szoftver ezzel szemben nem függ egyetlen szervezettől sem. Ha a projekt számít, a közösségben más emberek folytatják a projektet, amikor az eredeti fejlesztők továbblépnek.
Az ügyfelek ellenőrizhetik a nyílt forráskódú szoftverek minőségét és biztonságát is. Megállapíthatják, hogy mennyire könnyen tudnak saját funkciókat hozzáadni vagy átportolni egy új környezetbe.
Mivel egy nyílt forráskódú projekt forráskódja mindenki számára hozzáférhető, a fejlesztők széles köre megismerkedhet vele. Egy olyan projektnél, amelynek aktív közössége van, sokan nyújtanak támogatást a fórumon. Gyakran könnyű felvenni embereket a szoftver támogatására vagy a szoftver vállalaton belüli adminisztrálására és használatára, mivel az új alkalmazottak már ismerik a kódot.
Nagyon megnyugtató az ügyfelek számára, akiknek a mindennapi működése függ a kódtól, ha tudják, hogy egy hibát saját maguk is kijavíthatnak, vagy alkalmazhatnak valakit, hogy ezt megtegye. Egy homályos, csak néhány ügyfelet érintő hiba kijavítása évekig is eltarthat, mire a fejlesztőcsapat kijavítja, ami a zárt forráskódú szoftverek felhasználóinak állandó frusztrációt okoz. Ráadásul, ha a forráskód elérhető, a hiba és a javasolt javítás gyorsabban azonosítható.
Mi a helyzet a vállalat és az ügyfél közötti kapcsolattal? A vállalat dönthet úgy, hogy pontosan olyan kapcsolatot alakít ki, mint amilyet egy tipikus saját szoftvergyártó cég kínál, rendszeres frissítéseket és támogatási szerződést biztosítva az ügyfélnek. Az ügyfélnek soha nem kell megnéznie a forráskódot, vagy csatlakoznia a közösségi fórumokhoz.
A legtöbb ügyfél azonban profitálna a nyílt forráskódú projektek által kínált egyedülálló lehetőségekből. Lehetővé tehetik saját fejlesztőik számára, hogy mind az információkkal, mind a kóddal hozzájáruljanak a munkához. Az ilyen részvétel elmélyíti munkatársaik ismereteit, segít nekik új embereket toborozni, és beleszólást biztosít számukra a jövőbeli fejlesztésekbe.
Költségstruktúrák és beruházások
A programozók iránt nagy a kereslet, így minden szoftveres erőfeszítés drága lesz. A nagyobb nyílt forráskódú projektek ismerői még keresettebbek, mivel ezeket a kódbázisokat széles körben használják.
Egy nyílt forráskódú projekt potenciális költségmegtakarítást tesz lehetővé, mivel a különböző szervezetek és magánszemélyek közös kódbázisban egyesíthetik erőfeszítéseiket. Egy ilyen projekt működtetése azonban új költségeket is okoz.
Ha egy vállalat megnyit egy saját fejlesztésű projektet, a vállalatnak be kell fektetnie abba, hogy az egy nagyobb (esetleg világméretű) közösséget szolgáljon ki. Egyes funkciókat, amelyek a vállalat szűk üzleti igényeinek feleltek meg, esetleg újra kell gondolni, hogy más vállalkozásoknak is megfeleljenek.
Ha a kód rossz vagy zavaros, a vállalatnak valószínűleg nem kellene nyílttá tennie. A potenciális közreműködőket és a potenciális ügyfeleket egyaránt befolyásolja a minőség. A fejlesztőknek amúgy is javítaniuk kell ezeket a problémákat, mert a rosszul kódolt szoftver törékeny: nehéz új funkciókkal frissíteni, és olyan összetett hibák alakulhatnak ki benne, amelyeket nehéz kijavítani. Ezeket a problémákat nevezzük technikai adósságnak (technical debt), és minél hamarabb kijavítják őket, annál jobb minden felhasználónak.
Végezetül pedig meglepő lehet, hogy milyen gyakran fordul elő, hogy egy vállalat üzleti titkokat, jelszavakat, személyekre való személyes utalásokat vagy más érzékeny információkat ágyaz be a kódba. A fejlesztőknek időt kell fordítaniuk az ilyen sebezhetőségek eltávolítására. A jelszavaknak, API-kulcsoknak, tanúsítványoknak és felhő-hozzáférési hitelesítő adatoknak amúgy sem szabadna a kódban lenniük; ezeket külsőleg, egy biztonságos szolgáltatáson keresztül kell kezelni.
Tegyük fel, hogy egy vállalat nyílttá tette a kódját, és azt reméli, hogy a külső hozzájárulásokból haszonra tehet szert. Egyes ügyfelek fizetnek a fejlesztőknek a karbantartásért és az új funkciókért. Mások a saját fejlesztőiket fogják a projektre küldeni, de az alap fejlesztőcsapatnak időt kell szánnia a támogatásukra. Az alap fejlesztőcsapatnak a külsősöket is oktatni kell a kódról és a kapcsolódó kódolási szabványokról. Ennek a csapatnak kell irányítania a külső közreműködőket is, hogy mit kell hozzáadniuk, és hova kell visszaküldeniük a kódjukkal kapcsolatos megjegyzéseket.
Vegyük észre a tehetségesnek mutatkozó kívülállókat! Ezek az egyének értékes tagok lehetnek az alapcsapatban. Lehet, hogy szívesen csatlakoznak a csapathoz, és jelentős tudással rendelkeznek.
Ha egy fejlesztőcsapat fizetést kap, míg mások önkéntes munkát végeznek, az önkéntesek úgy érezhetik, hogy kihasználják őket, vagy megkérdezhetik, miért kellene segíteniük. Minden egyes közreműködőnek, legyen az egyéni önkéntes vagy szervezet, át kell esnie a leckében korábban leírt gondolkodási típusokon, hogy eldöntse, miért vesz részt a folyamatban.
A szabad kód nem ingyenes, még akkor sem, ha nem jár licencköltséggel. Egyszerűen csak egy másik fejlesztési modellről van szó.
Gyakorló feladatok
-
Hogyan növeli a nyílt forráskód az ügyfelek szoftverbe vetett bizalmát?
-
Miért csábítják a vállalatokat, hogy kipróbálják az open core üzleti modellt, és miért nem hozza a modell a nyílt forráskódú szoftverek előnyeit?
-
Mi a saját hosztolású terjesztés (self-hosted distribution)?
-
Milyen típusú segítséget nyújtanak általában a fejlesztők a nyílt forráskódú projektjeikben közreműködő külsősöknek?
Gondolkodtató feladatok
-
Fontolgatjuk, hogy egy nyílt forráskódú projektre egy zárt forráskódú terméket alapozunk. Milyen tényezőket vegyünk figyelembe a döntés meghozatala során?
-
Több, előfizetési díjas terméket építettünk egy nyílt forráskódú projektre. Mit kell tennünk, ha a nyílt forráskódú licenc megköveteli, hogy az összes kódunkat visszaadjuk a projektnek? Néhány új kommunikációs protokoll támogatását is hozzáadtuk a nyílt forráskódú projekthez, hogy megfeleljen a saját igényeinknek. Ha van lehetőségünk rá, megkérjük-e a nyílt forráskódú projektet, hogy integrálja ezt a protokolltámogatást a kódbázisba?
Összefoglalás
Ebben a leckében meganultuk a forráskód nyílttá tételének az értékét. Áttekintettük a ma használatos általános üzleti modelleket, valamint azt, hogy miért fontos megérteni a kód licencének a hatását. Olvastunk a nyílt forráskódnak a vállalkozásába való beépítésével kapcsolatos megfontolandó kérdésekről, valamint arról, hogy a nyílt forráskód milyen előnyökkel jár az ügyfeleink számára. Azt is megtudtuk, hogy a nyílt forráskódú fejlesztés költségei miben térnek el a védett szoftverek költségeitől.
Válaszok a gyakorló feladatokra
-
Hogyan növeli a nyílt forráskód az ügyfelek szoftverbe vetett bizalmát?
Az ügyfelek ellenőrizhetik a kód minőségét és biztonságát. Abban is bízhatnak, hogy továbbra is használhatják a kódot, ha az eredeti fejlesztők nem támogatják azt tovább.
-
Miért csábítják a vállalatokat, hogy kipróbálják az open core üzleti modellt, és miért nem hozza a modell a nyílt forráskódú szoftverek előnyeit?
Első pillantásra úgy tűnik, hogy a nyílt magnak a nyílt forráskódú szoftverek összes előnyét kínálnia kell, miközben lehetővé teszi a vállalat számára, hogy továbbra is saját üzleti modellt használjon, amely licencet ad el a szoftver használatára. A gyakorlatban az open core üzleti modell nem nyújtja a nyílt forráskódú szoftverek előnyeit, miközben fennállnak a nyílt fejlesztés megnövekedett költségei is.
-
Mi a saját hosztolású terjesztés (self-hosted distribution)?
A saját hosztolású disztribúció a szoftver olyan verzióját jelenti, amely az ügyfél saját eszközein futtatható.
-
Milyen tipikus segítséget nyújtanak általában a fejlesztők a nyílt forráskódú projektjeikben közreműködő külsősöknek?
Egy projekt fejlesztői általában oktatják és mentorálják a külső közreműködőket, és ellenőrzik, hogy hozzájárulásuk megfelel-e a csapat minőségi és kódolási szabványainak.
Válaszok a gondolkodtató feladatokra
-
Fontolgatjuk, hogy egy nyílt forráskódú projektre egy zárt forráskódú terméket alapozunk. Milyen tényezőket vegyünk figyelembe a döntés meghozatala során?
Először is döntsük el, hogy a nyílt forráskódú szoftver megfelel-e az igényeinknek! Ellenőrizzük a minőségét, a nyilvánosan bejelentett biztonsági hibákat és a szoftvert körülvevő közösség állapotát! Alaposan nézzük meg a licencet, hogy szükséges-e megosztanunk a kódon végzett módosításainkat! Határozzuk meg, hogy mennyire szeretnénk részt venni a nyílt forráskódú projekt közösségében, és hogyan határozzuk meg a fejlesztők szerepét ebben a körben!
-
Több, előfizetési díjas terméket építettünk egy nyílt forráskódú projektre. Mit kell tennünk, ha a nyílt forráskódú licenc megköveteli, hogy az összes kódunkat visszaadjuk a projektnek? Néhány új kommunikációs protokoll támogatását is hozzáadtuk a nyílt forráskódú projekthez, hogy megfeleljen a saját igényeinknek. Ha van lehetőségünk rá, megkérjük-e a nyílt forráskódú projektet, hogy integrálja ezt a protokolltámogatást a kódbázisba?
Ha a projekt nem követeli meg, hogy megosszuk a kódváltozásokat, akkor valószínűleg ezt nem fogjuk megtenni, mert egy jogvédett termék esetében könnyebben felszámíthatunk előfizetési díjat. Ha mégis meg kell osztanunk a kódot, kínáljunk előfizetést egy saját üzemeltetésű disztribúcióra. Még ha nem is kell megosztani a kódot, valószínűleg meg szeretnénk kérni a projektet, hogy integrálja a kommunikációs protokollok támogatását, hogy ne kelljen minden alkalommal implementálnunk a támogatást, amikor a nyílt forráskód új verzióját telepítjük.