A GE európai IT vezetője szerint a nyílt forrás óriási rizikót jelent a vállalati szervezetekre nézve

 ( trey | 2009. december 8., kedd - 9:23 )

A General Electric (GE) európai IT vezetője azt nyilatkozta a napokban, hogy a nyílt forrású szoftver csak belső, "játszótérként" való felhasználásra jó, és az a vállalat, amely küldetéskritikus infrastruktúrájának részeként alkalmazza, az óriási rizikónak teszi ki magát. A Budapesten megrendezett "Central and Eastern European IT Leaders Summit & Expo" rendezvényen az eWEEK Europe UK egyik kérdésére válaszolta ezt Péter György, a GE európai fogyasztói és ipari divíziójának IT vezetője.

Lehet, hogy az úrra furcsán fognak nézni kollégái a kijelentése miatt, mert korábban a GE Healthcare együttműködve az Egyesült Államok egyik vezető egészségügyi szolgáltatójával Linux alapon hozott létre egy egészségügyi rendszert, amelyről az GE Healthcare rangidős alelnöke és igazgatója azt állította, hogy "kisebb rizikót jelent az ügyfelek számára, védi azok TCO-ját és végül átvezeti őket egy elavult architektúráról egy korszerű architektúrára".

Ezen kívül Matt Asay "Newsflash for GE, you're already using 'risky' open source" cikkében megjegyzi, hogy érdekes György állítása annak fényében, hogy a GE Európában és világszerte is széles körben használja a JBoss-t, a Linux-ot, az Alfresco-t, a MySQL-t és más nyílt forrású projekteket.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Péter György? György Péter? Én semmit sem találtam róla.

--
trey @ gépház

villamosmérnök.
MBA.
"több elemzői, projekt vezetői, és csoport vezetői állás"

látens bölcsész? Szerintem életében egy sort se programozott még, beadandóit is ismerős írta.

szeretem, amikor ilyen hangemberek nyilvánítanak véleményt egy általuk tökismeretlen dologról...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

"szeretem, amikor ilyen hangemberek nyilvánítanak véleményt egy általuk tökismeretlen dologról..."

de hat te most pont ugyanezt teszed :)

--
NetBSD - Simplicity is prerequisite for reliability

igen, pont ugyanannyira értelmes, mint az ő trollkodása :)

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

O'rly? :)

miért, az oracle szted olcsó és jó? :)

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Szerintem inkább erre a mondatodra reagált:
"szeretem, amikor ilyen hangemberek nyilvánítanak véleményt egy általuk tökismeretlen dologról..."

miből feltételezed, hogy nem ismerem az oracle termékcsaládját? hogy nem ajnározom körbe?

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Maradjunk annyiban, hogy a beidézett hozzászólásod alapján a szakmai felkészültséged elég gyász.
És így akkor most finom voltam. Szerintem ezeket a nézeteket ne erőltesd.

oh, megszólalt az ész.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

a pénz nagy úr:)

Mondjuk ezt nem tudhatod ... Lehet, ott van a temaban, csak egyszeruen nem ugy gondolkodik mint te (vagy en), az is lehet, hogy kapott lovet, hogy ezt mondja, es csak egyetlen lehetoseg, hogy azert mondta ezt, mert fogalma sincs mirol beszel, de ebben nem lehetunk biztosak ...

Az hogy egyetemre járt, nem jelent semmit. Ha mindennap bejárok egy üres garázsba, ott nem lesz autó...

Ezek szerint vagy:
- megszakértette
- szövegkörnyezetből kiragadták, amit mondott és félre értelmezték
- tényleg megszakértette

:D


-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

"megszakértette", mivel le lett fizetve a f*reg.

--
Írj egy e-mailt, ha itt bármi hibát találsz. ^ ^

Fura, ha valaki ellentmond a munkaadója nevében a munkaadója gyakorlatának...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Hát lehet hogy épp most csörrent 15000$ Petike számláján a feladó bizonyos "Balmer" ...

Szerintem ingyen volt ennyi esze.

Balmer az OpenBSD projektben van.

le vagy maradva, azota atjott netbsd-hez :)

--
NetBSD - Simplicity is prerequisite for reliability

Ba11mer

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Ba1me11?

Blájen

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Doblátok a padlóla le.

Olvasom a cikket, először megijedtem attól, hogy egy ilyen komoly cég így kritizálja a nyílt forrást.
Aztán eljutottam a magyar hangzású névhez. Meglepődés vége, rögtön mindent értek. Ez Magyarország.
(Azért kiváncsi leszek, a cég mit fog reagálni kollegájuk kijelentésére.)

+1 sajnos ez van, ha magyar ember megszólal nemzetközi közönség előtt, akkor rettegni kell

Vagy esetleg a rangidős naffőnök angol kijelentését nem bírta értelmezni, és azt ferdítette magyarra?

Mondjuk tényleg lehet, hogy fordítási hiba :D

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

+1
vajon how red is his popo?
:D

Csak tudnám hogy a picsába kerül egy ilyen kártékony jószág ilyen szintre...
A laikus hasonszőrűek elméjében az ilyen nyilatkozatok akkora károkat okoznak az opensource számára, hogy RS joggal perelhetné
---
Why use Windows, if you have open doors… to Linux

mi az az rs es mi koze az open source-hoz?

--
NetBSD - Simplicity is prerequisite for reliability

Gondolom R.M.S.-re gondolt, de "én sem értem", hogy mit is akart ezzel mondani.

igen RMS, de képletesen és erősen túlozva értettem.
hagyjuk...
---
Why use Windows, if you have open doors… to Linux

Dilbert szerint úgy, hogy gyorsan előléptetik, mert alsóbb szinteken több kárt tud okozni:)

Micsoda egy dilettáns bérenc...
A Siemens-Philips-GE triumvirátusból a GE az egyetlen, amely az MR és CT berendezésein nem Windows-t, hanem Linux-ot futtat. A Linux alapú munkaállomásukat többek között itthon is fejlesztik. Eszerint a betegek is nagy veszélynek vannak kitéve?

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Én kész vagyok magam kitenni ekkora veszélynek. :)
---------------------------
Oszt jónapot!

Hello!

A Siemens is fejlődőképes, éppen tegnap/ma tartottam egy embedded Linux bemutatót a szegedi kollégáknak.

Nekem egyszer 76 percig bootolt a céges gépem (Windowst), erre azt mondtam a főnökömnek, hogy rendben, ezt ma még órabérben végigvártam, de első dolgom lesz Linuxot telepíteni. Azóta Linuxot használok, holott az nálunk hatóságilag tilos. Engem meg nem érdekel.

A Siemensnél nagyon erős az alulról jóvő "használjunk nyít forráskódú programokat" kezdeményezés, de a management mindenképpen pénzt akar fizetni a drága és gyakran hitvány programokért.

De fejlődnek, talán éppen amiatt, hogy állandóan dünnyögöm az igét a fülükbe, meg a Linuxos pólóm, bögrém is sokat segített...

Érdekes egy cég lehet, ahol "hatóságilag tilos" és mégis lehet használni. Tehát nem tilos.
Amúgy meg az ilyen management-ről mindig a pénzügyi elfogultság jut az eszembe. Kis országunk hírhedt a fejlett korrupcióról.

--
robyboy

Szerintem a Windows nem felhasználóbarát.
Ha az lenne, nem utálnám.

Nem biztos. Lehet, hogy most kapta meg a gépére a 7-es Vindózt, vagy a 2010-es Ofiszt, és el van ájulva az új játékszertől.

Szerintem akkora cégnél, mint a Philips, a Siemens és a GE biztos, hogy használnak nyílt és zárt forrású szoftvereket is. Pláne, ha az egyes divíziók hírből ismerik egymást.

Az orvosi informatikában jobban számít szerintem, hogy milyen a célszofter, mint az, hogy alatta milyen oprendszer fut. Mindegyik program tud crash-elni. Az oprendszer úgy is ki van csontozva. Az megint egy kérdés, hogy milyen egyszerű kicsontozni egy nyílt és ez zárt oprendszert egy célfeladatra. Mindenki kérdezze csak meg magától.
Abban a szegmensben, amiről beszélek minden cég Unix-szal indult 10+ évvel ezelőtt (vagy az a cég, amit a nagy cég később megvett). Az egyik migrált Linuxra. Biztos, hogy a Linux-ra történő migrálás is emberes munka lehetett. A másik cég átnyomult Windows-ra. A GE-nél is van olyan egészségügyi eszköz, ami Windows alapú.
Most játszunk el azzal a gondolattal, hogy át szeretne a cég térni az operációs rendszer újabb változatára. Lehet persze azt mondani, hogy a termék életideje alatt nem kell upgrade-elni. Mert bizony NT4-et még lehet látni itt-ott. De a termék fejlesztésének közben haladnia kell a korral. Nyilván Linux alatt is munkát jelent egy upgrade. Az alapokban komoly különbségek lehetnek. Játszd le magadban, hogy mit jelenthet áttérni 2.6.11-es kernelről 2.6.30-as kernelre a célapplikációval. Utána pedig a szoftver fejlesztő olvasók belegondolhatnak egy Windows - Vista migrációba. Hogy jobb a dokumentáció? ROTFL. Lehet járkálni Developer workshopra, meg rendelgetni a könyveket. A másik lehetőségnél ott van a doksi az ember orra előtt. Instabil API? ROTFLWMAOPIMP.

Azért milyen az a Windows XP munkaállomás, ahol a célszoftver csak rendszergazdaként indul el és az egyszerűbb használat érdekében üres a jelszó? Még akkor is kamikaze dolog, ha nincs interneten, hanem csak a lokál hálót látja (most egy negyedik nagy cég termékéről beszélek). Ha wírusirtót teszünk rá, akkor meg csökken a teljesítmény... A SunOS-esen, IRIX-en már évtizedek óta természetes volt, hogy aminek nem kell root, az user-ként fut.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Tulajdonképpen mi az, ami miatt az alkalmazás nem átemelhető egy nt4-es környezetből egy újabb windowsra, vagy egy linux 2.6.11-ről egy 2.6.30-ra? Kernel driver? Libek? Mert elvileg mindkét rendszeren megvan a bináris kompatibilitás.

Egyébként arról nem az os tehet, hogy a programozó nem képes új leprogramozni egy alkalmazást windowsra, hogy annak ne kelljen rendszergazdai jogosultság.

Ezt meg csak most nézem: "Windows - Vista migráció" :)

> Az oprendszer úgy is ki van csontozva.

Hát, ez se biztos, csak ha a gyártó foglalkozik ilyesmivel.
Ha meg nem, az onnan látszik, hogy a spektrumanalizátoron lehet pasziánszozni. :))

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

Tektronix powah? :-D

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Ja, akkor a válaszom "is". :))

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

"ROTFLWMAOPIM"
:D:D
ezt részleteznéd a gyengébbek kedvéért? (mint én :P) mert nem mindegyik részletet vágom
---
Why use Windows, if you have open doors… to Linux

