- A hozzászóláshoz be kell jelentkezni
- 2731 megtekintés
Hozzászólások
Hahó!
Örülök, hogy legalább valaki hozzászólt. Ez egy rendkívül érdekes téma. Örömmel osztom meg a gondolataimat másokkal és szívesen olvasom mások véleményét.
Azt gondolom, hogy a nyílt forráskódú fejlesztés nem valami varázsfegyver. Éppenhogy nem az. Én például nem emiatt és nem holmi Microsoft vagy Windows gyűlölet miatt használok Linuxot vagy BSD-t, hanem azért, mert bizonyos feladatokra technikailag praktikusabb (sőt, a kedvencem az: UHU, a Madrake, a Gentoo és a FreeBSD, de éppen ugyanúgy szeretem a Windowst és a többit is - bárki bármit mond e téren).
A korábbi hozzászólásommal mindössze azt szerettem volna hangsúlyozni, hogy ha az általunk fejlesztett termék NYÍLT FORRÁSKÓDRA ALAPULNA (egyébként nem az), AKKOR SE lennénk előbbre egy open source fejlesztésben jártas emberrel. A másik gondom az, hogy a "fejlesztő" szó nagyon általános. Sokan elsősorban a programozóra gondolnak, holott ez nem igaz. Nagyon sok más, akár fontosabb szakember is kell egy jó szoftverhez. A baj az, hogy manapság mindenki a programozókat isteníti (magam is az voltam/vagyok ezért bátran kimondom), holott a fejlesztés legfontosabb tényezője nem a programozó, hanem a tervező-szervező szakember.
Ugyanis, mint írtam elsősorban NEM a programozói gyakorlat a lényeg, amikor alkalmazok egy új programozót. Azért nem, mert azokat a techológiákat, eszközöket, belső szabályokat (meg mindent, amit korábban írtam) sehol máshol nem gyakorolhatta volna be, csak nálunk. Ezen nem segít a nyílt forráskódú fejlesztés.
Talán akkor lehete másképp, ha léteznének olyan open source szabványok, amelyek kifejezetten a fejlesztés módszertanára, a csapat, folyamat és termékmodellezésre és a kockázatmenedzsmentre vonatkoznának, továbbá ezt minden cég, vagy fejlesztő be is tartaná. Egyelőre azonban ilyen speciális open source-ra vonatkozó szabványokról nem tudok. Vannak helyette/mellette azonban más szabványok (UML, RUP, SSADM, MSF, stb), de önmagában még ez is kevés - hiába tudná valaki.
Bizonyos termékeknél, szoftvereknél valóban előny lehet az, amiről itt szó volt, de azon a fejlesztési területen, ahol én dolgozom (ügyviteli, kereskedelmi és speciális egyedi fejlesztésű szoftverrendszerek), ott hangsúlyosan nem. A világon jelenleg ezek a domináns szoftverek (több, összetettebb, elterjedtebb) és nem pedig az open source fejlesztésűek.
Megjegyzés: Jelenleg szó nincs arról, hogy a szoftvert kinyissuk, meg a benne lévő tudást "csak úgy" átadjuk mert ez járhatatlan út (kivéve a szerződéses partnereket). Az igazi érték mindig a tudás, ami a fejekben van meg az üzleti logika, ami a forráskódban és adatmodellben rejtőzik. De ez már egy másik történet lenne...
Köszönöm a figyelmet,
Üdv.
KJ.
- A hozzászóláshoz be kell jelentkezni
> Örülök, hogy legalább valaki hozzászólt. Ez egy rendkívül érdekes téma. Örömmel osztom meg a
> gondolataimat másokkal és szívesen olvasom mások véleményét.
Az ember szavai a szélbe dobott virágporszemek. Nem biztos, hogy bármi kin? bel?lük. És ez nem a virágpor hibája, se nem a szél-é.:-))
Szívesen válaszoltam volna már, de kint vagyok a világ végén, és meglehet?sen offline vagyok.
> Azt gondolom, hogy a nyílt forráskódú fejlesztés nem valami varázsfegyver. Éppenhogy nem az. Én
Ebben nem értünk egyet. Én úgy gondolom, hogy a szoftverek opensource-k lesznek _mindenképpen_.
A kérdés az az, hogy melyik mikor. Írtam róla egy szösszenetet, ha érdekel megtalálod
itt (a retek*.html sorban ertelmes, ha az elozoket nem olvastad)
> A korábbi hozzászólásommal mindössze azt szerettem volna hangsúlyozni, hogy ha az általunk
> fejlesztett termék NYÍLT FORRÁSKÓDRA ALAPULNA (egyébként nem az), AKKOR SE lennénk el?bbre egy
open source fejlesztésben jártas emberrel. A másik gondom az, hogy a "fejleszt?" szó nagyon
Ha a terméked nyílt forráskódra alapulna, akkor tudnál felvenni olyan ember aki a _te_ nyílt forráskodú termékedet ismeri. Pont ott tartana, mint a jelenleg felvett embereid 5-6 hónap után. S?t a gyereknek lennének referenciái. Meg tudnál nézni kódokat, amiket a te projekteddel készített. Egy ilyenb?l _látszik_ hogy a jelölt alkalmas, vagy nem.
De szerintem az "ALAPULNA" szót te abban az értelemben érted, hogy a progi Linux-on fut. _NEM_ maga a _PROGI_-nak kell nyílt forrásúnak lennie, hogy képes legyél kihasználni az el?nyöket. Persze ha nem akarod, akkor nem muszáj.
Te életed, te céged, azt csinálsz vele amit akarsz. Amit viszont nem árt megcsinálni, az a programoddal/megoldásaiddal járó kötelez? _járulékos_ költségek minimálisra csökkentése. Az nem a te pénzed, hanem az M$-é, vagy az Oracle-é. Ha a progid/megoldásod fut linux/mysql-en, akkor több pénz marad neked. A megrendel? csomagot néz, és arról van elképzelése, hogy maximálisan mennyit akar rákölteni. Nagyon nem mind1, hogy mennyi marad ebb?l a pénzb?l.
> általános. Sokan els?sorban a programozóra gondolnak, holott ez nem igaz. Nagyon sok más, akár
> fontosabb szakember is kell egy jó szoftverhez. A baj az, hogy manapság mindenki a programozókat
Ha _üzleti_ és zárt szoftverre gondolsz mond inkább azt. Megnézném, hogy az MPlayer team-ben, vagy a Linux kernel több ezer fejleszt?je között, milyen _fontosabb_ szakemberek vannak a programozóknál.
Egy zárt fejlesztés rengeteg köztes embert tartalmaz a fejleszt? (programozó), es a felhasználó
között. Az opensource fejlesztés _senkit_. Azok az opensource fejlesztések futnak _jelenleg_ a
legjobban, ahol a fejleszt?k is felhasználók. így tuti nincs kommunikációs probléma:-)) S?t rengeteg olyan probléma se létezik, amik nálad napi szinten gondokat okozhatnak.
Tippelnem, hogy a te _fontosabb szakembereid_ kozul azok a legjobbak, azok akik programozók voltak. tehát a fontosabb szakemberek nagy részére azért van szükség, hogy megel?zzék azokat a problémákat, amelyek nyilt fejlesztés, és az ? távolmaradásuk esetén fel se merülnek.
> isteníti (magam is az voltam/vagyok ezért bátran kimondom), holott a fejlesztés legfontosabb
> tényez?je nem a programozó, hanem a tervez?-szervez? szakember.
A zárt fejlesztéseknél jelent?sek a kommunikációs hiányosságokból ered? gondok. Az információ nem
jut el ahhoz akinek szüksége lenne rá, ezért rendkívüli jelent?séggel bírnak azok akiknek az
információ szállítás, vagy az információs utak kialakítása, vagy a kommunikációs problémák
megel?zése a feladatuk. Erre szerintem alkalmasabb egy mailszerver, és egy levlista:-)))
Valamint az, hogy a résztvev?knek ne legyen lehet?ségük máshogy információt cserélni. Mindenki
tudjon mindent. Mindenki _maga_ döntse el, hogy milyen információkra van szüksége. Fogadjunk,
hogy te jobban tudod milyen információkra van szükséged, mint én gondolom, hogy neked mire van
szükséged!
> Ugyanis, mint írtam els?sorban NEM a programozói gyakorlat a lényeg, amikor alkalmazok egy új
> programozót. Azért nem, mert azokat a techológiákat, eszközöket, bels? szabályokat (meg mindent,
AZÉRT mert a te fejlesztésed ZÁRT. Ahhoz, hogy kihozd a maximumot a dologból neked azt kell csinálni, amit csinálsz/mondasz.(Erre a tételre van indirekt bizonyításom:-))) Én arról beszélek, hogy a te maximumod lokális maximum, és léteznek magasabb hegycsúcsok is. Nem is kevéssel.
> amit korábban írtam) sehol máshol nem gyakorolhatta volna be, csak nálunk. Ezen nem segít a nyílt
> forráskódú fejlesztés.
u.a.
> Talán akkor lehete másképp, ha léteznének olyan open source szabványok, amelyek kifejezetten a
> fejlesztés módszertanára, a csapat, folyamat és termékmodellezésre és a kockázatmenedzsmentre
> vonatkoznának, továbbá ezt minden cég, vagy fejleszt? be is tartaná. Egyel?re azonban ilyen
> speciális open source-ra vonatkozó szabványokról nem tudok. Vannak helyette/mellette azonban más
Ami neked kell, az az, hogy legyen egy könnyen számolható fels? becslésed egy tetsz?leges üzleti
problémáról, és a fejleszt?csapatodod ennek betartását keresztül tudd verni. Tehát képes legyél
árat mondani azonnal az ügyfélnek, és a csapatod képes legyen ennek az árnak valamekkora részébe
kerül?en ezt megvalósítani. A "módszertanok" ezekhez tartalmaznak egyszerü szabályokat. A lényegük,
hogy 1 lépés _garantáltan_ kisebb legyen annál, amit egy átlagember át tud tekinteni. Ekkor az emberfelvételnél is elég annyit nézni, hogy az adott delikvens rendelkezik-e átlagos képességekkel. ha igen, akkor képes megtanulni/megcsinálni a lépéseket. Ha jobb képességekkel rendelkezik, akkor több lépést is képes átlátni, és hatékonyabban bír dolgozni. Már ha ezt a cég engedi. Egy iso min?sítésnél, semilyen irányba nem lehet eltérni a szabályoktól. Jobbat sem lehet csinálni. Nekem nincs jó véleményem a módszertanokról. Igaz, hogy az elmúlt évig, ha valaki nagyban gondolkodott, csak a módszertanokkal mehetett valamennyire biztosra. Viszont már megjelentek az els? olyan tudományos kutatások, amelyek azt bizonyítják, hogy az opensource _önmagától_ eredményez gyorsabb, olcsóbb, és jobb megoldást ugyanarra a problémára. nem talalom, pont azt amit olvastam, csak ezeket: firstmonday.org [firstmonday.org] es NSF: Faster, Better, Cheaper: Open-source Practices May Help Improve Software Engineering es meg Open-source can be faster, better and cheaper than closed corporate software development, say researchers at the University of California, Irvine, and the National Science Foundation. [science.newsfactor.com]
Mást most nem találtam, de érdemes rákeresni a web-en. (nem a yyyymagazin-ban, ott csak az jelenhet meg, amit az m$ jóváhagyott, ? a legnagyobb hirdet?, ? diktál)
Oriasi elony meg az opensourcenal, hogy mig a zárt kódot fejleszt?k azt a feladatot irják, amit rajukbíztak, egy opensource fejleszt? abba ássa magát bele, ami a legjobban tetszik neki. Olyan ez, mint a kozepkorban beleszuletni egy cipeszcsaladba, vagy most sajat elhatarozasbol elmenni atomfizikusnak. Mostanaban nem beleszuletsz egy atomfizikus csaladba. Lehet, hogy nem erdekel. Ami nem erdekel, azt nem hatekonyan csinalod, nem ersz el akkora eredmenyeket. Ezert kell a zart fejlesztogardanal nagyon vigyazni, hogy senki ne kapjon tul bonyolult feladatokat. Minimalis eselye van, hogy erdekli a tema. ami erdekli az embert, arrol _mar regen_ sokat olvasott/tanult. az olyan feladatok megoldasat o _sokkal_ gyorsabban birja teljesiteni. Te hany fejlesztod programozasi hobbijat ismered? Azt, hogy mit csinal szabadidejeben, ha gep ele ul? ?k ismerik a saját hobbijukat! nem is kell elmondanijuk senkinek, hogy abban alkossanak. Érzed a szavak közt a különbséget: alkotás - munka
Ha megnézed a linux kernel fejlesztési menetét, vagy ellátogaszt a IBM opensource es/vagy linux oldalaira lathatod, hogy tobb szaz ceges ember dolgozik foallasban a linux es mas opensource projektet fejlesztesen. azt is lathatod, hogy az igazi szep, nagy atuto eredmenyeket nem ezek az emberek irjak. Olyanok, akiket nem szorit a hatarido, sajat kedvtelesbol megfesti a Mona Lisa-t. Azert mert nem tilos neki megfestenie! A M$-hoz _tilos_ egy 5-szor gyorsabb scheduler-t irni. A Linux-nal sokan sportot uznek abbol, hogy meg egy kicsit gyorsitsanak rajta. Mar eddig is a leggyorsabb volt (unixoknal 4-5-szor, vindoz-nal 100-szor), de most a O(1) schedulerrel, es annak javitgatasaival igazan nagyot dobtak. Linus oriasi tehetsege ott van, hogy _felismer_ egy Mona Lisa-t.
Az opensource fejlesztéseknél mindenki azt csinálja amihez kedve van. Ez nemcsak azt jelenti, hogy amihez a _legjobban_ ért, hanem azt is, hogy akkor, amikor a legjobban megy neki a munka. Nekem volt olyan fejlesztési id?szakom, amikor 100-szor gyorsabban voltam képes dolgozni, mint amúgy. Képes voltam el?re "kitalálni" a megrendel? óhajait. Egyszer?en átláttam, hogy mit, és miért csinál, és látszott, hogy majd kérni fogja. Kérte. Magas labda volt, mert persze meg is csináltam addigra. Ebb?l azt akarom kihozni, hogy egy opensource framework sok ilyen munkának az eredményét tartalmazza.
Nekem akkor hiába volt ez a "szárnyalásom", semmi sem maradt bel?le. Nyoma sincs. :-(( Azóta is bánkódom, hogy ilyen jó munkáim jogait kiadtam a kezemb?l. Nem csinálhatok vele semmit. S?T, senki sem csinálhat vele semmit. Ha opensource-ban lenne, akár én szabadid?mben fejlesztgetnék hozzá, nagyon a tetszett az a kód, amiket akkor csináltam. A zárt forráskód oriási hátránya az, hogy _senkit_ sem enged segiteni, kizárólag _az_ csinálhat valamit, és kizárólag _akkor_, akinek és amikor a feladata. Többet mondok. A te céged kódjaiból _te_ is ki vagy zárva. Hiába lenne kedved programozni, már nem nyúlhatsz bele, mert akkor megzavarod valakinek a határid?s munkáját. És ezzel nagyobb bajt csinálsz, mint amekkora hasznot hajtana a programozásod.
Ezek a szép dolgok nem fedik le _teljesen_ egy megoldás szállítás menetét, viszont minél több dolog van az opensource részben, annál kevesebbet marad a megoldas hataridos lezuzasaba. Az opensource rész szépen kitisztul, az egyedi "ragasztó" kódokat sokkal könnyebb megírni egy szép átlátható, logikus kódhoz, mint egy történelmileg így alakult kódhoz.
> Bizonyos termékeknél, szoftvereknél valóban el?ny lehet az, amir?l itt szó volt, de azon a
> fejlesztési területen, ahol én dolgozom (ügyviteli, kereskedelmi és speciális egyedi fejlesztés?
> szoftverrendszerek), ott hangsúlyosan nem. A világon jelenleg ezek a domináns szoftverek (több,
jelenleg nincs ezen a területen futó 1. kategóriás [draconis.elte.hu] opensource projekt. Ha lesz, azt érezni fogod. Pont annyira, mint a Watcom. Hol van már a C fordítója? GCC van, és kész.
> összetettebb, elterjedtebb) és nem pedig az open source fejlesztés?ek.
> Megjegyzés: Jelenleg szó nincs arról, hogy a szoftvert kinyissuk, meg a benne lév? tudást "csak
> úgy" átadjuk mert ez járhatatlan út (kivéve a szerz?déses partnereket). Az igazi érték mindig a
> tudás, ami a fejekben van meg az üzleti logika, ami a forráskódban és adatmodellben rejt?zik. De
> ez már egy másik történet lenne...
Az igazi érték az ember. Ha egyszerre elmennének a jó embereid, akkor a hajadra kenhetnéd a forráskódokat. És nekiálhatnál 1-1.5 éves betanításnak. Bár jobb megoldás lenne a cég gyors megszüntetése. Innen már csak vinné a pénzt. Talán ha az ügyfelek el?l sikerülne eltitkolni, akkor még egy ideig vegetálhatna a cég karbantartás címszóval. Ha a forrádskódok nagy része opensource, akkor a céged függése is csökken a saját embereidt?l. Mivan ha elüti ?ket a villamos, mondjuk egy jól sikerült céges sörözés hazatámolygása közben? Az opensource mindenkinek csökkenti a függ?ségét mindenkit?l. Nehogy azt hidd, hogy mivel te vagy a cég tulajdonosa neked kevesebb függ?séged van, mint egy alkalmazottadnak. S?t!
GYERE KI EGY ÉVRE BALIRA!
Hát nem megy ugye? Túl sokba kerülne. Nem az, hogy itt kint vagy, hanem az, hogy nem vagy otthon!
Egy forráskód ha nem követi az id?k változásait, akkor "beporosodik", antik lesz. A zárt forráskódu fejlesztéseknél nagy gondok a "bebetonozott" szintek. Az okosak megtervezték a framework-ot. A fiatalok, meg menjenek, és nyomjanak le vele projekteket. Néha még az API szint mögé sem nézhetnek be. Ez rendkívül jót tesz a framework (vissza)fejl?désének.
Szerinted miért kezdi másolni a M$ a linux kernel fejlesztési metódusait? Miért alakította át a saját bels? szervezetét, úgy, hogy a kernel fejlesztésre létrejött egy külön csapat, ami a különböz? oprendszerei (XP,CE,longhorn,...) közös kernelét tartja karban. Kimondták (Az M$!!), hogy azon csodálkoznak, hogy bár a linux rendkívül sokfelé használható (beágyazott, desktop,szerver,szupercomp,...), mégis egységes maradt a kernel. gondolom náluk nem. Minden manager a saját rövidtávú céljai miatt forkolta a kernelt. Persze a hatarid?. így biztosan belefér, ha nekiállna szarakodni a korrekt beillesztéssel lehet hogy kicsuszna a határid?b?l.
Amikor minden lépés határid?höz kötött, akkor mindenki _kizárólag_ az aktuális lépés minimális (de azért még elfogadható) mértékü teljesítésével foglalkozik, és nagy ívben szarik arra, hogy a tevékenysége milyen károkat okoz másnak, vagy a jöv?nek. Ha nem ezt csinálná, akkor a saját részével lennének gondok. így nagy valószínüséggel máséval lesznek. Nem mindegy!
Ezért van szükséged _rengeteg_ profi tervez?re, hogy folyamatos ilyen szemlélet? programozók/managerek, de barmolják szét a kódot/projektet. Ha csak egy kicsit is rossz a tervezés, már nem lesz termék. Lásd elöbb. Az emberek egymás ellen dolgozhatnak.
Másik gond, hogy a fejleszt?k között _soha_ sincs egyetlen felhasználó sem. Az opensource projekteknél mindig dönt? részben a felhasználók is részesei a fejleszésnek. Nem hagyják, hogy bárki bármely lépésben a egész ellen dolgozzon. Nem muszáj olyan brutális tervez?i kapacitás ennek megakadályozására.
OK, értem, hogy elég nehéz összehozni -még gondolatban is- a céges megoldásszállítást, és az opensource-ot.
De nem lehetetlen. Fogadjunk:-))
Ja. van meg néhány szösszenetem ez ügyben. Ha van kedved, olvasd el. Szerintem tanulságosak:
retek sorozat, szepen sorban:-) [draconis.elte.hu]
Ha meg kivancsi vagy ki a retek vagyok, azt megtalalod itt :-) [draconis.elte.hu]
> Köszönöm a figyelmet,
> Üdv.
> KJ.
Tisztelettel:
Andrej
ui: megprobalom a hup.hu-ra is megvalaszolni, de a vilagvegererol, ez nem biztos, hogy sikerul, ezert elkuldom mailban is.
ui2:minimálisan 2 nap szukseges, hogy barmire reagaljak. Bocs.
- A hozzászóláshoz be kell jelentkezni
Sziasztok, lenne ket kerdesem a temaban:
1.; Mibol el meg egy OpenSource programozo, aki
napkozben nem penzes sw-t hegeszt
2.; Ha minden sw open lenne, mibol elne meg a tobbi
Nekem ugyanis sajnos nincs mibol 'lemenni Bali-ra', es a villanyszamlas sem lenne elragadtatva, ha penz helyett ket kilo leporellot nyomnek a kezebe, hogy 'Tuti kod, Oreg!' (bar meg nem probaltam :)
Amugy hobbiszinten vagyok eleg idealista es reszelgetem openben a dolgaimat hetvegenkent, de ha a munkahelyem nem kerne penzt a sw-ert, nekem se tudna fizetni, es mehetnek kaszalni napi 48 orat (dupla kasza, viharlampa, stb.).
A ciki meg az, hogy mikor nem volt melom, es asztalt pakoltam fillerekert, se idom, se energiam nem volt leulni hackelni, es hogy is mondjam, tobb honapi munkanelkuliseg es egyre gyulo szamlahalom mellol maskepp latszott a tema, mint a 'vilag vegerol' blogot irogatva. Kivanom, hogy bemondasra kelljen elhinned, de rengeteg ember a fizetos cuccok irasabol _el_, es ha masert nem, ezert szukseg van arra _is_. Az open sw-re meg azert, hogy valami rendesen mukodjon is a vegen :), de az mar egy masik tortenet...
- A hozzászóláshoz be kell jelentkezni
Hát szó ami szó, jó sokat írtál. Úgy érzem valaki félreinformálhatott téged
a "katedrális" jellegű fejlesztés minden lehetőségével kapcsolatban.
Jószerivel az összes pontra csak az ellenkezőjét tudnám mondani,
ezért csak néhányra reagálok (ellenkező estben véget nem érő levéláradat
lenne, ami nem jó).
[idézet szerző="Andrej"]
Ebben nem értünk egyet. Én úgy gondolom, hogy a szoftverek opensource-k lesznek
_mindenképpen_. A kérdés az az, hogy melyik mikor.
[/idézet]
Nos, remélem erre soha sem kerül sor. Nem vagyok forradalmár, nem akarom,
hogy a világ ezen része másképp működjön. Az általam és a cégem által alkotott
szoftvert nem szeretném, ha más is használná vagy átvenné a benne lévőket.
[idézet szerző="Andrej"]
Ha a terméked nyílt forráskódra alapulna, akkor tudnál felvenni olyan ember aki
a _te_ nyílt forráskodú termékedet ismeri. Pont ott tartana, mint a jelenleg
felvett embereid 5-6 hónap után. Sőt a gyereknek lennének referenciái. Meg
tudnál nézni kódokat, amiket a te projekteddel készített. Egy ilyenből _látszik_
hogy a jelölt alkalmas, vagy nem.
[/idézet]
Ez nem lehetséges. Pont ezt próbáltam volna elmondani. Nincs olyan ember a világon,
aki egy ilyen hatalmas és őrületesen összetett rendszer fejlesztését hobbiból
bevállalná. Engem soha sem érdekelt az ügyviteli fejlesztés, mégis csináltam évekig.
Hogy miért? Hát pénzért. Ha nincs pénz nem csinálom. A programozás iránti szerelem
úgy 10-15 év után már alaposan megkopik az emberben. Különösen akkor, ha nem
adatbázis-kezelőt, oprendszert vagy játékprogramot kell alkotni, hanem dögunalmas
integrált ügyviteli rendszereket (azért mert csak erre van kereslet).
[idézet szerző="Andrej"]
Amit viszont nem árt megcsinálni, az a programoddal/megoldásaiddal járó kötelező
_járulékos_ költségek minimálisra csökkentése. Az nem a te pénzed, hanem az M$-é,
vagy az Oracle-é. Ha a progid/megoldásod fut linux/mysql-en, akkor több pénz marad
neked. A megrendelő csomagot néz, és arról van elképzelése, hogy maximálisan
mennyit akar rákölteni. Nagyon nem mind1, hogy mennyi marad ebből a pénzből.
[/idézet]
Ez igaz. Mármint a megmaradt haszon. Csakhogy van itt egy kis bibi. Én azt
szeretném, ha a cég, ahol dolgozom pont olyanná válna, mint a Microsoft
vagy Oracle vagy C&A, stb. Igen, szeretném, ha hasznot hozna, de ehhez előbb
a pénzt el kell "vennem" a felhasználóimtól, a leendő ügyfeleimtől méghozzá
úgy, hogy észre se vegyék. Mindeközben persze arra is figyelek, amit írtál,
azaz a lehető legtöbb maradjon nekem. És itt jön a dolog zamata. Az élet nem
fehér és fekete. Mi évek óta igen jóban vagyunk pl. a Microsoftal (de akár az
Oracle-t is említhetném). Szivesen támogatjuk egymást (termékhasználat, közös
marketing rendezvények és bemutatók, közös termékismertetők, értékesítések),
cserébe ők is 7 számjegyű összegeket áldoznak reánk (kedvezményes licencek és
szoftverek, korlátlan szoftverhasználat kísérleti célokra, aktuális újdonságok
elsőkézből, oktatás, külföldi konferencia támogatása, ingyenes tanfolyamok
szervezése, hely a promóciós CD-ken, hely a magyar nyelvű termékeiken, stb).
Szóval, ha mi adunk, ők is adnak. E kettő nagyjából egyenlő mértékű.
Arról meg nekünk kell gondoskodnunk, hogy minél több maradjon a bugyorban.
Éppen ezért nagyon utálom amikor sokan és állandóan M$-oznak, de közben
elképzelésük sincs milyen folyamatok működhetnek a háttérben (ráadásul az
általam látogatott Microsoft vagy Oracle levlistákon soha egy rossz szóval
se illetik a konkurenciát). Szóval én ezt is kissé másképp gondolom.
[idézet szerző="Andrej"]
Ha _üzleti_ és zárt szoftverre gondolsz mond inkább azt. Megnézném, hogy az
MPlayer team-ben, vagy a Linux kernel több ezer fejlesztője között, milyen
_fontosabb_ szakemberek vannak a programozóknál.
[/idézet]
Semmilyen. Ismétlem: nem a programozó a lényeg. Bármikor tudom helyettesíteni,
átadni a kódjait egy másiknak. Néhány hét és máris zökkenőmentesen folytatódik
a munka. Ugyanez a tervezőknél, szervezőknél nem igaz. Az ő pótlásuk, nehéz,
mivel kevés a szakmailag értő, jó tervező ember. Márpedig tervezni kell.
Főleg egy ügyviteli rendszert. Aki nem dolgozott ilyenben, annak elképzelése se
lehet a valós helyzetről. Egy MPlayer-t vagy akár egy Linuxot össze se lehet
hasonlítani egy közel SAP méretű szoftverrendszerrel (azért a SAP-ot említem,
mert ő az első, mi csak a másodikak). Azért nem lehet összehasonlítani, mert
más kategória. Ezzel nem lebecsülni akarom az MPlayert vayg Linuxot, csak azt
mondom, hogy más. Egyszerűbb, kisebb, ráadásul zömmel "dobozos" terméknek
minősülnek, amihez képest gyökeresen eltérő fejlesztési módszereket kell
alkalmazni nálunk.
[idézet szerző="Andrej"]
Egy zárt fejlesztés rengeteg köztes embert tartalmaz a fejlesztő (programozó),
es a felhasználó között. Az opensource fejlesztés _senkit_. Azok az opensource fejlesztések
futnak _jelenleg_ a legjobban, ahol a fejlesztők is felhasználók. így tuti nincs kommunikációs
probléma:-)) Sőt rengeteg olyan probléma se létezik, amik nálad napi szinten
gondokat okozhatnak.
[/idézet]
Semmi olyan kommunikációs probléma sincs, mint amire gondolsz. Egyáltalán nem
a kőkorszakban élünk és nem értem miért gondolják a "bazár" (by: E. S. Raymond)
fejlesztéssel foglalkozók, hogy mindenki más idióta. A problémamegoldásra nálunk
külön stáb van, akik éjjel-nappal csak a menedzsmentel, a stratégiai vagy operatív
vezetéssel foglalkozik. Bármilyen külső vagy belső jelzés van azonnal ott vannak és
megteszik az adott pillanatban szükséges lépéseket. A fejlesztő meg fejlesszen.
Egyáltalán nem jó, ha a fejlesztők (tervező, szervező, programozó, tesztelő, oktató,
dokumentátor) az maga a felhasználó.
Azért, mert ők (mi) nem látunk meg mindent, amit egyébként az ügyfeleink igen.
Nem magunknak írunk rendszereket, hanem másoknak. Mi megadjuk az alaphangot és az
ügyfeleink pedig a kívánságlistát. Folyamatosan gyűjtjük az észrevételeket és igényeket,
melyek közül némelyiket ingyen, de a többségét pénzért valósítjuk meg. Ez a lényege a
munkánkak. Minden igényre figyelünk, de nem mindent valósítunk meg, csak azt, ami
illeszkedik a cég és a termék stratégiájába valamint nem okoz túl nagy fölös költséget.
Bármilyen vicces, de a módszereink egy része épp a Microsofhoz hasonlít. Hogy jó-e ez?
Természetesen igen. Nem szabad zsigerből elutasítani csak azért, mert ő a legnagyobb
szoftverglobalista a világon. Ellenkezőleg, inkább tanulni kell tőlük vagy bárki
mástól azt, ami jó. Márpedig senki se gondolja, hogy ott csupa hülyegyerek dolgozik.
[idézet szerző="Andrej"]
Tippelnem, hogy a te _fontosabb szakembereid_ kozul azok a legjobbak, azok akik
programozók voltak. tehát a fontosabb szakemberek nagy részére azért van
szükség, hogy megelőzzék azokat a problémákat, amelyek nyilt fejlesztés, és az ő
távolmaradásuk esetén fel se merülnek.
[/idézet]
Nem lehet azt mondani, hogy "a programozók a legjobbak". Ezzel akár azt is mondhatnánk,
hogy " a fogorvos jobb, mint a takarítónő". Égbekiáltó ilyent gondolni (már csak
azért is, mert az én anyukám régen takarítónő volt). Nálunk a szakterületeknek vannak
fokozatai. Nem mondhatom, hogy a programozó jobb, mint a szervező vagy a tesztelő.
Azért nem, mert nem ugyanaz a munkájuk és csak kevéssé lehetne összehasonlítani őket.
Ellenben létezik kategorizálás minden szakterületen, a "megjárja", a "jó" és a "profi".
Ezek jellemzőek lehetnek, de nem az almára és a körtére, hanem az almák között és a
körték között. A problémák megoldásáról meg fentebb már beszéltem.
[idézet szerző="Andrej"]
A zárt fejlesztéseknél jelentősek a kommunikációs hiányosságokból eredő gondok.
Az információ nem jut el ahhoz akinek szüksége lenne rá, ezért rendkívüli jelentőséggel bírnak
azok akiknek az információ szállítás, vagy az információs utak kialakítása, vagy a kommunikációs
problémák megelőzése a feladatuk. Erre szerintem alkalmasabb egy mailszerver, és egy
levlista:-))) Valamint az, hogy a résztvevőknek ne legyen lehetőségük máshogy információt
cserélni. Mindenki tudjon mindent. Mindenki _maga_ döntse el, hogy milyen információkra van
szüksége. Fogadjunk, hogy te jobban tudod milyen információkra van szükséged, mint én gondolom, hogy
neked mire van szükséged!
[/idézet]
Hihetetlen, hogy miket gondolsz! Kb. 8 éve létezik mail szerverünk (még Win 3.x alatt),
belső és külső levelezőlistánk, fórumunk, intranetes hírportálunk, HelpDesk szolgálatunk,
internetes tudásbázisunk, amellyel a technikai vagy ügyviteli információkat tudjuk közzétenni
magunk és az ügyfeleink között - és mindezt nap 24 órán keresztül. Ehhez hozzátartozik az
állandó, kötelező belső és külső oktatások (ügyviteli és technikai), az ügyfeleink oktatása,
konferenciák rendezése, tudásátadás és még kifulladásig sorolhatnám. Ez a gyenge kommunikáció?
A hab a tortán a cég minden területét lefedő ISO9001:2000 szabványnak való megfelelőség
(ez már elvárás, e nélkül nincs üzlet), valamint saját szabványaink. A saját fejlesztői
szabványainkban,a melyekben minden mozdulat le van írva (ki, mit, mikor és miért).
Saját bevezetési technológiánk, amellyel az ügyfeleinket segíthetjük az első lépések alatt.
Minden folyamatot, gondot, problémát nyomonkövetünk, regisztrálunk a saját szoftvereinkkel,
hogy később elemezhessük a történteket és javíthassunk a hibáinkon. Szóval ne haragudj,
de kissé komikusnak tűnik az, amit fentebb feltételeztél.
[idézet szerző="Andrej"]
AZÉRT mert a te fejlesztésed ZÁRT. Ahhoz, hogy kihozd a maximumot a dologból
neked azt kell csinálni, amit csinálsz/mondasz.(Erre a tételre van indirekt
bizonyításom:-))) Én arról beszélek, hogy a te maximumod lokális maximum, és
léteznek magasabb hegycsúcsok is. Nem is kevéssel.
[/idézet]
Igen valóban van magasabb. De azt én nem a nyílt forráskódú fejlesztésben,
hanem a saját módszereink, hatékonyságunk és embereink tökéletesítésében látom,
amihez nem kell más, mint pénz és szerencse. Pénz, amit "ki kell énekelnem"
az ügyfeleim szájából anélkül, hogy ők ezt észrevennék.
[idézet szerző="Andrej"]
Oriasi elony meg az opensourcenal, hogy mig a zárt kódot fejlesztők azt a
feladatot irják, amit rajukbíztak, egy opensource fejlesztő abba ássa magát
bele, ami a legjobban tetszik neki.
[/idézet]
No még csak az kéne. A fejlesztő ne azt csinálja, amihez kedve van, hanem azt,
amire a cégk (ahol dolgzik, ami a megélhetést biztosítja a számára) meghatározott.
Úristen! Itt nem hobbiról, hanem kőkemény munkáról, határidőkről, felelősségről,
bíróságról perekről, tragédiákról, milliókról, múltról és jövőről van szó!
Sajnálom, de ebbe nem fér bele a programozó jókedve. Azt, hogy mit csináljon
pedig a cégstratégia hosszú és rövidtávú érdekei tartalmazzák.
[idézet szerző="Andrej"]
Te hany fejlesztod programozasi hobbijat
ismered? Azt, hogy mit csinal szabadidejeben, ha gep ele ul? Ők ismerik a saját
hobbijukat! nem is kell elmondanijuk senkinek, hogy abban alkossanak. Érzed a
szavak közt a különbséget: alkotás - munka
[/idézet]
Már hogyne ismerném. Együtt élek velük, együtt sörözünk, beszélgetünk,
együtt sírunk és nevetünk. Ez egy csapat, amit hosszú évek alatt lehet
csak felépíteni és akkor is működik, ha a tagok közben jönnek-mennek.
[idézet szerző="Andrej"]
A M$-hoz _tilos_ egy 5-szor gyorsabb scheduler-t irni. A Linux-nal sokan
sportot uznek abbol, hogy meg egy kicsit gyorsitsanak rajta....
[/idézet]
Ugyan már. Ez elfogultstág, hitvita, amiben én nem akarok szerepelni.
Egyrészt mert nem értek vele egyet, másrészt, mert csak akkor lehet
ilyent mondani, ha az ember gyakorlatban tapasztalta.
[idézet szerző="Andrej"]
Az opensource fejlesztéseknél mindenki azt csinálja amihez kedve van. Ez nemcsak
azt jelenti, hogy amihez a _legjobban_ ért, hanem azt is, hogy akkor, amikor a
legjobban megy neki a munka. Nekem volt olyan fejlesztési időszakom, amikor
100-szor gyorsabban voltam képes dolgozni, mint amúgy. Képes voltam előre
"kitalálni" a megrendelő óhajait.
[/idézet]
A kedvről már beszéltem. A fejlesztés az munka és nem kedv kérdése.
A kedv az, amit otthon hobbiból csinálok. A megrendelő óhajait meg
nem lehet előre kitalálni, legfeljebb sejtetni. Az elmúlt években
sok-sok embernek nem sikerült. És mivel ez nem fejlesztési kérdés,
így szerintem nem is érdemes vele most foglalkozni.
[idézet szerző="Andrej"]
A zárt forráskód oriási hátránya az, hogy _senkit_ sem enged segiteni,
kizárólag _az_ csinálhat valamit, és kizárólag _akkor_, akinek és
amikor a feladata. Többet mondok. A te céged kódjaiból _te_ is ki vagy
zárva. Hiába lenne kedved programozni, már nem nyúlhatsz bele, mert
akkor megzavarod valakinek a határidős munkáját. És ezzel nagyobb bajt
csinálsz, mint amekkora hasznot hajtana a programozásod.
[/idézet]
Ez a szoftverfejlesztés lényege. Nekünk a mindennapi megélhetésünk
függ a cégtől, a munkától és nem a szórakozásunk. Szeretnénk nagyok
lenni, piacot nyerni, terjeszkedni belföldön és külföldön egyaránt.
[idézet szerző="Andrej"]
Az igazi érték az ember. Ha egyszerre elmennének a jó embereid, akkor a hajadra
kenhetnéd a forráskódokat.
[/idézet]
Tévedés. Az elmúlt évben 5 programozóm ment el - még több pénzért.
Mégis itt vagyunk, élünk és virulunk. És tudod miért? Azért,
mert van szabványaink, saját belső technológiáink. Mert mindenki
mindig csak azt és úgy csinálhatta, miben megállapodtuk. Ezért
az utód mindent ott talál, ahol az előd abbahagyta. A váltás
folyamatos, max. néhány hét és máris ott vagyunk, ahol azelőtt.
Ez persze nem tévesztendő össze az új fejlesztő (vagy bárki)
felvételével és betanításával.
[idézet szerző="Andrej"]
Szerinted miért kezdi másolni a M$ a linux kernel fejlesztési metódusait? Miért
alakította át a saját belső szervezetét, úgy, hogy a kernel fejlesztésre
létrejött egy külön csapat, ami a különböző oprendszerei (XP,CE,longhorn,...)
közös kernelét tartja karban. Kimondták (Az M$!!), hogy azon csodálkoznak, hogy
bár a linux rendkívül sokfelé használható (beágyazott,
desktop,szerver,szupercomp,...), mégis egységes maradt a kernel. gondolom náluk
[/idézet]
Na és, ha így van? Tanulni lehet bárkitől. Pont attól válik valaki jobbá,
ha nem szégyenli bevallani, hogy más valamit másképp, esetleg jobban csinál.
A jó ötleteket át kell venni. Ez még nem egyenlő a nyílt forráskódú
fejleszéssel, pusztán menedzsment és stratégiai kérdés.
[idézet szerző="Andrej"]
Amikor minden lépés határidőhöz kötött, akkor mindenki _kizárólag_ az aktuális
lépés minimális (de azért még elfogadható) mértékü teljesítésével foglalkozik,
és nagy ívben szarik arra, hogy a tevékenysége milyen károkat okoz másnak, vagy
a jövőnek. Ha nem ezt csinálná, akkor a saját részével lennének gondok. így nagy
valószínüséggel máséval lesznek. Nem mindegy!
[/idézet]
Nem túl szép beszéd. Ne izélj már. Ugye nem gondolod, hogy az emberek sz...t
szeretnének csinálni? Van, aki igen, de a többsége profi, rendes ember, aki
egy jobb jövőt szeretne. Gondoltál már arra, ha a microsoft nem lenne, most
nem írhatnánk itt ezt a levelet? Nekik és az IBM-nek köszönhetjük,
hogy a PC elterjedt.
[idézet szerző="Andrej"]
Ezért van szükséged _rengeteg_ profi tervezőre, hogy folyamatos ilyen szemléletű
programozók/managerek, de barmolják szét a kódot/projektet. Ha csak egy kicsit
is rossz a tervezés, már nem lesz termék. Lásd elöbb. Az emberek egymás ellen
dolgozhatnak.
[/idézet]
Bocsáss meg, de erre nincs mit mondanom. Ha körbenézel a világon láthatod,
hogy a tervezés a legfontosabb. A fejlesztési idő 60%-át kell, hogy lekösse,
a 30% a programozás és 10% a tesztelés. Nagyjából így kellene kinéznie.
Ha nem lenne tervezés, szervezés akkor te, mint programozó kimennél az
ügyfélhez és karakánul felmérénéd a teljes termelési üzleti folyamatait?
Vagy beugranál az egyik minisztériumba tárgyalni az államtitkárokkal,
gazdasági vezetőkkel, felmérnéd a pénzügyi lehetőségeket az államigazgatás
terén, majd mindezt megterveznéd, dokumentálnád, specifikálnád minden
kötelező papírokkal együtt? Esetleg elvégeznéd a hosszas, néha hónapokig
tartó terv egyeztetéseket, hadakoznál az ellendrukkerekkel, a régi
begyöpösödött informatikus bagázzsal? Én nem hiszem. Nem véletlen,
hogy a tervezés a legfontosabb. És nem azért, amiért te írtad.
Néhány idézet egy általam nagyra becsült szerzőtől:
[idézet-1 szerző="Joel Spolsky"]
- Szalagcím: Az IBM milliókat költ nyílt forráskódú rendszerek kifejlesztésére.
- Mítosz: Azért teszik ezt, mert Lou Gerstner olvasta a GNU alapelveket, és rájött,
hogy igazából nem is szereti a kapitalizmust.
- Valóság: Azért teszik ezt, mert az IBM IT tanácsadó céggé alakul. Az IT tanácsadás
a vállalati szoftverek kiegészítő terméke. Az IBM tehát igyekszik tömegcikké változtatni
a vállalati szoftvereket, és ennek legjobb módja, hogy támogatja a nyílt forráskódú
kezdeményezést. És lám, tanácsadó divíziójuk egyértelműen nyer ezzel a stratégiával.
[/idézet-1>
[idézet-2 szerző="Joel Spolsky"]
- Szalagcím: A Netscape nyílt forráskódúvá teszi webböngészőjét.
- Mítosz: Azért teszik ezt, hogy ingyen kódoljon nekik az új-zélandi internet kávézók törzsközönsége.
- Valóság: Azért teszik ezt, hogy tömegcikké tegyék a webböngészőt. [...] A Netscape azért tette
nyílt forráskódúvá a Mozilla-t, mert ebben látta a lehetőséget a böngésző olcsóbb fejlesztésére.
Tehát olcsóbban használhatta ki a tömegcikk előnyeit.
[/idézet-2>
[idézet-3 szerző="Joel Spolsky"]
- Szalagcím: A Sun és HP finanszírozza a Ximiant a Gnome fejlesztésére.
- Mítosz: A Sun és HP támogatja az ingyenes szoftvereket, mert szeretik a sokszínűséget.
- Valóság: A Sun és HP hardvercégek. Gépeket gyártanak. Annak érdekében,
hogy pénzt keressenek a gépeken, tömegcikké kell tenniük a hardvereket kiegészítő
ablakozó rendszereket.
[/idézet-3]
Zárom soraimat. Többet írni erről a részemről értelmetlen lenne,
mivel csak ismételném önmagam és sorra cáfolnám a saját
tapasztalataimmal az általad leírtakat.
Köszönöm a figyelmet,
Üdv.
KJ.
- A hozzászóláshoz be kell jelentkezni
Túl szép lenne, ha így lenne. Bizonyos szoftverek esetén tán még igaz is lehet, de egyébként nem. A cégem és jómagam 1994 óta foglalkozunk ügyviteli szoftverrendszerek fejlesztésével (jelenleg a 2. legnagyobb az országban), szoftvertechnológiával, programozók képzésével és vezetésével. Természetesen kereskedelmi termékről van szó (ami se nem nyílt, se nem ingyenes, mert, ha az lenne, akkor nem tudna 100 embert, azaz egy teljes céget eltartani).
Sajnos az elmúlt 10 év tapasztalata alapján azt kell mondanom, hogy fabatkát se érek az olyan programozókkal, akik ezerrel túrják mások forráskódjait. A mi esetünkben ez nem előny. Én úgy veszek fel programozót, hogy azt nézem meg mennyire kreatív, alkalmazkodó, fejlődőképes. Ha 3 hónap után nem látom a fejlődést, akkor meg kell válnom tőle.
Jelenleg 15 programozóm van. Az alap programnyelv megtanulása, begyakorlása 2-3 hét, tehát ezen hamar túl vagyunk.
A többi dolog, ami csak a cégre jellemző (saját class-ok, objektumkönyvtárak, belső szabványok, speciális technikák) az meg 2-5 hónap. És ez valóban nehéz és költséges folyamat, amelyen az, hogy mennyit búvárkodott már más forrásokban - nem könnyít.
Ráadásul az open source vagy ingyenes szoftverfejlesztésből nem tudunk megélni (holott mi ebből szeretnénk profitot termelni), így marad a 2-5 hónapos képzési idő.
Ezen csak belső szabályokkal, megfelelő oktatási tematikával és gyakorlati képzéssel tudunk valamit rövidíteni. Ha okos és ügyes az illető 2 hónap után már bevethetem élesben is (hogy termeljen már végre valami pénzt is ne csak vigyen). Kb. 5-6 hónap után már közepes munkát is tudok neki adni, de igazán profi csak 1-1.5 év után válik valaki. És ez még akkor is igaz lenne, ha előtte megírt volna egy saját Linux-ot.
Sajnos a nagyüzemi, vérre menő, egymás ellen versengő vadkapitalista szoftverfejlesztés piacán ez van. Hogy jó-e ez? Igen jó. Szerintem másképp ezt nem lehet csinálni.
Én úgy gondolom amíg egy fejlesztőt nem szorítja a határidő, nem kell figyelnie a konkurrenciára, nem folytat éles versenyt, nem dolgozik napi 10-14 órát folyamatosan és nem kell elszenvednie a megrendelők rigolyáit, anyázásait, fenyegetőzéseit vagy nincs kitéve a napi idegőrlő stresszhatásoknak, akkor az a mi felfogásunk szerint nem alkalmas komoly fejlesztési munkára.
Senkit se szerettem volna megsérteni. A szándékom csak az volt, hogy elmondjam, hogyan néz ki ez a valóságban.
Köszönöm a figyelmet,
üdv.
KJ.
- A hozzászóláshoz be kell jelentkezni
Félreértettél valamit azt hiszem. A cikk nem azt mondta, hogy zárt forráskódú termék fejlesztéséhez keress nyilt forráskódot "túró" fejlesztőt! Hanem azt, hogy fejlessz nyílt forrásra és mindig lesz gyakorlott progarmozód.
- A hozzászóláshoz be kell jelentkezni
Miért írod mindig azt, hogy "Joelon írta"? Ez valami jópofaság, vagy csak nem tudod, hogy a fickót Joel Spolskynak hívják? A weblapjának neve "Joel on Software" azaz "Joel véleménye a szoftverről".
- A hozzászóláshoz be kell jelentkezni
trey,
nem lehetne az embedded helyett inkább "beágyazott" oprendszert írni?
köszi!
Fidusz
- A hozzászóláshoz be kell jelentkezni
Azt hiszem, hogy ket dolog elkerulte a figyelmedet:
1.) "anr küldte be a hírt:"
2.) a cikk `` '' jelek között van, azaz idezet
Ez a ket dolog azt jelenti, hogy nem en irtam a cikket. Ebben az esetben a cikk irojanak kell cimeznek ezeket a kereseket.
- A hozzászóláshoz be kell jelentkezni