Miért dolgozunk szinte kizárólag open source megoldásokkal — 25 év tapasztalat után

Van egy kérdés, ami előbb-utóbb minden bevezető beszélgetésen elhangzik: „és ti miért nyomjátok ennyire a Linuxot?” A hangsúly általában nem ellenséges, inkább gyanakvó. Mintha egy hitvitába csöppent volna az ügyfél, ahol az egyik oldalon a szakállas rendszergazdák állnak, a másikon a normális cégek, akik Windowst használnak, mert az van mindenhol.

A válasz csalódást szokott okozni, mert nincs benne semmi ideológia. Nem azért dolgozunk szinte kizárólag nyílt forrású megoldásokkal, mert szebbnek tartjuk őket, és nem is azért, mert ingyen vannak — mindjárt látni fogod, hogy a licencdíj a legkisebb tétel az egészben. Azért dolgozunk velük, mert huszonöt év alatt megtanultuk, hogy egy infrastruktúra értékét nem az adja meg, hogy mennyire jól működik jó időben, hanem az, hogy mennyi mozgásterünk marad, amikor valami elromlik: amikor a szállító megemeli az árat, amikor a gyártó kivezet egy terméket, amikor egy auditor bekéri a bizonyítékot, vagy amikor hajnali kettőkor keresni kell egy hibát egy rétegben, amit soha nem terveztünk megnyitni.

Ez a cikk arról szól, hogy pontosan miben jobb a nyílt forrás, miben nem jobb, és mikor javasoljuk mi magunk a zárt megoldást. Nem harci kiáltvány. Inkább egy döntési logika, amit szívesen odaadunk, mert a saját ügyfeleinknél is ez alapján döntünk.

Az igazi kérdés nem az ár, hanem a kilépési költség

A legtöbb open source vs zárt szoftver vita rossz kérdéssel indul. „Melyik olcsóbb?” — ez ugyanis egy pillanatfelvétel, ráadásul a legtorzítóbb pillanatban: a beszerzéskor. Az az összeg, amit aláírsz, a teljes költségnek jellemzően a kisebbik fele.

A jobb kérdés így hangzik: mennyibe kerül kiszállni belőle?

Ez a szám az, ami minden későbbi tárgyaláson meghatározza az alkupozíciódat. Ha a szállítód tudja, hogy három hónap és tízmillió forint lenne lecserélni a rendszerét, akkor pontosan tudja azt is, mekkora áremelést nyelsz le szó nélkül. Ha viszont a rendszer nyílt szabványokon fut, az adataid exportálhatók, a konfigurációd verziókövetve van, és a migráció két hétnyi tervezett munka — akkor te ülsz az asztal jobbik oldalán. Nem azért, mert fenyegetőzöl, hanem mert nem szorulsz rá.

A nyílt forrás nem attól jó, hogy ingyen van. Attól jó, hogy alacsony a kilépési költsége. Minden más előny — a kontroll, az auditálhatóság, a kiszámítható költség — ennek az egynek a következménye.

Amiben a nyílt forrás tényleg jobb

1. Kontroll: a hiba a te hatókörödben marad

Amikor egy production rendszer elszáll, két világ létezik. Az egyikben megnyitod a logokat, elolvasod a forrást, reprodukálod a hibát, és megírod a javítást vagy a workaroundot. A másikban megnyitsz egy support ticketet, és vársz.

Ez nem elméleti különbség. Írtunk arról, hogyan építettük újra egy MariaDB-Galera klasztert éles üzem közben — az a művelet azért volt egyáltalán lehetséges, mert minden réteg nyitva állt előttünk: a replikációs protokoll, a state transfer mechanizmus, a hibaüzenetek forrása. Egy zárt klaszterezési megoldásnál ugyanez a helyzet egy eszkalációs sor, ahol a te üzemkiesésed a szállító prioritási listáján egy sorszám.

A másik oldalról nézve: 2024 júliusában a világ jelentős része leállt egy zárt biztonsági termék hibás frissítése miatt, és az érintett cégek — repterek, bankok, kórházak — nem tudtak mit tenni azon kívül, hogy várták a gyártót. Erről annak idején részletesen írtunk. A tanulság nem az, hogy „a zárt szoftver rossz”. A tanulság az, hogy amikor a hiba olyan rétegben van, ahová nincs belátásod, akkor a helyreállítási időd nem a te csapatod képességén múlik.

Az üzemeltetésben az egyetlen dolog, amit tényleg meg tudsz venni, az a beavatkozási képesség. Nyílt rendszerben ez alapból megvan. Zártban külön kell megvásárolni, és akkor is korlátozott.