Azóta Linuxot használok, holott az nálunk hatóságilag tilos.

hatóságilag :))

De fejlődnek, talán éppen amiatt, hogy állandóan dünnyögöm az igét a fülükbe, meg a Linuxos pólóm, bögrém is sokat segített...

JIHHIHIHIHHI

Belegondoltam ahogy a mánágerek beszélgetnek egymás között... "Te, ez a Fuszenecker Robi már hónapok óta Linuxos bögréből issza a jaffát, lehet hogy át kellene térnünk a nyílt forrásra!"

HungiBungi, minek már megint a személyeskedés? He? Ejnye!
Valószínűleg nem a linuxos bögre miatt térnek át Linuxra, ahogy máshol sem ez történik.

Valószínűleg nem a linuxos bögre miatt térnek át Linuxra

Pedig végülis más magyarázat tényleg nem nagyon lehet rá... :))

Hülye! Majdnem megfulladtam a torokgyógyító cukromtól! Gyilkos!

Hatóságilag Tilos: Anarchia

--
Vittem a buliba egy üveg sósavat. Oldódjon a hangulat...

A szegedi kollégák egy része (Siemens PSE) már 4-5 éve is embedded Linux projekten dolgozott...:)

Nem beszélve az egyéb belső Linux / open-source belső projektekről amiket csináltunk. Valamelyik másik hozzászóló írta, hogy a Siemenses MRI / CT /stb. gépeken Windows fut. Én 2004-2005 környékén voltam egy olyan belső Siemenses embedded Linux konferencián, ahol többek között:
* Siemens MRI készülék képalkotó részének Linuxra portolása
* Linux alapú UMTS bázisállomás
volt a téma.

Összességében nekem az volt a tapasztalatom, hogy biztosították a szükséges eszközöket a hatékony munkához. A notebookomon pl. Linux volt + VMware-ben a standard Windows desktop. Az asztali gépemen csak Windows. De volt több Linuxos szerverünk (ClearCase, Subversion, Trac, build szerverek ... stb.)

Üdv,
Gergely

A betegek nem, csak a cég.

Én azt bírom az ilyen ítéletekben, hogy az esetek 99%-ában simán igazak pl. a zárt forráskódú rendszerekre is. Magyarul, semmi értelme az egésznek, csak hangulatkeltés. Az sokkal szomorúbb, hogy a sok sutyerák meg mind megeszi, amit elé dobnak.

Szerk.: Jah, és erről jutott az eszembe:

" Gondolkozni nehéz, ezért legtöbben ítélnek. "
( Márai Sándor )

--
robyboy

Szerintem a Windows nem felhasználóbarát.
Ha az lenne, nem utálnám.

Maximalisan egyetertek a fickoval, valoban nagy kockazat. Ez nem azt jelenti kizart hogy alkalmazzak, de valoban nem art 100x menggondolni. Sok iparban nem szabad a bandwagenre ugralni, mert erosen pofara lehet esni. Eloszor is nem art azt fixalni, hogy nagy cegekrol es nagy volumenu projektekrol van szo, nem pedig apro cegek adhoc modon osszerakott projektjeirol. A masik amit nem szabad elfelejteni, hogy nem bebetonozott, mar 10 eve letezo opensource termekekrol van szo, hanem dinamikusan valtozo projektekrol (pl linux kernel).

Miert is lehet rizikos ? Pl:
- Mivel opensource, felhalmozott tudas a cegben keves van rola, ergo nagy az indulo befektetes. Eleg arra gondolni, milyen munka lehet mondjuk egy *nix kernel behegesztese vagy alkalmazasa egy celhardveres platformon (nem pedig egy mezei PC-n amin Pistike el tudja inditani) es annak rendes kitesztelese. Ha az opensource termek raadasul nem is arra a kornyezetre van tervezve/optimalizalva (pl elosztott OS), akkor a hegesztes folyamata meglehetosen el tud durvulni. Plusz, mivel nem oda szantak, a teljesitmenyevel szinte garantaltan problemak lesznek, ami - mint az uriember emlitette - mission critical termekekhez elengedhetetlen.

- Mire valamibol termek lesz, sokeves fejlesztesen esik at. Mire a vegere ernek, nem hatrany, ha a projekt meg letezik. Az sem hatrany, ha a projekt menet kozben es a vegen is olyan iranyban jarja be az elet rogos utjat, ami a cegnek is megfelelo. Pl kritikus patchek, kritikus fejlesztesi iranyok belekerulnek. Ezt, mivel opensource, nem lehet kontrollalni, hacsak nem vagy benne az iranyitasban igen erosen. Ez a megoldas pedig mar csak nyug, mert akkor jarsz a legjobban, ha te iranyitod ugy, ahogy akarod - azaz nem opensource alapon csinalod.

- Hasonloan eleg problemas a dokumentacio minosege (sot, egyaltalan a meglete).

- Hasonloan problemas lehet a cucc minosege (ertsd: mennyire teszteltek ki).

- Eleg komoly problema a tamogatas kerdese, foleg a fentiek tukreben.

- Meglehetosen nehez egy hatalmas es ismeretlen kodbazisban turkaszas idejenek becslese, azaz projekt tervezes szempontbol eleg nagy kockazat az, ha a projekt felenel kiderul hogy a behalaszott opensource cucc alapvetoen hasznalhatatlan a feladatra architekturalis okokbol, csak ezt elfelejtettek megemliteni (vagy egyaltalan atgondolni) az adott projektben.

Osszegezve: a nyereseg az ilyen projekteknel maximum abbol adodhat hogy a meglevo kodbazist nem kell megirni, a jovore nezve valoban nagy rizikot jelent ha opensourcebol dolgoznak. Ha pedig ez igy van, akkor igencsak valos es realis alternativa egy meglevo kereskedelmi termek megvetele az opensource helyett. Peldanak okaert megvenni az OSE oprendszert a Linux kernel helyett...

A cegek opensource iranyba haldasaban azt tudom elkepezelni ami nagyjabol zajlik is: maga a ceg tervez vmi celszoftvert, amikor az kesz es mukodik, akkor megnyitja a tobbieknek, de a fejlesztest tovabbra is koordinalja. Azaz kifele mukodik, de nem befele.

1-4: hol számít, hogy open vagy closed source?
5: rakás támogatott open source szoftver van.
6: ha más által fejlesztett zárt forrású szoftverről derül ki, hogy problémás, akkor végképp nem tudják módosítani. Saját fejlesztésű zárt forrású helyett nyilván első sorban saját fejlesztésű nyílt forrású jön szóba.
"realis alternativa egy meglevo kereskedelmi termek megvetele az opensource helyett"
Megint csak: ha más termékét veszik meg, miért kisebb rizikó, mint nyílt forrásút használni?

Megegyszer, lassan: nem szamit, ami szamit (mint irtam, de utalom magamat ismetelni):
- nem kell a bandwagonra ugralni mert pofara lehet esni, ergo nem inditunk minden uj technologiaval komoly projektet
- nagycegek garazscegekkel szoba sem allnak. A termekek amikrol szo van azok nem kiscegek termekei, sok helyen hasznaljak es trial mindig jar hozzajuk.
- a dokumentacio *enyhen szolva* 100x jobb mint barmelyik opensource cuccnal

A kovetkeztetes egyezik azzal amit irtam.

"ha más termékét veszik meg, miért kisebb rizikó, mint nyílt forrásút használni?"
Sarkitasz. A kerdes nem relevans ahhoz amit irtam. Olvasd el meg1x.

"nem kell a bandwagonra ugralni mert pofara lehet esni, ergo nem inditunk minden uj technologiaval komoly projektet"

Persze, és ebből lehet is arra következtetni, hogy nyílt forrású szoftverek használata lehet rizikós. És az is, hogy zárt forrású szoftvereké is lehet. Szóval minden lehet rizikós, ha megfelelő tervezés nélkül csináljuk, de ezt eddig is tudtuk.

"A termekek amikrol szo van azok nem kiscegek termekei" "a
dokumentacio *enyhen szolva* 100x jobb mint barmelyik opensource cuccnal"

Itt milyen konkrét termékekről beszélsz? Ha jól gondolom, az előző hozzászólásodban még nem beszéltél konkrét termékekről.

Nyilván vannak olyan zárt forrású programok, amikre igaz, amit írtál, és olyan nyílt forrásúak is, amiket nagy cégek fejlesztenek, és jó a dokumentációjuk.

"nagycegek garazscegekkel szoba sem allnak."

Ezt tippeled, vagy tudod? Elsőre a win7 dvd/usb tol esete ugrott be, és szerintem nem egyedülálló, hogy kisebb dolgokkal kis cégeket bíznak meg. De én se tudok pontosat.

"Ezt tippeled, vagy tudod?"
Tudom. De ha te nem, az mar sokat elarul, szoval hagyjuk is a kerdeskort.

Láttam már nagy cégnél bazi nagy céget pofára esni a drága sz@rával, és ugyanott, ugyanarra a feladatra egy garázscég (mit garázs? panel félszoba cég) az opensource alapú megoldása tökéletesen bevált. A cégek azzal állnak szóba, aki aze lvárásaiknak megfelelő megoldást le tudja tenni az asztalra. Ha az egy Novell vagy RedHat és a Linux, meg a többi hótt veszélyes opensource megoldás, akkor azzal, ha meg a Microsoft, az Oracle vagy az SAP, akkor az életfogytig nyugodt alvást és biztos jövőt nyújtó vendor lock-in és a nagy cég fizetős, zárt cucca.

"A cégek azzal állnak szóba, aki az elvárásaiknak megfelelő megoldást le tudja tenni az asztalra."

Ha ezt komolyan gondolod még sohasem jártál ilyen multi közelében. Szó sincs róla hogy ez elég lenne. A megoldás kell PLUSZ megfelelés a beszállítói elvárásoknak. Ez egy rakás plusz kondíciót jelent, kiemelkedő pénzügyi stabilitást, működő minőségbiztosítási rendszert, FDA megfelelést, stb. nem sorolom. Megnézném melyik panelszobában lévő faxgép menne át a GE beszállítói auditon mint potenciális beszállító...

Ezt írtam: "...aki az elvárásaiknak megfelelő megoldást le tudja tenni az asztalra." Ebbe tökéletesen beleillik az is, amit mondtál: a megfelelő megoldásnak nemcsak működnie kell (az valóban csak a szükséges de nem elégséges feltétel), hanem a mögöttest is hozzá kell venni, azt, amit te is írtál -- pl. hogy legyen ISO (meg más) ilyen/olyan papírja a cégnek.

"Láttam már nagy cégnél bazi nagy céget pofára esni a drága sz@rával, és ugyanott, ugyanarra a feladatra egy garázscég (mit garázs? panel félszoba cég) az opensource alapú megoldása tökéletesen bevált."

vs

