Leveranciersonafhankelijkheid door OSS

[CEH08]

Ik ben bezig met een paper voor mijn studie, ik haal hierin aan dat het gebruik van OSS de leveranciersonafhankelijkheid vergroot. Ik moet dit nog wel empirisch onderbouwen...Misschien is iemand van jullie wel eens bezig geweest op dit vlak en kan je me een beetje op weg helpen.
Ik zoek dus stukken in vakliteratuur die dit vanuit de praktijk beschrijven.
Tot dusver heb ik alleen maar aannames gevonden en geen harde bewijzen.
Ook het weerleggen van de stelling is interessant natuurlijk.

Tx

[Sallin]

Misschien moet je "leveranciersonafhankelijkheid" wat beter definieren: wat leveren de leveranciers, waarom is het goed daar onafhankelijk van te zijn, komt de winst niet in de vorm van andere kosten ergens anders in het bedrijf boven drijven. Verder zou ik eens kijken bij de business sites van redhat, windows e.d. of je daar geen info van daan kan halen.

[Anoniem: 28958]

CEH08 schreef op woensdag 07 oktober 2009 @ 11:50:
Ik ben bezig met een paper voor mijn studie, ik haal hierin aan dat het gebruik van OSS de leveranciersonafhankelijkheid vergroot. Ik moet dit nog wel empirisch onderbouwen...Misschien is iemand van jullie wel eens bezig geweest op dit vlak en kan je me een beetje op weg helpen.
Ik zoek dus stukken in vakliteratuur die dit vanuit de praktijk beschrijven.
Tot dusver heb ik alleen maar aannames gevonden en geen harde bewijzen.
Ook het weerleggen van de stelling is interessant natuurlijk.

Tx

Nou, als je een praktijkvoorbeeld wilt hebben:

Er zit in mplayer een bepaalde feature die ervoor zorgt dat een verbinding als "verlopen" wordt beschouwd. Ik heb toen een aanpassing gemaakt, zodat de verbinding pas na een paar honderd jaar als verlopen wordt beschouwd (proxy server die eerst alles moet controleren kan zorgen voor een vertraging van een uur of zo bij grote binaire bestanden). Een betere aanpassing is een extra parameter toevoegen, maar daar had ik geen zin in.

Dit is een heel simpel voorbeeld, waarin ik ook een leverancier ben (aan mezelf). Het voordeel van OSS is dat je met een groep mensen dezelfde basis deelt. Iedereen kan op die basis doorbouwen, dus ben je een leverancier zat, dan zeg je: Toedeledokie!

Als je afhankelijk bent van een heel specifiek product (AutoCad/Solidworks/etc.) dan kun je dat niet doen. Afhankelijk van hoe handig je bent, kun je overigens meestal wel hierom heen werken, maar het kan zijn dat het je een vermogen kost. In de praktijk zijn mensen overgeleverd aan AutoDesk.

Dus, als je een bedrijf hebt, moet je altijd de overweging maken tussen geld in je eigen ontwikkeling stoppen of kiezen om een ander bedrijf nog machtiger te maken. Ik weet wel wat ik kies. Het kiezen voor gesloten software dat iets doet wat nergens duidelijk omschreven staat is een korte-termijn beslissing die tot hoge kosten later leidt.

En qua vakliteratuur, tja, wat is vakliteratuur? Er zijn genoeg mensen die baas zijn en dit soort anecdotes hebben opgeschreven en het is ook niet zo lastig om te bedenken dat het in enige vorm afhankelijk zijn van een bedrijf nooit goed is. Je zult zeker geen Microsoft publicatie vinden die dit soort dingen zegt.

Je moet denk ik ook niet in termen van specifieke stukjes software die altijd genoemd worden (OpenOffice vs MS Office), denken. Ik denk dat Excel bijv. nog steeds beter is als enig OSS alternatief, maar ik ben zelf geen gebruiker van Excel.