2. Auditálhatóság: 2026-tól ez már nem kényelmi kérdés

Évekig el lehetett adni azt a mondatot, hogy „ez egy bevált, tanúsított termék”. Ez az időszak Európában most zárul le.

Az EU kiberrezilienciáról szóló rendelete (Cyber Resilience Act) 2024. december 10-én lépett hatályba. A jelentési kötelezettségek 2026. szeptember 11-től élnek — vagyis alig több mint egy hónap múlva —, a teljes követelményrendszer pedig 2027. december 11-től alkalmazandó. Az aktívan kihasznált sebezhetőségeket 24 órán belül korai figyelmeztetéssel, 72 órán belül teljes bejelentéssel kell jelezni. A gyártóknak ezen felül folyamatosan karban kell tartaniuk a termékük komponenslistáját, az SBOM-ot.

Fordítsuk le ezt üzemeltetői nyelvre. Ha holnap megkérdezik tőled, hogy pontosan milyen szoftverkomponensek, milyen verzióban futnak a rendszeredben, és hogy egy frissen publikált sebezhetőség érinti-e valamelyiket — mennyi idő alatt tudsz válaszolni?

Nyílt forrású stacken ez egy parancs és néhány perc. Csomagkezelő, konténer-image scan, függőségi fa, SBOM generálás — mindegyik nyílt eszközzel, saját infrastruktúrán, harmadik fél engedélye nélkül. Zárt komponensnél a válasz az, hogy „megkérdezzük a gyártót”, és az általa adott dokumentumot fogadod el bizonyítékként. Ez működhet, de a felelősség attól még a tiéd marad.

Ugyanez a logika érvényes a NIS2 hatálya alá eső cégeknél is: az ellenőrzés nem azt kérdezi, hogy jó terméket vettél-e, hanem hogy tudod-e bizonyítani, mi fut nálad és hogyan reagálsz, ha baj van. A bizonyíthatóság pedig sokkal olcsóbb ott, ahol a rendszer minden rétege olvasható. Ha ez a terület még nem tiszta nálad, kezdd a szerver biztonsági checklistünkkel — az alapok legalább 80%-át lefedi.

3. Költség: nem a nulla licencdíj, hanem a kiszámíthatóság

Itt szoktak félreérteni minket. Nem azt mondjuk, hogy a nyílt forrás ingyen van — nincs ingyen, mert a szakértelmet, az üzemeltetést és a támogatást ugyanúgy meg kell fizetni. Azt mondjuk, hogy a költsége kiszámítható, mert a legnagyobb kockázatot jelentő tétel, a licencár egyoldalú megváltoztatása, hiányzik belőle.

Két eset az elmúlt két évből, mindkettő valós ügyfélfájdalom nálunk is:

A VMware-történet. A Broadcom felvásárlása után megszűnt az örökös licenc, minden ügyfél előfizetéses modellbe került, a termékpaletta néhány nagy csomagba olvadt, az árazás pedig socket-alapúról core-alapúra váltott, magas minimális magszámmal. A gyakorlati következmény az, hogy a kis és közepes környezeteknél elvész a takarékos méretezés előnye: ha húsz magot használsz, akkor is a minimumot fizeted. Volt ügyfél, aki a megújításkor többszörös árat kapott ugyanarra, amit addig is használt — és nem azért, mert többet fogyasztott. Az AT&T ügye nyilvánosan is végigment a sajtón, de a jelenség a kkv-szegmensben ugyanígy zajlott, csak halkabban. A KVM-alapú alternatívák — Proxmox VE, OpenStack — ezért kerültek 2025–2026-ban a komolyan vehető opciók közé olyan cégeknél is, akik korábban rá se néztek volna.

A Windows Server-matek. A Windows Server 2025 licencárai a 2022-es generációhoz képest nagyjából 10–20%-kal emelkedtek, de nem ez a fájó rész. A fájó rész a CAL, vagyis a hozzáférési licenc: minden felhasználó vagy eszköz után fizetni kell, aki a szerverhez hozzáfér — akkor is, ha csak egy megosztott mappát nyit meg. Nagyjából huszonöt felhasználó fölött a CAL-ok összege meghaladja magának a szervernek a licencköltségét, száz felhasználónál pedig már a többszöröse. Ehhez jön, hogy a Windows Server 2016 támogatása 2027. január 12-én lejár, tehát sok cégnél most kell dönteni — és a legtöbben ilyenkor automatikusan a következő Windows-verziót veszik meg, anélkül hogy megnézték volna, mennyibe kerülne ugyanez másképp.

