A nyílt forrás teljes növekedése

Open Source

Amit Deshpande és Dirk Riehle - az SAP Research munkatársai - egy tanulmányt készítettek a nyílt forráskódú szoftverek és nyílt forrású fejlesztés növekedéséről. A tanulmány megállapítása szerint a szoftverfejlesztés nagymértékű változáson megy keresztül. A teljesen zárt forrástól távolodva olyan fejlesztés irányába halad, ahol a termékekben és szolgáltatásokban megjelennek a nyílt forrású szoftverek. Hogy mennyire jelentős ez a változás? Ennek kiderítésére született meg a tanulmány, amelynek elkészítése során a kutatók több mint 5 000 aktív és népszerű, nyílt forrású projekt növekedését vizsgálták meg. Az eredmény: mind a nyílt forrású projektek száma, mind a nyílt forrású programsorok száma exponenciális mértékben növekszik. A tanulmány elérhető itt.

( vomberg | 2008. 03. 16., v – 17:08 )

A grafikonjaikat megnézve ezzel az exponenciális dologgal azért vigyáznék. Nem érzem én ezt tisztán exponenciálisnak, vannak benne telítődéses jellegű irányok is, elég bátor dolog egy e-ados görbét ráhúzni ezekre.

Szerintem egyszeruen arrol van szo, hogy a nyilt forras meg mindig ujdonsagnak szamit. A kezdeti szakaszon az exp. novekedes termeszetes. Kesobb atmegy telitesbe. Ha meg mar elavult, akkor lassan kihal (ez persze nyilt forrassal kapcsolatban egyelore nem fenyeget).
Bar a nyilt forras kozvetlenul nem technologia, ami hozza tartozik, az igen.
----
Anthill inside
honlap készítés

A Malthus-Verhulst összefüggések és a logisztikus modell ugye... de nem tudom, hogy ezek mennyire igazak erre az esetre. Az bizos, hogy a "környezet eltartóképessége" korlátos, de az (szerintem) nem, hogy ugyanúgy viselkedne mint egy biológiai populáció esetében, ahol az eltartóképesség közelítéssel időben állandónak tekinthető és nem függ a populáció behatásaitól.

a nyílt forrás sem annyira új dolog a nap alatt. a unixok forráskódja sosem volt olyan hétpecsétes titok, mint ma egyes kereskedelmi programoké. egy zárt kör, elsősorban amerikai egyetemek és pár fontosabb partner nemcsak hozzáfért a unix forráskódokhoz, de részt is vett a fejlesztésében javításában. mára az internetnek és olyan projecteknek mint a gnu köszönhetően a forráskód mindenki számára elérhető. elsősorban jogi okok miatt, ez a szélesebb nyíltság úgy valósult meg, hogy a kereskedelmi unixok pusztulásnak indultak, és egy tőlük jogilag független klónrendszer ezzel egyidőben felemelkedett.

( emberk | 2008. 03. 16., v – 17:20 )

Lehet kicsit radikális véleményem van de én így gondolom.:

Ez logikus, hogy így alakul. Egyszerűen, a leg-dinamikusbban (nem tudom hogy egybe vagy külön kell írni dötsétek el.) fejlődő iparág(-ak egyike) az informatika. A felődés legnagyobb kerékkötője pedig a "titkolózás", ergó a zárt kód. Egy kutatóintézet nem várhat arra hogy a nagy mamut ms a kódban lévő (szerintem sokszor szándékos) hibákat kegyeskedik orvosolni. Egyszerűbb 3-4 profi, akit egyébként is szerződtetnének, simán kijavítja egy nyílt kódban.

( turul16 v | 2008. 03. 16., v – 19:31 )

Nekem ugy tunik, hogy sokkal gyorsabban szuletnek, "disztro erett" szofverek, mint, hogy bekerulnenek a disztrokba ill. annak default repojaba. Ezert is van, hogy szerteszet mindenfele tarolokat hoznak letre, es szinte sekinek sem eleg a distroja hivatalos taroloja.