En ik vind eigenlijk dat als dit voor een universitaire studie is, dat het een beetje lui overkomt om hier iets te posten, maar goed.

[bobo1on1]

Ik vraag me af of je hier überhaupt harde bewijzen voor kunt vinden, het enige wat je kunt doen is praktijkvoorbeelden aanhalen en de conclusie trekken of leveranciersonafhankelijkheid haalbaar is in die specifieke situatie.

Daarbij lijkt geld mij een zeer grote rol spelen, stel ik zou een bepaalde (grote) feature van photoshop nodig hebben die niet in the gimp zit, dan heb ik de keuze tussen €150 uitgeven aan een photoshop licentie of een paar duizend euro spenderen aan een developer die die feature voor mij in the gimp gaat bouwen en er ondersteuning voor levert, en waarbij ik nog maar moet afwachten hoe snel die developer de feature heeft ingebouwd.

In dat geval is leveranciersonafhankelijkheid al een stuk minder haalbaar geworden, de kosten zijn fors hoger en er kan een redelijke tijd niet gewerkt worden.

[wzzrd]

bobo1on1 schreef op woensdag 07 oktober 2009 @ 15:06:
In dat geval is leveranciersonafhankelijkheid al een stuk minder haalbaar geworden, de kosten zijn fors hoger en er kan een redelijke tijd niet gewerkt worden.

Raar voorbeeld: je gaat als particulier zo'n aanpassing niet sponsoren in je eentje. Je doet dat óf in groepsverband (met een zgn. 'bounty') óf als bedrijf. In dat laatste geval wordt het heel snel rendabel: als je een stapeltje Photoshop licenties kunt besparen, loopt dat snel in de papieren.

En die functie wordt trouwens als 'ie eenmaal gemaakt is en geaccepteerd 'upstream' onderhouden. Daar heb je de maker dus niet voor nodig.

[Janoz]

bobo1on1's voorbeeld snijdt hout, maar hij ziet een cruciaal punt over het hoofd. Hij gaat er onterecht namelijk vanuit dat de feature al wel in Photoshop geimplementeerd is. Voor een juiste vergelijking moet je kijken wat het gaat kosten wanneer jij een feature nodig hebt die in beiden nog niet geimplementeerd is. In photoshop ben je overgeleverd aan de wil van Adobe. Willen zij het niet (bijvoorbeeld omdat ze het nut niet in zien of omdat jij toevallig net niet de triple A klant bent met een shiny diamond support contract) dan is het end of story. Voor de aanpassing in the Gimp daarintegen kun je zelfs de boer op. Je kunt bij verschillende partijen een offerte aanvragen en dan vergelijken welke jij het aantrekkelijkste vindt. Voor het implementeren van deze aanpassingen heeft die partij vervolgens dezelfde resources tot zijn beschikking als elke andere partij, incl de mensen achter the Gimp. De kans is vervolgens ook nog eens extra groot dat die aanpassing later alsnog gewoon in de 'normale' Gimp opgenomen wordt aangezien de opgeleverde code gewoon aan het project gedoneerd kan worden.

Het grote verschil is dat in het geval van OSS je jezelf niet vastketend aan 1 leverancier. Concurrentie kan ook doorgaan na de aanschaf van je product. Dit zorgt ervoor dat je de prijs kwaliteit verhouding van je support contracten goed kunt houden.

[laurencevde]

Bij veel projecten heb je niet eens een echte "leverancier"...