"Ebbe tökéletesen beleillik az is, amit mondtál: a megfelelő megoldásnak nemcsak működnie kell (az valóban csak a szükséges de nem elégséges feltétel), hanem a mögöttest is hozzá kell venni, azt, amit te is írtál -- pl. hogy legyen ISO (meg más) ilyen/olyan papírja a cégnek."

Mukodhet a panelceg termeke szuperul, szo se rola. Meg is fogjak venni - de nem a termeket, hanem a ceget max mindenestul. Hogy szerzodnenek vele, azt kizartnak tartom. A kiscegek nem allnak tul jol az ilyen versenyekben, mert hatranyban vannak. Nem tehetnek rola, de ez a helyzet. Meg ha minden papirja meg is lenne, akkor sem fognak vele szerzodni.

Dehogynem.
A kiscég összeáll vmi nagynevű semmit-se-csinálunk, de nevünk van consulting céggel, aki a nevét adja, és a kiscég már bent is sertepertél a -terminus technikus jön - "nagycég"-ben.

Miert? Lehet hogy pl. a Microsoftnak (tudod az kis garázscég) dolgozik.

Szeretjük a sztereotípiákat, mert ilyenkor egy időben két helyről hallható a hülyeség.

Én már szívtam sokat egy nagy cég által fejlesztett, sokak által használt java-s alkalmazásszerverrel, mert a tonna dokumentációban nem találtam meg azt a néhány fontos részletet, ami nekem kellett.
Nagyságrenddel gyorsabban végeztem volna a forráskód átolvasásával, de ehelyett kénytelen voltam a loglevel-t finomabbra állítani és a több 10 Mb-nyi logot áttúrva rájönni, hogy hol a hiba.

Valoban szereted oket mert most arra panaszkodsz hogy voltal olyan bena hogy a reszletes leirasok ellenere sem tallatad meg amit kerestel es ebbol vhogy oda lyukadsz ki hogy a jo leiras nem jo leiras. Erdekes.

A dokumentáció minőségét nem oldalszámban/kg-ban, polcon elfoglalt méterben, hanem használhatóságban mérik. Ha van 100 oldal, ami használható, releváns és tapasztalatok alapján fontos infót tartalmaz, az jobb, mintha van másfél méter használhatatlan rizsa.

Amiről te beszélsz, az sztm nem opensource spcifikus.

Mivel opensource, felhalmozott tudas a cegben keves van rola, ergo nagy az indulo befektetes
A termék bevezetési időigénye nem függ össze a licenszeléssel.
Bármely új technológiáról (pl .Net) elmondható.
Mivel opensource, a tudás meglelhető az interneten.

Mire valamibol termek lesz, sokeves fejlesztesen esik at. Mire a vegere ernek, nem hatrany, ha a projekt meg letezik.
A termék életciklusa nem függ össze a licenszeléssel.
Proprietary fejlesztéseknél ez nem fordulhat elő? Ott aztán tényleg kuka, ha megakad a fejlesztés.

Hasonloan eleg problemas a dokumentacio minosege (sot, egyaltalan a meglete).
A dokumentáltság nem függ össze a licenszeléssel.
Ha a (saját/proprietary) fejlesztés a szarul dokumentált, ugyanúgy nagy a betanulási idő.
Ha nyílt a forráskód, legalább van esélyed annak tanulmányozásával a dokumentációs hiányosságokat pótolni, nem csak fekete-doboz módszerrel kísérletezel.

Hasonloan problemas lehet a cucc minosege
A minőség nem függ össze a licenszeléssel.
Bár nem vagyok akkora szakértő, hogy elintézzek egy WebSphere/GlassFish/JBoss/WebLogic minőségbeli összehasonlítást egy mondatban, de sztm ezt így általánosan kijelenteni merész dolog.

Eleg komoly problema a tamogatas kerdese, foleg a fentiek tukreben.
Ha van rá piaci igény, lesz cég, aki supportálja.

a nyereseg az ilyen projekteknel maximum abbol adodhat hogy a meglevo kodbazist nem kell megirni, a jovore nezve valoban nagy rizikot jelent ha opensourcebol dolgoznak.
vs
Mivel opensource, felhalmozott tudas a cegben keves van rola, ergo nagy az indulo befektetes

A cegek opensource iranyba haldasaban azt tudom elkepezelni ami nagyjabol zajlik is: maga a ceg tervez vmi celszoftvert, amikor az kesz es mukodik, akkor megnyitja a tobbieknek, de a fejlesztest tovabbra is koordinalja.
És ennek tükrében hogyan értékelnéd az előző (általam is idézett) kijenetéseidet?

Azaz kifele mukodik, de nem befele.
Azaz írjon meg egy apache/nginx/akármilyen http szervert, írjon j2ee stacket, mert akar egy helloworld rendszert?

"Amiről te beszélsz, az sztm nem opensource spcifikus."
De igen.

"A termék bevezetési időigénye nem függ össze a licenszeléssel."
De igen. Eleg ha az OSE leirasokba belenezek vagy a linux kernelebe. Nagysagrendi kulonbseg van csupan az ebbol adodo tanulasi idoszakban.

"Mivel opensource, a tudás meglelhető az interneten."
Ez egy oriasi myth es abszolut nem igaz.

"Proprietary fejlesztéseknél ez nem fordulhat elő? Ott aztán tényleg kuka, ha megakad a fejlesztés."
Sarkitasz, nem errol szol a hozzaszolasom. Ismetlem: garazscegekkel nagy cegek nem allnak szoba. A bedoles rizikoja lenyegeben zero es itt a rizikorol van szo. Ellenpeldat mindenre lehet hozni, csak nem erdemes.

"A dokumentáltság nem függ össze a licenszeléssel."
"A minőség nem függ össze a licenszeléssel."
Ha logikailag nem is vezetheto le, megis megfigyelheto a jelenseg. Es ezek nem egyes peldak, ezek nagy altalanossagban is igazak. Az okokrol ertelmetlen vitazni ebben a szalban, mert a hozzaszolas nem azt celozta meg.

"Ha van rá piaci igény, lesz cég, aki supportálja."
Ismetlem: garazscegekkel nagy cegek nem allnak szoba. Foleg nem azokkal akik eppen pont arra jottek letre.

"Azaz írjon meg egy apache/nginx/akármilyen http szervert, írjon j2ee stacket, mert akar egy helloworld rendszert?"
Meg lennel lepve hany nagycegnel csinaljak ezt. Az okok valtozatosak, de a realitas az, hogy ez van.

Osszegezve: az eddigi hozzaszolasok azt tukroztek hogy nagy cegnel nagy volumenu projektet meg nem lattatok; vagy a hozzaszolasoknal ezek szompotjait nem vettetek figyelembe; ezert szoltam hozza. Az uriember egy adott nezopontbol nezi a kerdest es en abbol a nezopontbol teljesen meg tudom erteni az aggalyait. Aprosagokba kar belekotni, a nagy kepet kell nezni osszessegeben.

bocsánat, hogy közbeszólok... de kíváncsiságból érdekelne, hogy honnan ez a "beható tudás"?
tényleg, minden kötekedés nélkül kérdezem...

Tudom, ez az ország nem valami nagy, és nem egésszen nevezhetőek a projectjei nagyszabásúaknak. Viszont láttam már országos méretű projecteket én is, de eddig egyszer sem írtuk újra az apache-t például...

+1

nagy multi sw fejlesztő cégnél dolgozva láttam már jó pár dolgot, és nekem az a
személyes tapasztalatom, hogy sok esetben jobbak az opensrc megoldások (linux kernel,
java könyvtárak, j2ee cuccok), viszont bizonyos feladatokra opensrc megoldások nem
nyújtanak megoldást, ilyenkor érdemes/muszáj/szükséges kereskedelmi terméket használni.

BTW pont egy spec. propertiary oprendszerrel jártunk úgy (több százezer eladott végpont)
hogy bizonyos javításokat egyszerűen nem voltak hajlandóak megcsinálni, kb. 0 rugalmassággal
reagáltak a kéréseinkre. Ez azért elgondolkodtató.

A vendor lock-in-ről még lehet nem hallott. :) Persze ha a vendor jó akkor nem gond, de általában bármilyen váltás eléggé erőforrás igényes.

"Ez azért elgondolkodtató."
Gondolkodj csak. Mint emlitettem, mindenre van ellenpelda, csak nem feltetlen erdemes vele dobalozni (ertsd: semmi koze a temahoz es sehova se vezet).

már elég érdekes az érvelésed, ne is haragudj. Te is csak egyedi példákat tudsz
mondani, mint bárki más, nekem egy nagy multinál ez a tapasztalatom, másoknak
is. A adott célra a megfelelő megoldás kell, és sokszor az opensource (ami
egyébként egy teljesen általános elnevezés, attól, hogy valami opensource se
nem jobb, se nem rosszabb) "termékek" megfelelő megoldást adnak.

Ja, és attól, hogy opensource, attól még nem biztos, hogy ingyenes...

Ezt ne nekem mondd, hanem az uriembernek aki ilyet ir:
"bizonyos feladatokra opensrc megoldások nem nyújtanak megoldást, ilyenkor érdemes/muszáj/szükséges kereskedelmi terméket használni."

Ami opensource fel van hasznalva az iparban, az szinte mind fizetos (licensz plusz tamogatas) es komoly ceg iranyitja a fejlesztest, mert ilyen apparatus kell minosegi termekhez. Ha egy vallalat bele akar szolni komolyabban a fejlodesbe, azt nem napi commitolgatassal fogja megtenni, hanem rendes, cegek kozott egyeztetett, uzleti modon. Vagy meg sem teszi.

A fizetos opensource uzleti megoldasokat epit es szallit, kihasznalva a sok kodmonkeyt. Az ingyenes 99%a hobbicelokra es minicegekek megfelelo. Ez nem lenezes, az is egy piac; nekem is nagyon jol szokott jonni ha eppen ott kell.

"kíváncsiságból érdekelne, hogy honnan ez a "beható tudás"?"
Egyreszt nem gondolnam hogy ez a tudas tulsagosan behato lenne, ez egy velemeny, ami ertelemszeruen a sajat tapasztalatbol szarmazik. Nem az eszt akartam osztani, csak elmondani a velemenyem :)

Masreszt volt szerencsem tobb kulonbozo helyzetben lenni, ami segitette az ilyen iranyu tapasztalatok szerzeset. Azt gondolom hogy aki atfogobb tapasztalatokkal rendelkezik arra erdemesebb figyelni, mintha egy szuk terulet zsenije/szakija lenne. Itt nem magamra celzok, hanem arra hogy en is ilyen emberekre figyelek inkabb, foleg ha ilyen riziko kerdesrol van szo, ahol mind a technikai mind az uzleti oldalnak megvannak a buktatoi.

Egyebkent nem eppen egy rossz tapasztalat pl ujrairni az apacsot, meglepoen sokat lehet belole tanulni. Amikor nekiallsz egy ilyen projektnek (nem feltetlen az apacsra celzok), akkor jossz ra, mennyit szamit a minosegi dokumentacio, amiben nem csak az API van benne meg a szep kod szep kommentekkel, hanem a teljes design leiras a design dontesek okaival egyutt. Ilyenek lehetnek pl korabbi pofara esesek leirasai, meresek es kiertekelesek eredmenyei, stb - csupa olyan dolog, amit lehetetlen a kodban kommenttel hatekonyan dokumentalni.