Nem minden workload költöztethető. De az a tapasztalatunk, hogy egy tipikus kkv-környezetben a szerverek 60–80%-a olyan feladatot lát el — webkiszolgálás, adatbázis, fájlmegosztás, levelezés, monitoring, CI —, amihez nem kell fizetni operációs rendszer licencet. A megtakarítás nem a licencszámlán mutatkozik meg igazán, hanem abban, hogy ez a pénz átcsoportosítható redundanciára, mentésre és tényleges üzemeltetésre. Ha a felhőköltségeidnél is hasonló a helyzet, érdemes elolvasnod, hogyan lehet 30–40%-ot faragni egy felhőszámlán, és hogyan felezzük meg egy Kubernetes-klaszter erőforrásigényét ingyenes eszközökkel.

4. Élettartam: az EOL nem parancs, csak egy dátum

Zárt terméknél a támogatás vége kemény határ. Utána vagy fizetsz kiterjesztett támogatásért, vagy vállalod, hogy javítatlan sebezhetőségekkel üzemelsz. Harmadik út nincs.

Nyílt forrásnál is van életciklus, de van választás. A CentOS 2023-as irányváltása után egy hét alatt megjelentek a kompatibilis alternatívák, és a migráció legtöbbször egy szkript volt, nem egy projekt. Amikor a Terraform licence 2023-ban szigorodott, a közösség pár hónap alatt életre hívta az OpenTofu forkot, ami ma a Linux Foundation alatt fut. Amikor a Redis licencet váltott, megszületett a Valkey. Ez nem azt jelenti, hogy a nyílt forrás immunis a szállítói önkényre — épp ellenkezőleg, ezek a történetek pont arról szólnak, hogy nem az. De azt igen, hogy a fork mint kiút létezik, és ez önmagában fékezi az árazási étvágyat.

Linux vs Windows szerver: hol nem érdemes vitatkozni

Számokban a kép elég egyértelmű. A W3Techs 2026. júliusi mérése szerint az azonosítható operációs rendszerű webkiszolgálók 61,7%-a Linux, a teljes Unix-család 91,9%, a Windows 8,3%. A TOP500 szuperszámítógép-listán 2017 óta 100% a Linux aránya. A Microsoft saját dokumentációja szerint az Azure-ban futó ügyfélmagok több mint 60%-a Linux-workloadot szolgál ki. Ha a Microsoft saját felhőjében a többség Linux, akkor a „linux vs windows szerver” kérdés a legtöbb új terhelésnél már el is dőlt.

De ez csak a webes és felhős szelet. Vannak területek, ahol mi magunk javasoljuk a Windowst, és nem kelletlenül:

1. Active Directory-központú vállalati környezet. Ha a teljes identitáskezelés, csoportházirend és eszközmenedzsment AD-ra épül, akkor a Samba-alapú kiváltás elméletileg lehetséges, gyakorlatilag ritkán éri meg. A migráció kockázata nagyobb, mint a megtakarítás.
2. .NET Framework alapú, régi belső alkalmazások. Nem a modern .NET, az remekül fut Linuxon. A tíz-tizenöt éves, forrás nélküli belső rendszerek.
3. SQL Server-függő üzleti logika. Fut Linuxon is, de ha a stack köré épült ökoszisztéma — riportok, integrációk, SSIS-csomagok — windowsos, akkor a portolás egy külön projekt.
4. Gyártó által tanúsított ipari és orvosi szoftverek. Ahol a támogatási nyilatkozat konkrét operációs rendszerhez kötött, ott a saját ízlés nem szempont.
5. Specializált szakmai szoftverek — tervezőprogramok, könyvelési rendszerek, gyártásirányítás —, amiknek egyszerűen nincs érdemi alternatívája.

Ezekben az esetekben a Windows nem kompromisszum, hanem a helyes válasz. A Linux szerver üzemeltetés alapjairól szóló írásunkban részletesebben is végigvesszük, hol húzódik a határvonal.

És amiben a nyílt forrás nem jobb

Ha ez a cikk csak az előnyöket sorolná, joggal gyanakodnál. Négy dolog, amit érdemes tudni.