Paar voorbeelden van onafhankelijkheid:
Als de ene distro je niet meer aanstaat, pak je een andere. Al je applicaties en instellingen je je bijna probleemloos meenemen.
Alle distros draaien op dezelfde (linux-)kernel, maar een aantal kunnen ook op een compleet andere kernel draaien, en er draaien ook compleet andere typen userspace(non-gnu) op de linux-kernel. De keuze van de kernel staat dus redelijk los van de keuze van userspace.
Linux(kernel+userland) draait op zowat alle hardware, en is dus ook niet gelimiteerd aan het nogal archaïsche X86, bios, etc. Windows loopt echt ARM zwaar tegen te houden(ARM-based netbooks en laptops kunnen slechts in de marge spelen omdat je er geen zinnige windows op kan draaien. Zelfs al zou windows erop draaien, dan al de closed-source windows-apps niet...), en dankzij windows heeft elke pc nog steeds het antieke bios, simpelweg omdat windows nergens anders mee overweg kan...
Linux doet dit probleemloos, juist omdat de hele stack open-source is, en waar nodig aangepast kan worden, door elke fanaticus.
Veel van het bovenstaande komt ook door de modulaire opbouw van linux, maar dat komt ook weer omdat dat een noodzaak is in een dergelijke opensource-ontwikkelomgeving. Als pakketten teveel van elkaar afhankelijk worden, kan de ontwikkeling van het een gehinderd worden door het ander...

Je kunt simpelweg op zowat elk niveau zowat elk onderdeel uitwisselen/verbouwen/herschrijven zonder veel verdere problemen.


Maar uitwisseling van documenten en informatie is waarschijnlijk nog veel belangrijker. Open standaarden dus. Voor open-source projecten zijn er meestal niet echt redenen om geen open standaard te gebruiken, in tegendeel, maakt het ontwikkelen er alleen maar makkelijker op, dus meestal worden de open standaarden gehandhaafd. En zelfs al zou een project zijn eigen documentformaat erop nahouden, dan kan je altijd op zijn minst adv de broncode een convertor (laten) schrijven...


Je kunt je stelling ook omdraaien, en voorbeelden geven waarin de leveranciersonafhankelijkheid sterk verkleind werd door een closed-source-keuze, op een manier die bij open-source niet echt mogelijk was geweest.
Vendor-lock-ins bijv., en elke behoorlijke econoom zou je moeten kunnen vertellen wat daarmee mis is, zijn zo goed als onmogelijk met open-source-software...

[Anoniem: 294759]

laurencevde schreef op donderdag 08 oktober 2009 @ 05:52:
Bij veel projecten heb je niet eens een echte "leverancier"...

Klopt, omdat als daar ook sprake van zou zijn dat alle OSS projecten totaal oplossingen kunnen afgeven.
Dit is niet het geval. Sowiezo vind ik dat de TS zich moet realiseren wat OSS echt inhoud. Er is geen pakket met de grote noemer "OSS" die je bij verschillende partijen kan halen.

OSS zou ook op CSS opgevingen gerealiseert kunnen worden, daarmee alleen al oogt het flexibel.
Maar wat ik mij afvraag is: Gaat het hier om totaal oplossingen gebaseert op OSS of gedeeltelijk? Daarin zou de TS wat duidelijk in moeten zijn.
Omdat OSS projecten niet als totaal leveranciers gezien kunnen worden(mits wij hierover spreken), is het dus makkelijker om het te implementeren in CSS mits daar ondersteuning ervoor is. En hiermee wordt voor een groot deel de onafhankelijkheid gedefinieerd van OSS: de neutraliteit van omgeving, de diverse keuzen in projecten(en dus oplossingen)

Paar voorbeelden van onafhankelijkheid:
Als de ene distro je niet meer aanstaat, pak je een andere. Al je applicaties en instellingen je je bijna probleemloos meenemen.

Voor consumenten gaat deze mogelijkheid zeker op. Voor bedrijven worden de aantal smaken kwa distro's aanzienlijk kleiner omdat er maar een beperkte aantal grote partijen zich in willen zetten voor enterprise support voor hun distro. Voor een lange tijd is Novell Suse Enterprise en Redhat Enterprise die zich echt inzetten hiervoor. Heeft OSS er profijt van? Direct en indirect wel omdat deze bedrijven in het kader van de GPL, code teruggeven aan de community(in dit geval minimaal de Linux kernel). Plus het stimuleert innovatie aan. Is er dan nog steeds sprake onafhankelijkheid? Jazeker alleen de mogelijkheden zijn veel minder.