Egyebkent nem eppen egy rossz tapasztalat pl ujrairni az apacsot, meglepoen sokat lehet belole tanulni. Amikor nekiallsz egy ilyen projektnek (nem feltetlen az apacsra celzok), akkor jossz ra, mennyit szamit a minosegi dokumentacio, amiben nem csak az API van benne meg a szep kod szep kommentekkel, hanem a teljes design leiras a design dontesek okaival egyutt. Ilyenek lehetnek pl korabbi pofara esesek leirasai, meresek es kiertekelesek eredmenyei, stb - csupa olyan dolog, amit lehetetlen a kodban kommenttel hatekonyan dokumentalni.
Ezek meglétéről proprietary projektek esetén hogyan tudsz meggyőződni?
Szerinted ha egy projekt forráskódját nem adják ki, akkor a felépítését dokumentáló leírást, a döntés hátterének okait feltáró - inkább belsőnek tekinthető, a know-how részét képező - dokumentációt kiadják?

Az az érzésem, hogy neked a fejedben megragad egy két terméknév, és azokat mantrázod: OSE, apache.
Konkrétumokat legyél szíves mondani, hogy ne csak azzal szembesüljünk, hogy "tapasztalat", hanem olyasfélével, amit nem tudunk megcáfolni, mert igazad van.

A "mesterrel" (Péter György) - és veled is - az a baj, hogy általánosságban beszélt.
Lehet ilyen általánosságokat puffogtatni, de ez olyan dolog, mint kijelenteni, hogy "a Windows/szőke ember/stb semmire se jó".
Aki raciolnálisan közelíti a problémát, tudhatja, hogy mi lehet a kijelentésnek a hátterében, de azt is tudja, hogy nem igaz.

Az OSE marketinged ;-) mindenesetre bevált, felkeltetted az érdeklődésemet:
- Az van vmi fejesztői környezet?
- Ki tudnám valahol próbálni, láthatom valahol működés közben?

Szerk: Lehet hogy alapfogalmakkal van a gond:
Te mit értesz mission critical alatt?

"Ezek meglétéről proprietary projektek esetén hogyan tudsz meggyőződni?"
Ez mar egy teljesen masik kerdes amire valaszoltam, semmi koze az opensource vs zart kod szalhoz. Plusz volt benne egy celzas egy masik korabbi beszolasra hogy a jo dokumentacio az == a szep koddal illetve kommentezessel.... Bocs ha felreertheto volt :)

Azert mantraztam 1-2 peldat, hogy ne kelljen 40 reakcioval szembesulnom es valaszolgatni egyenkent. Gondolom sejted mi lenne ha szepen irnek egy listat: mindenki kikapja belole azt ami szerinte nem jo es ott allok 40 ember valaszaval, ami 40 iranyba visz. Forumon nem egyszeru erdemben vitazni, mar a mostani szanaszet rohanast sem lehet kezben tartani ;) Konkretat ugyanazert nem fogsz tobbet kapni tolem, amiert a cvmet sem postolom ide. Maganugy :) Ha nem ismered azt amirol beszeltem, akkor amugy sem fogod nekem elhinni, akarmit irok, nem igaz ? Sot, ha meg ide is postolnam mit csinaltam, a kovetkezo reakcio az lesz hogy johat papirja lehet hogy van rola, de... Mint a cikkiro eseteben tortent ugyebar...

"A "mesterrel" (Péter György) - és veled is - az a baj, hogy általánosságban beszélt."
Egyetertunk, altalanossagrol volt szo, ez a cikk celja is, ahogy mondod. Nem ertem ezzel mi a baj :) Mivel sok felhasznalo kozelit az opensource fele, ezert a kerdes mint altalanossag merult el, nem pedig egy konkret projektrol volt szo. Nem lehet egy projektet ket kulonbozo modon megcsinalni, dontesre kenyszerulsz, igy az osszehasonlitasok mindig santitanak valahol.

Nem volt szandekom az OSEt reklamozni, pusztan azert szerepelt, mert kereskedelmi termek, hozzaferheto a leirasa es a referenciak, szemben pl olyan belso fejlesztesekkel, amiket hiaba emlitek, aki nem azzal dolgozik, soha nem hallott roluk. Ha kicsit guglizol, hamar meglesz az, foleg hogy a linux kernellel hasonlitottam :)

Mission critical alatt azt ertem, ami a ceg fo terulete, vagy fontos neki. Ilyen lehet pl az, hogy a ceg vilagelso valamiben es ezt a helyet meg akarja orizni, vagy oda torekszik. Vagy pl jobbat akar nyujtani, mint mas, pl teljesitmeny vagy megbizhatosag vagy akar funkcionalitas teren. Ilyenkor nagyon is realis lehetoseg az, hogy ujrairod pl a protocol stacket, a http szervert, stb. Azert ha korbenezel, hogy hany olyan opensource projekt van, ami cegek belso munkajabol fakad, akkor sztem erteni fogod mire gondolok (pl erlang, tipc, akar a unix alapok, stb...).

Tehát akkor az erlangot használni: "very, very risky?"
Ez az az OSE ( http://www.enea.com/Templates/Product____27017.aspx ), amelyikhez eclipse, gdb a development környezet?

Ez a mondat az eredeti postombol megvan ?

"A cegek opensource iranyba haldasaban azt tudom elkepezelni ami nagyjabol zajlik is: maga a ceg tervez vmi celszoftvert, amikor az kesz es mukodik, akkor megnyitja a tobbieknek, de a fejlesztest tovabbra is koordinalja. Azaz kifele mukodik, de nem befele."

Tehat az kerdezed, hogy very very risky-e egy eredetileg zart forraskodu, kifejezetten egy adott celra keszult nyelvet es kornyezetet hasznalni, csak azert, mert a ceg kesobb open source-sza tette ? Nem, nem az. Elkaptad a lenyeget...

"A cegek opensource iranyba haldasaban azt tudom elkepezelni ami nagyjabol zajlik is: maga a ceg tervez vmi celszoftvert, amikor az kesz es mukodik, akkor megnyitja a tobbieknek, de a fejlesztest tovabbra is koordinalja. Azaz kifele mukodik, de nem befele."
Ha a GE alkalmazza az Ericsson erlangját az kintről befele, jegyzem meg.

mert a ceg kesobb open source-sza tette ? Nem, nem az. Elkaptad a lenyeget...

I think open source is great for own internal playground type of things but if it's running vital mission critical applications - networks running on open source for example - then that is a huge, huge risk to the organisation,” he said.
Köszönöm a választ: Tehát a kockázat a licenszelésből adódik.

"Ha a GE alkalmazza az Ericsson erlangját az kintről befele, jegyzem meg."
Igen, igy van. Ez egy pelda a sok kozul, de sosem egyrol volt szo, hanem altalanossagrol; ezert a megallapitas bar helyes, valojaban nem valasz vagy erv az eredeti mondatra.

Amirol en beszelek, az ez a *jelenseg* es az ezekbol fakado riziko: az erlangot 86ban kezdtek, 98ban adtak ki opensource-ra. Most 2009 van. Egy idezet az erlang oldalarol: "The Erlang 4.7 specification. A very ambitious document that tries to describe in detail exactly the semantics of Erlang 4.7. The specification is 10 years old and does not reflect the language exactly as it is today."

Ha mar mindenaron peldanyositani akarod az altalnos jelenseget...

Tenyleg erdekelne, miert van az a kenyszered, hogy minden kerdest korulbelul 1 mondatban le akarsz irni vagy eldonteni ? Ahogy elnezem, sok hozzaszolo hasonlo cipoben jar. Ugy tunik ezen igyekezetben korulbelul a lenyeg 90%-a teljesen figyelmen kivul marad, az osszkeprol nem beszelve. Egy osszetett es szubjektiv temakorben ez eleg erdekes hozzaallas. Az embernek mar szinte az az erzete tamad, hogy valojaban nem a parbeszed a cel...

Igen, igy van. Ez egy pelda a sok kozul, de sosem egyrol volt szo, hanem altalanossagrol; ezert a megallapitas bar helyes, valojaban nem valasz vagy erv az eredeti mondatra.
Ha valaki eclipse-t használ, akkor valójában egy egykori IBM WebSphere Application Developert használ. Az eclipse határozottan jobban használható, mint a WSAD volt.
Ha netbeanst, akkor egy egykori cseh garázscég munkáját, a xelfit.
Ha Qt-t akkor Trolltech (most már Nokia) cuccot.
stb, stb...
Tehát a Te érvedre-elvedre az "irányokról: bentről-kifelé" szólóan sztm ellenérv, válasz, mert ezeket a cuccokat nem csak a kifejlesztő cég használja nagy sikerrel.

A legtöbb nagy nyílt forráskódú projekt mögött sztm mindig van legalább egy nagy cég. - Ha nem lenne, az egész még ennyire se lenne stabil.
Sok önkéntessel végzett fejlesztés tényleg azt eredményezné, amit Te mondtál, és sztm te ebből is indulsz ki - általánosítasz: az 1 fős projekteket a 100-1000 fejlesztővel rendelkezővel mosod össze.

Tenyleg erdekelne, miert van az a kenyszered, hogy minden kerdest korulbelul 1 mondatban le akarsz irni vagy eldonteni
Elnézve a hozzászólásaim leütésszámát, ezt nem mondanám. (inkább az ellenkezőjétől tartok, a Beküldés gomb megnyomásakor, az első hozzászólásom pont emiatt nem tudott első lenni, mert gd beelőzött :-))
Én kértem konkértumokat tőled, hogy ne 1 mondatos kinyilatkoztatásokról szóljon a dolog.
Elhiszem a tapasztalataidat, PGY tapasztalatait is meg tudom érteni (a SAP-os összehasonlítást kiváltképp), de azért, mert azt tapasztaltam, hogy bizonyos területeken nem tudtuk bevezetni az egyik CÉG termékeit, vagy elhasaltak (láttam ilyet, a Németországból érkező rendszermérnökök is), nem mondanám azt hogy a CÉG termékeinek használata very-very risky - pláne, ha akkora főnök vagyok, mint PGY.

Te (és PGY) akartad 1 mondattal kijelenteni, hogy a nyílt forráskód nagyobb kockázat, mint a zárt forrású rendszer.
Én ezt azzal cáfoltam, hogy amit Te mondasz dokumentációról, bevezetési problémákról, minőségről, nem annak az elvnek az eredménye, amit nyílt forráskódnak hívnak.

Meg még azt szerettem volna mondani, hogy a fent említett szempontokat figyelembe véve, az is helytálló mondat, és egyenértékű a Te és PGY kijelentésével, hogy "using proprietary solutions are very very risky.", és a kockázatok ugyanazok lehetnek, sőt olyanok is keletkezhetnek, amelyek a nyílt forráskód esetén nem (vendor-lock-in).