A nyíltság nem egyenlő a biztonsággal. A 2024-es xz-utils incidens (CVE-2024-3094) tankönyvi példa: egy támadó évekig építette a bizalmat egy nyílt projekt körül, hogy aztán hátsó ajtót helyezzen el egy olyan tömörítőkönyvtárban, ami gyakorlatilag minden Linux-rendszeren ott van. A maximális, 10-es súlyosságú sebezhetőséget végül egy mérnök vette észre, aki adatbázis-teljesítményt mért, és feltűnt neki egy furcsa processzorterhelés. Az OpenSSF elemzése helyesen mutat rá, hogy a nyíltság tette lehetővé a gyors felfedezést és javítást — de az is igaz, hogy a nyílt közreműködési modell adta meg a támadónak a belépőt. Aki azt mondja, hogy „nyílt, tehát biztonságos”, az ugyanazt a hibát követi el, mint aki azt mondja, hogy „tanúsított, tehát biztonságos”.

Nincs kit felhívni. A támogatás nem jár a szoftverhez. Vagy megveszed valakitől — disztribútortól, szolgáltatótól, tőlünk —, vagy házon belül tartod a kompetenciát. Aki nyílt forrást választ támogatás nélkül, az nem spórol, csak elhalasztja a számlát.

A licencek is változnak. Lásd fent: Terraform, Redis, Elastic. A „nyílt forrású” címke nem örökérvényű. Nagy, kritikus komponensnél érdemes megnézni, ki birtokolja a projektet, és mi történne, ha holnap üzleti licencre váltana.

A felhasználói élmény gyakran gyengébb. A zárt termékek mögött termékmenedzsment és UX-csapat áll. Egy nyílt eszköz sokszor kiválóan működik, de a beállítása több szakértelmet igényel. Ezt vagy megveszed szolgáltatásként, vagy elszenveded.

Mikor fogadjuk el a zárt megoldást

Röviden: gyakrabban, mint gondolnád. Az ügyfél dönt, mi a következményeket tesszük eléje. Öt eset, amikor mi magunk javasoljuk vagy elfogadjuk:

1. Amikor az ügyfél ragaszkodik hozzá, és érti a következményeket. Ez a leggyakoribb. Leírjuk, mennyibe kerül három év alatt, mi a kilépési költség, mi történik áremelésnél — és ha ezek után is a zárt megoldást választja, azt vállaljuk és jól üzemeltetjük. Nem sértődünk meg, és nem szabotáljuk a döntést azzal, hogy félvállról vesszük.
2. Amikor nincs érdemi alternatíva. Lásd az ipari, orvosi és szakmai szoftvereket. Itt a vita értelmetlen.
3. Amikor a belső kompetencia hiányzik, és nem is épül ki. Ha nincs, aki hozzányúljon, és nem is akar lenni, akkor a nyílt stack nem szabadság, hanem elhagyott infrastruktúra. Ez a legveszélyesebb kimenetel, és inkább vállaljuk a licencdíjat.
4. Amikor a migráció kockázata nagyobb, mint a megtakarítás. Egy működő, stabil, régi rendszert nem cserélünk le elvi alapon. Ha valami tíz éve gond nélkül fut, az önmagában érték.
5. Amikor a szerződéses vagy audit-környezet ezt írja elő. Bizonyos szektorokban a tanúsított termék nem opció, hanem követelmény.

Amit viszont mindig kérünk, az három dolog: legyen dokumentált adat-export, legyen írásban rögzített ár a szerződés teljes időtartamára, és legyen leírva, mi történik a rendszerrel, ha a szállító megszűnik vagy kivezeti a terméket. Ha ez a három megvan, a zárt megoldás is teljesen védhető döntés. Ha valamelyik hiányzik, az nem szoftverkérdés, hanem kockázatkezelési.

A látszólagos ellentmondás: GitHub, Google, Anthropic

Itt jön a rész, ahol a figyelmes olvasó megfog minket. Ha ennyire fontos a nyílt forrás, miért ajánlunk három nagy, amerikai, zárt platformot?

Mert a szempontunk soha nem az volt, hogy „nyílt vagy zárt”, hanem az, hogy kié az adat, és mekkora a kilépési költség. Ezen a mércén ez a három platform átmegy — miközben sok „szabadnak” tűnő megoldás megbukik rajta.

GitHub. A platform zárt, de a formátum nem. Egy git repository teljes története minden fejlesztő gépén ott van; egy git clone és egy saját Gitea vagy GitLab példány után egy délután alatt független vagy. A CI-pipeline-ok kicsit több munkát jelentenek, de a lényeg megmarad: a szellemi tulajdonod nem a szolgáltatónál lakik, hanem nálad, és a szolgáltató csak kényelmet ad hozzá. Erről a gyakorlati oldaláról írtunk is: hogyan automatizálunk üzleti folyamatokat GitHub Actions és mesterséges intelligencia segítségével.