Veel van het bovenstaande komt ook door de modulaire opbouw van linux, maar dat komt ook weer omdat dat een noodzaak is in een dergelijke opensource-ontwikkelomgeving. Als pakketten teveel van elkaar afhankelijk worden, kan de ontwikkeling van het een gehinderd worden door het ander...

In theorie zou dat zo zijn. Echter is zijn er nog weinig stukken OSS die geen dependencies hebben naar elkaar toe. En waarom zou je? Als je voor ieder dingetje het wiel moet uitvinden of een aparte port voor jouw stukje code, nek je alles. Neem KDE bijvoorbeeld: om maar minilijstje te nemen van waarmee het allemaal afhankelijk is: libxml, Qt, OpenGL, stdlibc++, libjpeg, libpng, etc, etc. En dit is ook opensource software.

Je kunt simpelweg op zowat elk niveau zowat elk onderdeel uitwisselen/verbouwen/herschrijven zonder veel verdere problemen.

Dat is ook de kern van OSS. De vrijheid(mits toegestaan) van het verder (laten)ontwikkelen op bestaande broncode. En indien het GPL is: de verplichting om je broncode vrij te geven zodat andere projecten er profijt van kunnen hebben. Maar dit is vooral afhankelijk van het licentie model. Indien BSD licentie is dan hoef dat weer niet.

[Confusion]

CEH08 schreef op woensdag 07 oktober 2009 @ 11:50:
Ik ben bezig met een paper voor mijn studie, ik haal hierin aan dat het gebruik van OSS de leveranciersonafhankelijkheid vergroot. Ik moet dit nog wel empirisch onderbouwen...Misschien is iemand van jullie wel eens bezig geweest op dit vlak en kan je me een beetje op weg helpen.
Ik zoek dus stukken in vakliteratuur die dit vanuit de praktijk beschrijven.

Waarin meet je 'leveranciersafhankelijkheid'? Als je geen eenheid hebt waarin je die grootheid kunt uitdrukken, dan kan je empirische onderbouwing wel op je buik schrijven. Daarnaast zou je experimenten onder gecontroleerde omstandigheden moeten opzetten, waarin je dan het effect van het gebruik van OSS op die leveranciersafhankelijkheid gaat meten. Daar heb je natuurlijk de middelen en de tijd niet voor. Waarschijnlijk heeft niemand daar ooit de middelen en de tijd voor gehad.

Ik vind empirische onderbouwing een rare eis voor dit soort stellingen. Het blijft bij anecdotes, voorbeelden en onzuivere experimenten. Je kan alleen logische redeneringen aanvoeren, waarin je aantoont dat de stelling onder bepaalde aannames klopt.

De stelling dat OSS de leveranciersonafhankelijkheid vergroot is in zekere zin triviaal waar. Er is bij OSS geen sprake van leverancier waar je afspraken mee hebt, dus kan je er ook niet afhankelijk van zijn. Als je echter 'de community' tot leverancier bestempelt, dan kan je beide kanten op redeneren. Enerzijds legt die community je (vrijwel!) geen beperkingen op, dus kan de afhankelijkheid nooit groter zijn. Anderzijds zou een closed source leverancier weleens veel sneller op feature requests kunnen reageren, betere support leveren, etc. Dan wordt de afhankelijkheid die je ervaart juist groter, maar daarmee komen we terug bij het eerste punt: hoe meet je 'afhankelijkheid'? Eigenlijk heb je in dat laatste geval geen eerlijke vergelijking gemaakt, omdat je zou moeten vergelijken met een bedrijf dat support op gelijkwaardige OSS levert. Maar als die niet bestaat?

[Anoniem: 294759]

Wat vind TS er zelf eigenlijk van?