Regi hozzalas, hogy ami, nincs benne az alap repoba az szar is,ma oriasi tevedes lenne.

Alapveto valtozas fog bekovetkezni, a csomagok terjeszteseben elobb-utobb, a novekvo igenyek kiszolgalasanak erdekeben.

Talán a forrásalapú disztrók előnyben vannak, de ezeket a fileokat (ebuild, recipe, FrugalBuild (na jó, frugalware nem forrásalapú disztró, de akár az is lehetne :))) is tárolni kell valahol. Jó lenne, ha ezek a disztrók tudnának olyat, hogy van egy hivatalos tároló minden fontosabb program filejával, de egy másik tárolóba pl. reg után bárki tölthetne fel ilyen fileokat. Az egészet meg lehetne bonyolítani egy verziókövetővel, és valami ebbe integrált osztályozóval. Tehát ha egy csomag valakinél nem működik, akkor egyrészt osztályozhatja a rossz csomagot, másrészt tölthet fel újat. Ha egy csomag elér egy bizonyos pontszámot (pl. -100), akkor automatikusan az előző verzió lesz az alap.

Na, jut eszembe, Arch linuxnak van ilyen tárolója tudtommal, ahová bárki tölthet fel. Bár Frugalware esetében is működik a dolog, csak nincs ennyire pontosan megszervezve. :)

A forras alapu disztrok tenyleg elorebb vannak ilyen szempontbol. De en ott latom az elonyt, hogy igen konyu egy csomagot letrehozni, es utanna terjeszteni. Egy egy text filet sokkal konyebb megosztani masokkal, mint egy 100MB-os csomagot. Raadasul az ebuild alltalaban mukodik kulonbozo verzioju lib-ekkel is. Mivel mindig az adott rendszeren levo lib-eket hasznalja a forditasnal. Mig binaris disztrok eseteben, szite minden disztro verziohoz kulon package kell, igy ha nem a fo agat hasznalod akkor lehet, hogy a te rendszereden nem mukodik a csomag. Plusz ebuild igen konyen modosithato. Pl. ha kijon egy uj minor verzio akkor az esetek tobbsegeben eleg csak atnevezni az ebuildet, es mukodik is. Vagy apro modositasokkal megoldhato, pl csak x86-ot tamogat az ebuild, de upstream tamogatja az amd64-et is, csak hozza kell adni egy uj keywordot es mukodik is.

Gentoo eseteben, ha a portage tree-ben nincs csomag akkor, a bugzillaban alltalaban talasz egyet. En mar 5+ eve hasznalok Gentoo-t es eddig mindent csomagbol tettem fel. Ebbol csak 2 olyan csomag volt amihez nekem kellett ebuild-et irni, a tobbihez mindig talaltam valahol.

Ezzel az problema, hogy a komplex distribuciok rendelkeznek olyan infrastrukturaval, ami kulonbozik mas disztribuciok infrastrukturajatol. Pl. egy Debian install script azt mondja, hogy invoke-rc.d vagy update-rc.d, es onnantol mindegy, hogy sysv init vagy upstart van felinstallalva, olyan invoke-rc.d ill. update-rc.d van a rendszerben ami az aktualis init cuccot kezelni tudja, de ugyanezeket a parancsokat pl. Gentooban maskent hivjak.

( Botond | 2008. 03. 17., h – 16:34 )

mind a nyílt forrású projektek száma, mind a nyílt forrású programsorok száma exponenciális mértékben növekszik

Vagyis élnek. Kicsit abszurdnak hangzik, de erre már más is rájött. Az élőlények a nyílt forrású csomagtervek (projektek), a táptalaj a fejlesztők összessége, az élőlények építőelemei a forrássorok. Egyelőre exponenciálisan növekszenek, mert még korlátlanul rendelkezésre áll táptalaj, azaz nyílt forrású fejlesztő. De ha elfogy a fejlesztő, akkor a projektek egymás ellen fordulnak majd, és a táptalajt egymás elől eszik el. Ezt ismerte föl a Google, aki pénzjutalommal ösztönzi a saját csomagtervein dolgozó fejlesztőket.