Google Workspace. A levelezés, a naptár és a dokumentumkezelés az a terület, ahol a saját üzemeltetés a legrosszabb ár-érték arányt adja: a kézbesíthetőség, a spamszűrés és a rendelkezésre állás fenntartása aránytalanul drága. A Google mögött viszont nyílt protokollok állnak — IMAP, SMTP, CalDAV —, és teljes körű adatexport érhető el. Ha holnap váltani akarsz, a postafiókjaid átvihetők. Ez nem elméleti: csináltuk már. A témáról bővebben a levelezés szabadságáról és biztonságáról szóló írásunkban.

Anthropic (Claude). A nyelvi modellek súlyai zártak — ez tény, és nem szépítjük. Amit viszont nézünk: az API állapotmentes, az adataidat nem tanításra használják, a promptjaid és a workflow-jaid a te fájljaidban élnek, nem a szolgáltató adatbázisában. Az integrációs réteg, a Model Context Protocol pedig nyílt szabvány, amit más modellszolgáltatók is implementálnak. Ez azt jelenti, hogy ha holnap modellt váltunk, az automatizációink többsége megmarad — a beépülési pont ugyanaz. Ezt konkrétan is bemutattuk a Claude Code és WordPress MCP-integrációról szóló útmutatónkban, és ezen a logikán alapul az AI-automatizálási szolgáltatásunk is.

A mérce tehát nem a licenc, hanem négy kérdés. Nálad marad-e az adat? Kiexportálható-e teljesen? Nyílt formátumban vagy protokollon keresztül működik-e? És meg tudod-e becsülni, mennyibe kerül elköltözni? Ha mind a négyre igen a válasz, akkor a zárt platform is biztonságos választás. Ha bármelyikre nem, akkor a nyílt forrás sem ment meg — mert egy rosszul üzemeltetett, dokumentálatlan nyílt rendszer ugyanúgy csapda.

Hogyan néz ki ez egy tipikus ügyfélnél

Nem elvekben, hanem konkrétan. Egy átlagos kkv-környezet, amit ma szállítunk:

• Operációs rendszer: Debian vagy Ubuntu LTS, ötéves támogatási ablakkal.
• Virtualizáció: KVM-alapú, jellemzően Proxmox VE, ahol nincs magszám-alapú büntetés.
• Webkiszolgálás: nginx vagy Caddy, konténerizálva.
• Adatbázis: PostgreSQL vagy MariaDB, replikációval, tesztelt visszaállítással.
• Monitoring: Prometheus és Grafana — a részletekért lásd a szerver monitoring eszközökről szóló összeállításunkat.
• Mentés: Restic vagy Borg, három másolat, két adathordozó, egy telephelyen kívül, havi visszaállítási próbával.
• Kód és infrastruktúra: git alapon, GitHubon, de tükrözve.
• Levelezés és irodai munka: Google Workspace.
• AI-réteg: Anthropic API, nyílt integrációs protokollal.

Ez a stack nem azért néz ki így, mert szép. Azért, mert minden elemére meg tudjuk válaszolni a négy kérdést. És mert ha holnap bármelyik szállító megemeli az árat, van hova lépni.

Összegzés

Huszonöt év alatt sok technológiai divat jött és ment. Ami nem változott: a legdrágább döntés mindig az, ami elveszi a következő döntés lehetőségét.

A nyílt forrás nem erkölcsi kérdés, hanem kockázatkezelés. Kontrollt ad a hibakezelésben, bizonyíthatóságot az auditban, kiszámíthatóságot a költségben, és mozgásteret a tárgyaláson. Cserébe szakértelmet kér — ez a valódi ára, és ez nem nulla. Ahol ez a csere nem éri meg, ott mi magunk mondjuk, hogy vedd meg a zárt megoldást, csak tudd, mit veszel.

Ha épp most áll előtted egy ilyen döntés — Windows Server 2016 kivezetés, VMware-megújítás, felhőköltség-robbanás vagy egy elavult rendszer leváltása —, akkor a legrosszabb, amit tehetsz, hogy a határidő nyomása alatt automatikusan a megszokottat választod. Nézd meg, hogyan dolgozunk a felhő-üzemeltetésben és a DevOps-projektekben, vagy írj nekünk pár sort, és átbeszéljük, mennyibe kerül nálad a kilépés. Az első beszélgetés díjmentes, és nem azzal fog kezdődni, hogy Linuxot ajánlunk.