És arra szerettem volna utalni, hogy a kockázatok és mellékhatások ;-) nem a licenszelésből adódnak, hanem a fejlesztők munkájának minőségéből...
Az opensource már úgy része a (gazdasági és informatikai) rendszernek, hogy az ilyen "csak internal playgroundnak jó" kijelentések sztm elég meredekek.

Peace.

huh :)

"ezeket a cuccokat nem csak a kifejlesztő cég használja nagy sikerrel"
Termeszetesen vannak olyan open source termekek amik elkapjak a jo iranyvonalat es stabil, jo minosegu es megbizhatova valnak (ezek mogott szinte mindig cegek allnak). Eclipse-t pl en is szeretem, csakugy mint azokat, amik erosen hasonlitanak fizetos termekekre, de ingyen vannak. De ez egy dolog. :)

Ket komment az eclipsehez, mint peldahoz:
1. a riziko itt is megtalalhato, mert ha pl a nagy ceged ezt hasznalja es mondjuk megszunik az egyik alprojekt tamogatasa vagy fejlesztese (mint egy idoben a visual designere volt), akkor az rad eros hatassal van. Esetleg veglegessel. Termekek eletciklusanak megszunese mashol is van, termeszetesen, de azok zokkenomentesebbek, mert jo elore lehet tudni mi varhato a termekvonalban, az opensourceban ez joval docogosebb.
2. A dokumentacio es az online informcio erosen limitalt az eclipse eseteben (is), amennyiben sikerul egy olyan teruletre nyulnod, ami nem a mainstream (nekem sikerult).

"A legtöbb nagy nyílt forráskódú projekt mögött sztm mindig van legalább egy nagy cég. - Ha nem lenne, az egész még ennyire se lenne stabil. "
Egyetertunk. Ez azt is jelenti hogy a nagyvallalti fejlesztesi kultura es moral ha megvan, akkor a riziko kisebb, mintha nem lenne meg. Marpedig ez a legtobb open source termeknel nincs meg. A sikereseknel megvan, ez vilagos; ezek merteke azonban nem eri el a fizetos termekeket. Legalabbis szerintem.

"miert van az a kenyszered, hogy minden kerdest korulbelul 1 mondatban le akarsz irni vagy eldonteni "
Ez nem a sorok szamara vonatkozik, hanem arra, hogy egy komplex kerdeskor osszetevoit fogod, kiszeded es egyesevel utkozteted egy masik ervvel, majd a vegen eljutsz oda, hogy nincs is problema, holott a processz soran mas, mar emlitett szempont is szoba kerul, amit te lazan kihagytal, mert elszigetelten nezed az egyes pontokat. Tehat az ervelesre vonatkozott a megjegyzes :)

"Te (és PGY) akartad 1 mondattal kijelenteni, hogy a nyílt forráskód nagyobb kockázat, mint a zárt forrású rendszer. "
En azt tudom kommentelni amit en mondtam, mert az o gondolatait nem tudom olvasni :) A kovetkeztetesem valoban ez, de mint emlitettem, nem a licensz miatt gondolom igy, hanem az azt korulvevo jelensegek miatt.

"Az opensource már úgy része a (gazdasági és informatikai) rendszernek"
Egyetertek, es orulok is neki, mert az en eletemet is megkonnyiti, en is sokat hasznalok beloluk. Annak csak orulni tudnek ha meg tobb opensource cucc allna be a sikeresek moge elsosorban minosegben es a jol eltalalt absztrakciok teren. Esetleg ha az igazi innovacio is megjelenne a palettan a sok masolgatas mellett :)

Ha megszűnik az xyz. fejlesztőeszköz vagy annak valamely moduljának a támogatása/fejlesztése, akkor aki használta/használja/használni akarja, akkor mi lesz? A kóddal kapcsolatban két lehetőség van: zárt, vagy nyílt forrás. Ha zárt, akkor sz0póág, ha nyílt forrású a cucc, akkor két lehetősége van. Az egyik, hogy nem akar vele foglalkozni _senki_, az aktuális felhasználója sem, ekkor valóban sz0póágon van. A másik meg az, hogy továbbra is lesz, aki karbantartja a cuccot. Vagy más, vagy saját maga. Ha saját maga (ugye a szoftver beszerzésével nulla költsége volt, amit ott megspórolt, most belerakja áll neki, akkor teljesen szabad keze van a fejlesztésben/bővítésben/módosításban, wendor lock-in gyakorlatilag nincs.

Attol hogy nyilt a forras, nem feltetlen engedi meg a linensze hogy te akarhogy modositsd kereskedelmi celokra. Akar te, akar masik ceg akit felberelnel. Lasd a korabbi valaszom neked, kapcsolodik ehhez.

Az ilyen "belenézhetsz" forrást nem tartom nyílt forráskódnak, nem is nagyon tudok hirtelen ilyet mondani... Te tudsz? Csak hogy tudjuk, mit kell elkerülni, ha nem akarjuk magunkat és a cégünket kitenni mindenféle kósza veszélynek...

Pl. Windows ;)

Az érvelésed szerintem ott hasal el, hogy úgy véled, az open source megoldásokat házon belül állítják szolgálatba, miközben nagyvállalati felhasználókról beszélsz.
Ugyanúgy, mint a proprietary, az open source megoldások esetében is preferált a kész megoldások külső beszállító általi szállítása (lásd: core competence), de amennyiben Ti az SAP-t házon belül telepítettétek fel, mert olyan tökjó dokumentációja volt, ám legyen igazad.
Többször utalsz garázscégekre, amelyek hipp-hopp megszűnnek, bezzeg a nagyok... Azt hiszem, az elmúlt évek nagyvállalati hírei alapján elég sok szép nagy céget lehetne kijelentésed alapján legarázscégezni.
Mindeközben úgy csinálsz, mintha a vállalatoktól csak proprietary megoldásokat lehetne vásárolni, ezek szerint Te nem hallottál olyan cégekről, mint Red Hat, Novell, Canonical, amelyek ugyan tudom, hogy garázscégek, úgyhogy nem érdemes velük foglalkozni ;)

A nagy képet sajnos nem látom, nem olyan a munkám (de ezek szerint Te jó eséllyel valamilyen számítástechnikai tanácsadócégnél dolgozol (minden negatív felhang nélkül))

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Az a cég, amely azért nem vált technológiát, mert az emberei nem értenek hozzá - a mondat elhangzásakor megy tönkre, kerül versenyhátrányba.
Olcsóbb felvenni az új technológiák ismerőit, mint az adódó versenyhátrányt más módon ledolgozni.
Amelyik pedig fejlődni akar, kirugdossa a sok 40-es 50-es, stb régivágású emberét és felveszi a 20-30-as korosztály ifjú padawanjait.
Hogy ez jó, vagy sem - más kérdés.

az eddigi hozzaszolasok azt tukroztek hogy nagy cegnel nagy volumenu projektet meg nem lattatok
De láttam. Multinacionális cégek. Használnak apache-ot, ibm http servert (ja, az is apache), batikot, fopot, eclipse a fejlesztőeszköz. Migrálnak.
Nem érdekli őket a kernel API doksija. AIX esetén se érdekelte őket. Mert nem kernel modult akarnak fejleszteni, hanem ügyfélnyilvántartást.

Le se szarják, h opensource, mert kapnak/vesznek támogatást JBoss-ra, RHL-re, stb - ez a fontos.
Nem garázscégektől: 20-30-40 fős cégektől.
Persze a 20-30-40 fős cégek között van olyan, aki, amikor kezdte "garázscég" volt (5-6 emberrel) - annál a "multinál".
Kicsi volt a kínálat, be kellett vele érni, nem bánták meg, mert a cég velük együtt nőtt, stratégiai szövetség jött létre köztük.

Meg lennel lepve hany nagycegnel csinaljak ezt. Az okok valtozatosak, de a realitas az, hogy ez van.
Ahogy látom, te rendszermagtól webstackig mindent fejlesztenél... ezek alapján a munkahelyed csakis a google lehet :-D.

Sztm rossz témakörökben kapirgálsz:
Ne a one-man-show FLOSS projektekre gondolj, hanem olyanokra, mint apache, linux/*bsd kernel, postgresql, mysql, jboss, Qt. Ezek vannak olyan minőségűek, dokumentáltságúak, mint a nem opensource változataik, sőt.

Nem azt mondom, hogy az OpenSource csak sikerrel végződhet. De sztm nem abból adódik a kudarc, első sorban. Amit láttam, az a megfelelő átgondolás hiányára, buzzwordoknek bedőlésre, alkalmazottak inkompetenciájára, pozícióféltésére volt inkább visszavezethető.

A Vendor-lock-in sztm hasolnóan nagy problémája ezeknek a cégeknek, mint az általad felnagyított bizonytalanság, pedig a "saját" technológiákkal való operálás csak oda vezethet.

Maradjunk annyiban hogy a "20-30-40 fős cégek" garazscegek es akkor talan erted mit akarok mondani.

Sokan hozzaszoltatok, de ugy tunik egyiktek sem vette a fardtsagot hogy a GE-hez hasonlo nagyceg helyzetebe kepzelje magat. Legtobb ellenerv meg mindig abbol a felreertesbol szarmazik, hogy amit ti nagynak gondoltok, az nekem (es a hozzaszolas szempontjabol ez szamit) kicsi. Lehet ezt folytatni, csak nem erdemes, amig el nem fogadjatok hogy mirol beszelunk.

En megertem hogy az akar 100 vagy 1000 fos ceg nem fog nekiallni OSt fejleszteni vagy mondjuk OSEt venni, vagy apache-ot fejleszteni de a nagycegek viszont igen. Nem azert mert nagyok, hanem azert mert olyan (ismetelten mondva) mission critical esetleg specialis kornyezetben hasznaljak a cuccot, amiben az apache nem muzsikal fenyesen. Nem azert mert vacak, hanem mert nem arra terveztek es lehet jobban csinalni. Ilyenkor jon a dilemma, hogy mit lehet csinalni - ez pedig a riziko resze, amirol szo van. Abba is gondolj kicsit bele, hogy ha N masik ceg arul apache-ot, akkor megis mitol lesz az egyik jobb, mint a tobbi. Attol, hogy nem (az eredeti) apache van benne...

"Maradjunk annyiban hogy a "20-30-40 fős cégek" garazscegek"

Ember, vegyél már vissza egy kicsit az arcodból. Magyarázhatod hogy mekkora hülyeséget mondtál attól még nem lesz jobb. Itt _nem_ a GE-ről van szó aki igenis használ opensource szoftvereket (amiről a belinkelt oldal is tanúskodik, légyszi olvasd el a hírt mielőtt hülyeségeket írsz), hanem a magyar nagyfejűről aki azt nyilatkozza hogy a nyílt forrás ellen csakis szentelvízzel lehet harcolni.

Amúgy nagyon kiváncsi vagyok milyen cégről beszélsz amelyik simán ír magának egy OS-t, webservert, stb, stb. (Nekem ebből az jön le hogy simán baromságokat beszélsz)

U.I.:A belinkelt cikkben benne van hogy a GE MySQL-t használ, pedig amit ők csinálnak (egészségügy) az tényleg Mission Critical. Akkor most hogy van? Azt mégse maguk fejlesztették? Akkor mégis jó esetleg Mission Critical környezetben is a opensource?

a felteteleket majdnem teljesiti a morgan stanley :)

Az hogy azt mondom hogy a "20-40" fos cegek garazscegnek szamitanak es akkor erteni fogod az ervelest, nem vall nagy arcra, pusztan probaltam megvilagitani egy nezopontot. Mondhatni definialtam a fogalmat, hogy ertsd mire gondolok. En sosem emlitettem mekkora fej lennek, ezt (a sok hozzaszolas es roflmao alapjan) ti kepzeltetek oda. Mindenki magabol indul ki.

Nem tunt fel hogy a sajat hulyesegem magyaraznam, ez ismet egy olyan dolog amit te kepzelsz oda. A hirt elolvastam koszi szepen, en nem latok benne szenteltvizet emlitve. Egy nezopontot latok, amit tapasztalat alapjan meg tudok erteni. Mas ugy latszik nem, sot, sok torekves sem volt eziranyba, ugyhogy jo puffogast a tovabbiakban.

:o
a létszámtól függene a garázscég minősítés?
ne haragudj, de ez baromság...
amúgy taktikának nem utolsó ez a "kifogytamazérvekbőljöhetahátatfordítósdurci" csak némiképp sekélyes...
---
Why use Windows, if you have open doors… to Linux

Csupan megsporolom a goto 10-et. A felvetett kerdesekre es ervekre a hozzaszolasaimban megtallahato a valasz. Minek ismeteljem ? Ugysem halljatok meg :)

igen csak ne haragudj de te sem hallasz meg semmit. egy vita észérvek ütköztetése, melynek során általában mindkét fél véleménye alakul, már ha kellőképpen normálisan állnak a témához és egymáshoz, és a végén megszületik a konklúzió ami már mindegyik résztvevő számára elfogadható (az, hogy az helytálló, már vitatható :) ). a te véleményed nem alakult, pedig érveket felsorakoztatott a másik oldal is, azokra a dolgokra reagálva (cáfolva/megerősítve) amit felsoroltál. ha ezek ellenkeztek vagy ellentmondtak a te állításaidnak, akkor további magyarázat nélkül megismételted őket. ha nem akarsz meggyőzni másokat az igazadról, vagy elfogadhatóan megmagyarázni, megindokolni állításaidat (úgy, hogy megértsék és el is fogadják azokat), akkor mi a ráknak kezdtél bele? nem vagyunk a magyar parlamentben :D

---
Why use Windows, if you have open doors… to Linux

Nem haragszom :) Igen, jol latod, valoban nem alakult. Ennek ket oka van: az egyik, hogy nem azert postoltam hogy barki barkit is meggyozzon (oda-vissza). A postolasom oka az volt, hogy kicsit mas szempontbol is mondjak velemenyt a temarol, mint a tobbseg "ki ez az mscs, mbas ficko ez se latott soha kodot" velemenye. En is, mint itt sokan, lattam mar kodot, nagy projektet, kis projektet es megis hasonlo a velemenyem mint az ove. (Habar azt hozzateszem hogy az enyem mogott nem kell uzletit keresni, mert az nincsen.)

A masik hogy lenyegeben elbeszelunk egymas mellett. Szinte az osszes reakcio zsigerbol jott (keves udito kiveteltol eltekintve); a valasz ezekre valojaban benne van a mar leirtakban, ez megsem tetszik senkinek. Ismetelni magamat pedig (mint mar emlitettem ;) nem szeretem. Akit erdekel, az el tud rajta gondolkozni, aki meg mindenkeppen a sajat igazat akarja leirva latni, az meg azt harsogja. Nekem nem faj, en pusztan leirtam a magam velemenyet ado hatteret, hatha mast is erdekel. Nem jott be :)

Hmm értem. Így ez valóban elfogadható.
---
Why use Windows, if you have open doors… to Linux

Értem.

"A hirt elolvastam koszi szepen" =/= A hírt megértettem, fel is fogtam.

Többen leírtuk (vagy utaltunk rá) hogy nagy multi cégnél dolgozunk, talán éppen ezért
pont hogy belelátunk egy ilyen cég működésébe...

Láttam nagy cégnél, nagy volumenű projektet. És így is csak azt tudom mondani, hogy baromságokat írsz. Szerintem összekevered a hup-ot a pcforum-mal.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Kosz a tartalmas hozzaszolast.

Lássad fejjebb

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."


"A minőség nem függ össze a licenszeléssel."
Ha logikailag nem is vezetheto le, megis megfigyelheto a jelenseg.

Nem tudom elhinni hogy ez a tevhit meg mindig tartja magat...

Kerlek tamaszd ala szamokkal, cikkekkel (es nem a hany hibat ismerunk el a heten jellegu elemzesekre vagyok kivancsi).

Ez egyszeruen nem igaz, butasag ilyet gondolni.

Termeszetesen semmi ertelme sincs cikkel vagy statisztikaval dobalozni; a megfigyeles tapasztalatbol szarmazik:

- Egy OSE pl nagysagrenddel stabilabb, bugmentesebb, jobban tesztelt es dokumentaltabb mint a linux kernel. Lehet huhogni, de nem erdemes.
- Ablakozo kornyezetek linuxra, maga a linux, a disztribuciok szinten eleg gyengen allnak minoseg teren. Az egy dolog hany bugot javitanak ki es mennyi a commit vagy a fejlodes, de felhasznalokent (es fejlesztokent is) az erzet mast mutat. Egyebkent nem vagyok szerelmes egyik OS es kornyezetebe sem, pusztan szeretem a produktiv munkat.

Termeszetesen olyat is siman tudok mondani, aminel pont forditott a helyzet. Az (en) tapasztalataim alapjan azonban a "Ha logikailag nem is vezetheto le, megis megfigyelheto a jelenseg" mondat helytallo.

Ez nem butasag; mas iparagakban mozgunk, masok a kovetelmenyek, lehet sorolni millio okot, hogy miert kulonbozhet a tapasztalat ket embernel. Nem abszolut igazsagot mondtam, barmennyire is ezt probaljak a szamba adni, velemenyt mondtam. Teljesen vilagos (szamomra legalabbis) hogy egyes teruleteken az egyik erosebb, masokon a masik. Amit en eddig lattam (mar latom is az erre ugro emberkeket...), az a zart forraskod es az uzleti alapon valo fejlesztest hozza ki elonyosebbnek.

Az OSE-hoz milyen fejlesztői környezet van?

Lehet hogy igazad van, nekem pont ellentetes tapasztalataim vannak.

"Eleg arra gondolni, milyen munka lehet mondjuk egy *nix kernel behegesztese vagy alkalmazasa egy celhardveres platformon">mondjuk, "egy célhardveres platformon" célszoftvert fognak használni, akár FLOSS-t is, ha van. nyilván megkeresek, nem pedig a Distrowatch.com-ról töltik le az egér pozíciójához éppen legközelebb eső diszto linkjéről a telepítőlemezt.

_____________
烏邦土 - 乾屎橛

Honnan tudod egy zárt forrású programról, h mennyi nyílt forrású rész van benne? pl. BSD licencű. és akkor innentől mindent helyettesíts be arányosan a zárt forráshoz is.

"Eloszor is nem art azt fixalni, hogy nagy cegekrol es nagy volumenu projektekrol van szo, nem pedig apro cegek adhoc modon osszerakott projektjeirol."

Az olyanok hogy Novell/Redhat modanak valamit? Nem adhoc garázscégekről van szó mint ahogy beállítani próbálod.

"A masik amit nem szabad elfelejteni, hogy nem bebetonozott, mar 10 eve letezo opensource termekekrol van szo, hanem dinamikusan valtozo projektekrol (pl linux kernel)"

Khmm. Megsúgom: A Linux kernel 10 évnél idősebb egy kicsit. Persze dinamikusan _fejlődik_ (szerintem nem is rossz irányba). Ha itt a stabilitásra próbáltál célozni => Lásd előbb.

"milyen munka lehet mondjuk egy *nix kernel behegesztese vagy alkalmazasa egy celhardveres platformon (nem pedig egy mezei PC-n amin Pistike el tudja inditani) es annak rendes kitesztelese. Ha az opensource termek raadasul nem is arra a kornyezetre van tervezve/optimalizalva (pl elosztott OS)"

A Linuxot (magát a kernelt mert hát arról beszéltél) használják elosztott rendszerekben is. Vannak opensource programok amit szintén használnak elosztott rendszerekben. Vannak Linux kernelre épülő komoly fizetős programok is. Ne keverjük a programot/kernelt.

"- Mire valamibol termek lesz, sokeves fejlesztesen esik at. Mire a vegere ernek, nem hatrany, ha a projekt meg letezik. Az sem hatrany, ha a projekt menet kozben es a vegen is olyan iranyban jarja be az elet rogos utjat, ami a cegnek is megfelelo. Pl kritikus patchek, kritikus fejlesztesi iranyok belekerulnek. Ezt, mivel opensource, nem lehet kontrollalni, hacsak nem vagy benne az iranyitasban igen erosen. Ez a megoldas pedig mar csak nyug, mert akkor jarsz a legjobban, ha te iranyitod ugy, ahogy akarod - azaz nem opensource alapon csinalod."

Attól még hogy opensource, lehet ám patronálni. Plusz, képzeld a Linux kernel jelentős részét ezért fizetett programozók irták. Azért ne mond nekem hogy egyszerűbb nulláról megírni egy komoly programot, mint felvenni valakit aki patcheket gyárt/küld egy komoly programhoz. (Persze akkor úgy kell kiírni hogy pl. Mysql programfejlesztőt felveszünk pl. a Mysql portálra.)

"- Hasonloan eleg problemas a dokumentacio minosege (sot, egyaltalan a meglete)."

Bwahahahaaa. Láttál már MS. Developer Toolst? Ez nem licencfüggő.

"- Hasonloan problemas lehet a cucc minosege (ertsd: mennyire teszteltek ki)."

V.ö. (Nulláról kifejleszteni + kitesztelni)/(Megvenni + kitesztelni)/kitesztelni

"Osszegezve: a nyereseg az ilyen projekteknel maximum abbol adodhat hogy a meglevo kodbazist nem kell megirni, a jovore nezve valoban nagy rizikot jelent ha opensourcebol dolgoznak."

A mondat második fele számomra nem következik semmiből amit eddig irtál, sőt mintha ellentmondásba lenne az első felével.

"Peldanak okaert megvenni az OSE oprendszert a Linux kernel helyett..."

Ezt nem értem. Valószínűleg már megint a kernel/oprendszert kevered. Mi lehet az OSE? Gyanítom hogy ez a Operating System Embedded. De azért attól hogy megvették még alkalmazásokat kell(het) írni rá.

ROTFLWMAOPIMP

1. Szerinted egy 500 milliós MR az egy adhoc módon összerakott projekt?
Szerinted a Windows egy bebetonozott termék? Windows XP - Vista - Windows 7. Sok minden eszembe jut, de nem a beton.

Hagy meséljek el egy rövid kis sztorit. Az amerikai főnökömnél megpendítettem a nyílt forrást. Azzal hessegetett el, hogy ő 10 év múlva is ugyanúgy akarja majd olvasni az adatait, mint most. Na elő is került egy 1996-os ppt fájl. Szerinted ki tudta nyitni az Office97? Nem. Legújabb MSOffice kinyitotta? Szállt, mint a győzelmi zászló. Most akkor lehet tippelni, hogy mivel lehetett kinyitni. Persze sok minden nem úgy jelent meg, mint ahogy az eredetiben, de ez akkor is ugyanúgy lett volna, ha valamelyik MS office meg tudta volna nyitni...

2. Zárt forrású Unix hegesztése beágyazott platformra ugyanolyan izzadtságos, mint zárt forrású windowst. Embedded laborban ilyenkor a Linux From Scratch-t tolják. Biztos nem szeretnének gyorsabban, kellemesebben végezni egy Windows-zal.
Mission critical? Egy tőzsdei rendszer az biztos csak egy playground...

3. Szerintem a Microsoft fejlesztési irányát egy mezei cég befolyásolhatja? Milyen garanciát ad a Microsoft egy windows software létére?

4. Sajnos nem értek egyet. Vállalaton belül fejlesztett mammut szoftverek dokumentációja rendszerint sokkal katasztrófálisabb, mint egy nyílt projekté. Maximum a kollégáid tudják neked elregélni.

5. Mindannyian publikus bétatesztelők vagyunk a PC világban. Kivéve a Macintosh-t.

6. Támogatás. Na ne röhögtess. Milyen támogatást kapsz az Embedded Windows-odhoz? Milyen támogatást kapsz a Windows-odhoz, ha elvesznek az adataid? Kihez mehetsz panaszra? Ha van is support-od, akkor vajon mit fog mondani neked s support-os? Öregem...

7. A zárt cuccok kódbázisa talán ismert? Tudod mennyit fogod turkászni? Arról nem derülhet ki, hogy alkalmatlan?

8. Számtalan ellenpélda van: sok kereskedelmi célprogramot használnak nyílt forrású oprendszeren.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Te honnan a csudabol szedted a windowst ?

Az opensource nem azt jelenti, hogy egy sourceForge-rol letoltott megbizhatatlan, kontroll nelkul folyamatosan valtozo blob-ot teszek a termekbe. Ha egy nagy ceg vesz valami szoftvert, ami bekerul a termekbe, annak ugyanolyan szigoru minosegellenorzesi eljarason kell atesnie, fuggetlenul attol, hogy opensource vagy nem, zsak penzbe kerul vagy nem. Kell rendes doksi es kell support (kisebb dolgokat hazon belul is lehet supportani).

Csak zarojelben:
- egy *nix kernelt egy egzotikus architekturara felheggeszteni egy kulon ceg kulon termeke. Aki vegfelhasznalonak fejleszt es ilyennel tolti az idejet, az csak magat szurja tokon. Akinek meg tenyleg ilyen kell, az fordit ra feljesztesi idot/eroforrast.
- ha valamire nem valo *nix, akkor nem kell rarakni. :)

Az opensource licensz nem korlatozza, hogy sajat branched legyen egy szoftverbol, ami megbizhato, es kielegiti az igenyeidet. Ahol meg 1000+ szoftverfejleszto van, ezt nem is nagy szam megoldni. Konkretan a GE-nek van sajat RHEL linux alapu disztribucioja, ami termekek igenyeihez van igazitva.

Sztem sokkal nagyobb szivas a vendor-lockin. Amikor a szoftverhez mar nem kapni hw-t, amin fut, vagy egy system lib tele van thread safety problemakkal, de eredeti fejleszto mar nem foglalkozik vele - meg nagyobb osszegekert sem. Na, ebbol van csunya ganyolas.

Van rengeteg olyan opensource cucc, ami mar bizonyitott (adatbazis-, verziokezelok, gui toolkitek, debug eszkozok, vizualizacios konyvtarak, script nyelvek), ezekbol semmi ertelme venni egy proprietary zart valtozatot, ha nincs elonye az opensource-szal szemben.

Osszgezve: opensource dolog hosszu tavon nem riziko, hanem biztonsag, hogy senki nem tudja kihuzni a labad alol a talajt.
En nem allitom, hogy mindenhol kizarolag opensource eszkozoket kell hasznalni, mert ez nyilvan hulyeseg, de teljesen elzarkozni a dologtol is az. Az illeto megnyilvanulasa inkabb az ismeretlentol valo felelmet tukrozi, mint valos tapasztalatot. (esetleg vett egy ocska linuxos home routert, es lefagy neki :)

Istenem hagyjátok már! Ő elhiszi sőt vallja amit mond és valószínűleg imádkozik is, hogy a gonosz openszórsz el ne pusztítsa a világot. :)
Másrészt ha elolvasod az összes hozzászólást, rájössz hogy nem lehet meggyőzni.

Az openszórsz rossz, érteeeem? :)

+1

Koszonom :)

-Kevés a cégen belül felhalmozott tudás.
-Hoznak a céghez egy addig sohasem látott alkalmazást, adnak mellé x főre y napnyi oktatást, illetve a rendszerrel járó dokumentációt, illetve ha a megrendelő kéri, z ideig támogatást. A cégen belül az induló nulla tudás az oktatás, a gyakorlat, a mindennapi használat/üzemeltetés során szépen eléri a szükséges és elégséges szintet. Ha valami nem megy, akkor a szállító (vagy más, aki hajlandó aza dott rendszerhez támogatást adni) segít.

-"Mire valamiből termék lesz... sok év..." Igen, sok év telik el, mire egy fejlesztés piacéretté válik -- a szükséges alapokat úgy kell megválasztani, hogy azok hosszabb távon rendelkezésre álljanak. Ezért célszerű olyan eszközökhöz nyúlni, aminek az eltünésére, a karbantartás, támogatottság, támogathatóság, továbbfejlesztés, illetve továbbfejleszthetőség megszünésére minimális az esély. Itt, az előző ponthoz képest (ahol gyakorlatilag irreleváns, hogy az adott megoldás forráskódját ki és hogyan láthatja, ki férhet hozzá) az opensource/szabad szoftveres dolgoknak van egy orrhossznyi (vagy nagyobb...) előnye: lehet egy opensource fejlesztésből is abandonware, viszont senki sem akadályozza meg a használóját abban, hogy vagy saját maga, vagy valaki az ő megbízásából folytassa annak a fejlesztését, támogassa, és kiemelje az abandonware állapotból. Ha ez egy kereskedelmi szoftverrel történik meg (azaz a gyártó/fejlesztő dobja el a szoftvert, vagy azért, mert már nem üzlet neki, vagy azért, mert megszűnik a cég (gyakorlatilag irreleváns, hogy miért)), akkor az adott eszköz további használata fog igen komoly kockázatot jelenteni, hiszen bármilyen hiba, sérülékenység, funkcionális hiányosság derül ki, nem lesz, aki ezt javítsa.

Dokumentáció... Válasszuk ketté a dolgot. A felhasználói dokumentáció általában egyik esetben sem jeleskedik azzal, hogy megütné a megfelelő szinvonalat, bár az is igaz, hogy a kereskedelmi termékek mellé legalább valami papírpazarlási célú könyvet, vagy doksicédét csomagolnak (jó esetben az épp aktuális verzióhoz valót). Ha fejlesztőként nézem a dolgot, akkor meg eszembe jut egy régi igazság: a jól és szépen megírt és kommentezett forráskód a legjobb dokumentáció.

Tesztelés minősége... Való igaz, a fre/opensource szoftverek jelentős részénél nincs kifejezett QA team, de ez csak számosságban jelent sokat, a nagyobbacska/komolyabb projekteknél ugyanolyan, ha nem jobb a minőségbiztosítás, mint a ker. termékek esetén. Jut eszembe, a ker. termékek esetében nagyon gyakori, hogy a marketing osztály mondja meg, mikor van release -- f/oss esetben meg elsődlegesen szakmai alapon dől el ugyanez. (Szerintem a marketinges által kierőszakolt release-ben nagyobb a kockázat, de mindegy.)

Ha az, hogy valami alkalmatlan az adott projekt céljaira, az akkor derül ki, amikor nyakig vannak a... a projektben, akkor másban is nyakig vannak -- a tervezés hibáiban. Kereskedelmi termék használhatatlansága, adott célra való alkalmatlansága esetén így jártak, dobozt felhajítják a polcra a többi lom mellé, és keresnek egy másik stuffot -- a használhatatlanra költött pénzt meg leírják veszteségként. (amivel ugyanúgy fogalkozni (betanulás, tesztelés, hogy jó-e, satöbbi) kellett, mintha opensource/ingyenes alternatívából indultak volna ki) Ha bukta van az eszközzel, a termék bekerülési költsége, mint veszteség jelentkezik az egyik oldalon, a ráfordítás, ami a keresése/megismerése/kipróbálására ment, az meg mindkettőn -- és erről nem lehet kategórikusan kijelenteni, hogy zárt/fizetős vagy nyílt/ingyenes esetben több vagy kevesebb.

Anno volt erről egy előadásom, ott sokkal részletesebben belementem ezekbe a kérdésekbe, ha gondolod megpróbálom előtúrni valahonnan az anyagot.

"Sok iparban nem szabad a bandwagenre ugralni, mert erosen pofara lehet esni."
Nekem erről inkább a Solaris/UNIX/*IX -> NT4 migrációk jutnak eszembe. Valszeg túl öreg vagyok.

A témához: ha telekom- vagy hálózati berendezések kapcsán mond valaki ilyet (veszélyes az opensource), akkor már bocs, de az illető hülye. A platformok elsöprő tobbsége jelenleg opensource alapokon nyugszik. 3-4 évvel ezelőttig még virágoztak a különféle bezárt BSD fork-ok de ezek közül sokat migráltak Linux-ra mert elfogyott körülöttük a levegő.

Ja, csak szemezgetnék:
"Mivel opensource, felhalmozott tudas a cegben keves van rola, ergo nagy az indulo befektetes." In the USA/Silicon Valley az egyetemeken a BSD kernelt tanítják (TCP-IP illustrated, itthon sikerült már túllépni a Tannenbaum-on?). Normális helyről szabadult friss diplomások a BSD vagy Linux kernelt tanulták. Minden ami ennek ellentmond lokális probléma.

"Eleg arra gondolni, milyen munka lehet mondjuk egy *nix kernel behegesztese vagy alkalmazasa egy celhardveres platformon (nem pedig egy mezei PC-n amin Pistike el tudja inditani) es annak rendes kitesztelese. Ha az opensource termek raadasul nem is arra a kornyezetre van tervezve/optimalizalva (pl elosztott OS), akkor a hegesztes folyamata meglehetosen el tud durvulni. Plusz, mivel nem oda szantak, a teljesitmenyevel szinte garantaltan problemak lesznek, ami - mint az uriember emlitette - mission critical termekekhez elengedhetetlen."

Ez az opensource mellett szól, már bocs. Open esetben van esélye a cégnek magának elvégezni a célhardveres optimalizációt/tesztelést de meg is veheti valakitől. A zárt esetben találni kell egy megfelelő célhardvert _és_ ráoptimalizált megoldást, sokkal kisebb a mozgástér. Jópár éve megszívtunk egy ilyet (zárt OS + nem támogatott új HW) és nem kiscégről volt szó.

"- Meglehetosen nehez egy hatalmas es ismeretlen kodbazisban turkaszas idejenek becslese, azaz projekt tervezes szempontbol eleg nagy kockazat az, ha a projekt felenel kiderul hogy a behalaszott opensource cucc alapvetoen hasznalhatatlan a feladatra architekturalis okokbol, csak ezt elfelejtettek megemliteni (vagy egyaltalan atgondolni) az adott projektben."

Talalkoztál már betonfallal? Tudod, amikor a marketingesek rádsóztak valamit, amiről kiderül, hogy a céljaidnak csak 99%-ban nem felel meg. Ilyenkor az eladó cég méretével arányosan csökken az esélyed, hogy foglalkoznak érdemben a kínoddal. Opensource megoldásokat kis cégek is tudnak érdemben testre szabni, mert nem 0-ról kell indulniuk. Illetve végső esetben magad is megpróbálhatod hozzáadni a hiányzó 1%-ot. Na?

Még valami, a kódolás nem egzakt tudomány, olyan nincs, hogy valamit előre megtervezel és az 100%-ban bejön. Ennél minden software bonyolultabb, nincsenek tűrésmezők, ez nem egy mechanikus szerkezet.

Olyan opensource platformokon melyek maguk is kereskedelmi termekbol lettek opensourceok, majd igencsak eros rancfelvarrason estek at, hogy kepesek legyenek kiszolgani az igenyeket. Ezek mellett tovabba a kereskedelmi, zart/felig zart SWek is ott vannak, nem dobtak oket kukaba. Az hogy a BSDk kezdenek kihalni beloluk (en is ismerek ilyet, valoban), az miert szol az opensource mellett ?

Linuxra sokan valtanak, nyilvan, mert koltseghatekony es van jovoje. Viszont az esetek nagy reszeben csak a legbelso magot veszik at, ami kore maguk epitik fel az egesz middlewaret, az alkalmazasokrol termeszetesen mar nem is beszelve. Szoval azert az opensource van mindenhol kep egy csoppet arnyaltabb, mint sugallod. Az a opensource kod ami ott mozog, lehet talan 10% vagy annyi sem. Persze cege es ipara valogatja, en arrol beszelek, amit ismerek.

"Normális helyről szabadult friss diplomások a BSD vagy Linux kernelt tanulták."
Nivosabb helyen meg solarist, vagy barmi mast. Egyebkent szuper. Legalabb lesz sok kismajom aki osszepotyogi amit kell :)

"Open esetben van esélye a cégnek magának elvégezni a célhardveres optimalizációt/tesztelést de meg is veheti valakitől. A zárt esetben találni kell egy megfelelő célhardvert _és_ ráoptimalizált megoldást, sokkal kisebb a mozgástér"
Igen, ez fogos. Tulajdonkeppen igazat is adnek, ha nem sejtenem hogy mas rendszerekre gondolunk. A kep egyebkent is arnyaltabb picit, mert a kereskedelmi termekek eleve arra keszulnek hogy extrem modon lehessen oket konfiguralni, mig az opensource-rol ez nem igazan mondhato el. Mas a celkozonseg; ez talan jobban kifejezi azt, amire gondolok. Az, hogy a ceg megoldhatja maganak, az valoban impressziv elso hallasra, csak nem biztos hogy koltseghatekony.

"Jópár éve megszívtunk egy ilyet (zárt OS + nem támogatott új HW) és nem kiscégről volt szó."
Ezt barki beszivhatja, erre mondtam: peldat mindenre lehet talalni. De atlagban nezve kisebb rizikod van beszivni ezt (plusz atlagban nezve sokkal gordulekenyebben uszod meg ha beut), mint egy opensource projektnel.

"Opensource megoldásokat kis cégek is tudnak érdemben testre szabni, mert nem 0-ról kell indulniuk. Illetve végső esetben magad is megpróbálhatod hozzáadni a hiányzó 1%-ot. Na?"
Kiscegeket felejtsuk mar el, az elso postomban ott volt a kitetel hogy nem roluk van szo. (Egyebkent igazad van, nagyon jo versenyt tud generalni a linuxra epulo feltorekvo piac, ezzel nincs is gond.)
Nagycegeknel eleve nem jon olyan megoldas szoba, ahol fennall a rizikoja, hogy csapdaba esnek a megoldassal. Ezt a rizikot, az opensource rizikojahoz hasonloan messze elkerulik, erre megvannak modszerek.

"Még valami, a kódolás nem egzakt tudomány, olyan nincs, hogy valamit előre megtervezel és az 100%-ban bejön"
Kosz, ezzel tisztaban vagyok :)

"Nagycegeknel eleve nem jon olyan megoldas szoba, ahol fennall a rizikoja, hogy csapdaba esnek a megoldassal. Ezt a rizikot, az opensource rizikojahoz hasonloan messze elkerulik, erre megvannak modszerek."

A vendor lock-in elkerülésére mi a legjobb, bevált módszer? Ha célszoftver, akkor az aktuális verzió forrása minimum letétbe helyezve valahol, ha meg nem az, akkor a forráskód elérhetősége. Egy naaagy cég igen komoly projektjében pl. az első megoldást (forráskódokat a szállító teljes egészében, megfelelő ellenörzési, biztonsági és egyéb folyamatok és szabályozás szerint köteles volt letétbe helyezni, verzióváltáskor frissítve, etc.) alkalmazásával védték magukat, de ugyanott volt olyan is, ahol explicit kikötötték, hogy a forráskódot a szállító a megrendelőnek köteles átadni.

Ami elvitathalatlan előnye a nyílt forráskódnak (pontosabban annak, ha a megrendelő hozzáférhet a teljes forráskódhoz) az az, hogy lehetősége van a hódot auditálni, mielőtt használatba veszi az adott alkalmazást. Ez a zárt forráskód esetén gyakorlatilag lehetetlen.

go to sleep :)

Ezt jól megmondtam...: "lehetősége van a hódot auditálni" :-))

Tudatlan ember oktondisága. De a legnagyobb baromság foglalkozni vele.

"A GE európai IT vezetője szerintem óriási rizikót jelent a vállalati szervezetekre nézve..."

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

Megnyugtató, hogy a világ legnagyobb műszaki profilú vállalatának műszaki végzettségű informatikai vezetője ilyen jól képes megítélni a nyílt forrás jelentette esetleges kockázatokat.
Sajnos a vállalata még nem ismerte fel amit ő igen és a netcraft szerint a www.ge.com kiszolgálását többek között igen veszélyes Apache webszerverek végzik.

de solarison (ha jól néztem) és lehet a sun odaadta cédére kiírva a forráskódot, amit ő bezárt a páncélba. így az apache zárt kód lett, tehát biztonságos.

Péter György óriási rizikót jelent a vállalati szervezetekre nézve, ha így általánosságban tesz kijelentéseket. A fő veszélye a dolognak az, hogy a végén még valaki elhiszi.
A zárt kódú program legalább olyan nagy rizikót jelent a vállalati szervezetekre nézve, sőt!
Egy szoftver igazából akkor jelent rizikót, legyen az zárt vagy nyílt forrású, ha hozzá nem értők üzemeltetik és ezzel kárt okoznak.
--
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

Ahogy végiggondolom tényleg van előnye a zárt kódnak. Ha valami beszarik van kire mutogatni. :P Míg fordított esetben mindig az admin a hibás. Linuxot használni tehát tényleg bátorság. :D

Es, ha nyilt kodhoz veszel supportot ? Akkor kapsz egy bunbakot:)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nyugodtan nevezzetek elfogultnak, vállalom.
De én olyat még nem láttam, hogy csökkent a RedHat forgalma. Inkább hiszek nekik. Egy fecske nem csinál nyarat.

>>: sys-admin.hu :<<

+1

Azért a cikk kapcsán nem állnék neki áttanulni a Unix vonalról... :-)
Ja és nyílt forrással kapcsolatban még nem találkoztam perverz licenccel, míg zártnál alig van nem perverz. Pedig mindig törekszünk a megfelelésre, de amikor az adott gyártó három licencelős embere négy megoldással áll elő ugyanarra (és a többiek megoldását egyik sem tartja jónak...), majd végül előállnak egy revenue sharing licence modellel, azaz most vegyük meg processzor alapon, év végén meg megmondják hogy ennek a hányszorosát fizessük mert már userek is lesznek. Kúl. Írjál rá business case-t.
Amúgy meg a Sun rohadjon meg, mert kiplakátolta az OS forrását (na jó, egy részét). Eddig hittem bennük, de most szemléletkiigazításban részesültem :-)
És most nekiállok hamut szórni a fejemre, és összetépem a Solarisra és RHEL-re belőtt terveimet a garázscéges projektemben (aminek a mérete tuti meghatározó lesz a magyar piacon az elkövetkező 3-5 évben).

@mchalls: végiggondoltam milyen OS-t telepítsek. Taníts mester, mert azt mondod "ki beszélt itt windowsról?", de nem ismerek olyan zárt nem windowst ami ne használt volna fel nyílt vagy nyílttá vált forrást.

Szerintem telepits olyat, amilyet akarsz.

Csak mellekesen jegyeznem meg, hogy a paypal creditcard mogott is a GE all. Na annal otvar szarabb (probaltam nagyon finoman fogalmazni) online feluletet meg eletemben nem lattam, mar amikor egyaltalan mukodik. En hulye eddig azt hittem, hogy valogatott dilettansok dolgoznak ott, de most megvilagosodtam: mindennek az a szemet nyilt java az oka! Oh wait...

Mármint a GE Money bank, ami az adott konglomerátum pénzügyi cége (Hint: Budapest bank...)

Biztosan félreértelek, de az EBay tulajdonában lévő PayPal-nak mi köze a GE-hez?

Gondolom az, hogy a PayPal nem kártyakibocsátó, tehát kell mögé valaki, aki PayPal co-branded kártyákat bocsát ki.

Ja, hogy átsikolottam a credit card kifejezés fölött... Bocs!