Opensourcesoftware
Opensourcesoftware (soms ook openbronsoftware) is computerprogrammatuur waarvan de gebruiker de licentie heeft om de broncode te bestuderen, aan te passen, te verbeteren, te verspreiden of te verkopen. De gehanteerde softwarelicentie bepaalt voor welke doeleinden de broncode ingezet mag worden.

De ontwikkeling van opensourcesoftware komt vaak tot stand op publieke en gemeenschappelijke wijze, door samenwerking van individuele programmeurs, overheden en bedrijven. Opensourcesoftware is tevens de meest prominente ontwikkeling in de opensourcebeweging.

Situatie 
Een opensource-computerprogramma wordt uitgegeven, vrijgegeven aan gebruikers in twee onderdelen: de software die een computer kan uitvoeren (de gecompileerde executable) en de 'broncode' waarmee deze software gemaakt is. De broncode is niet nodig om de software te laten werken, daarvoor is alleen de executable, het uitvoerbare bestand, nodig. Mocht iemand (een deel van) de software willen aanpassen dan heeft hij de broncode nodig, past deze aan en kan de nieuwe of andere versie compileren. Er is dan een nieuwe versie van de software gemaakt. 

Opensourcesoftwareprojecten kunnen ontwikkeld worden door een community, een gemeenschap van meerderen. Het succes van zo'n project is af te meten aan de activiteit en de hoeveelheid deelnemers aan de community.

De basis 

De ontwikkelmethode die Eric S. Raymond beschreef, gaat ervan uit dat de broncode van software beschikbaar gesteld wordt. Hiermee wordt de mogelijkheid gecreëerd om een programma aan te passen door eenieder die de kennis heeft om de broncode te begrijpen. Dit is voornamelijk gebaseerd op de gebruiken van de eerste (universitaire) computerspecialisten die (vanaf het begin van data-uitwisseling via bijvoorbeeld het interuniversitaire ARPANET) elkaar wilden helpen met het gebruiken van de (toen nieuwe) computers.

Geschiedenis 
Hoewel de opensourcebeweging onder die naam (open source movement) in 1998 is begonnen, komen de doelen van de beweging grotendeels overeen met die van de Free Software Foundation, en het concept van open samenwerking met vrij beschikbare broncode is al veel ouder.

In de jaren 60, toen de eerste grootschalige commerciële computers werden gemaakt door onder andere IBM, werd er vrij te gebruiken software bijgeleverd. 'Vrij' wil zeggen het kon worden gedeeld onder de gebruikers. Tevens zat de broncode erbij en kon software zo worden verbeterd en aangepast. Dit veranderde echter in de jaren 70: het werd gebruikers meestal niet langer toegestaan om dit soort software te ontwikkelen of te delen. Mede als reactie hierop gingen in de late jaren 70 en vroege jaren 80, verschillende groepen en hackers over tot het ontwikkelen van vrije besturingssystemen, zoals het latere GNU en FreeBSD.

Richard Stallman, een voormalig programmeur bij het laboratorium voor kunstmatige intelligentie van MIT aan de Amerikaanse oostkust lanceerde het GNU Project en richtte 4 oktober 1985 de Free Software Foundation ('stichting voor vrije software') op. Het uiteindelijke doel hiervan was een vrij besturingssysteem te bouwen. Als het ware een vrije kloon van het gesloten besturingssysteem Unix. De naam GNU is een recursief acroniem dat staat voor "GNU's Not Unix!". Als juridisch instrument werd daarnaast de GNU General Public License ontworpen om ervoor te zorgen dat GNU vrij zou blijven en om de vrije software te promoten. Stallman schreef eveneens het GNU-Manifest, waarin hij betoogt dat de beschikbaarheid van de broncode en de vrijheid om deze verder te distribueren en te wijzigen fundamentele rechten zijn.

Tegelijkertijd werd er in de Computer Science Research Group aan de Universiteit van Californië te Berkeley gewerkt aan een verbetering van het Unix-systeem en applicaties die al snel bekend werd als "BSD Unix". BSD staat hier voor Berkeley Software Distribution. Het project werd gefinancierd door DARPA-contracten en gesteund door Unix-hackers wereldwijd. Het werd onder BSD-licentie verdeeld aan het eind van de jaren 80, nadat de software alleen binnen de gemeenschap van Unix AT&T-licentiehouders was te verkrijgen. BSD Unix-gebruikers hadden daarentegen een AT&T-licentie nodig, ten behoeve van een bruikbaar systeem.

In de jaren 80 en 90 werd de ontwikkeling van het opensourceconcept voortgezet. Door het gebruik van USENET en Internet werd het mogelijk inspanningen van hackers en programmeurs in andere delen van de wereld te coördineren. Langzaam maar zeker kon op het Unix-besturingssysteem veel en verschillende software gebouwd worden. Het werd hoog tijd voor veranderingen en die kwamen in 1991 en 1992.

Bill Jolitz in Californië verwezenlijkte de ontbrekende delen van het besturingssysteem van BSD Net/2 en maakte het mogelijk dat het werkte op Intel 80386-machines. Ook beschikte het over een werkende kernel. Deze inzet werd zeer gewaardeerd binnen BSD- en Unix-gemeenschappen. Het werd verspreid onder de BSD-licentie, wat het meteen vrije software maakte.

Linus Torvalds, een informaticastudent uit Finland, verwezenlijkte de eerste versies van de Linux-kernel. Steeds meer mensen werkten hier uiteindelijk aan samen om de kernel te blijven verbeteren, en hulpprogramma's toe te voegen om een werkelijk besturingssysteem te voltooien, GNU/Linux6. In 1993 waren zowel 386BSD en GNU/Linux6 redelijk stabiele platforms. In de jaren 90 kwamen er vele opensourceprojecten met een grote hoeveelheid aan nuttige en hoogwaardige software beschikbaar, zoals Apache, GNOME, KDE en Mozilla. Vooral GNOME en KDE waren populair omdat ze toegankelijk waren voor mensen met minder technische kennis. GNU/Linux en BSD begonnen uit te groeien tot werkelijke alternatieven voor propriëtaire systemen.

In 1998 werd de broncode van Netscape Communicator vrijgegeven. Naar aanleiding hiervan kwam het begrip 'open source' uit een strategie-sessie op 3 februari 1998 in Palo Alto. Hierbij aanwezig waren Todd Anderson en Chris Peterson (Foresight Institute), John “Maddog” Hall en Larry Augustin (Linux International), Sam Ockman (Silicon Valley Linux User Group), Micheal Tiemann en Eric Raymond. Voorafgaand was Raymond uitgenodigd door Netscape om hen te helpen plannen met het vrijgeven van de broncode van Netscape Communicator. De leden van de strategiesessie grepen de release van de broncode aan om zich te bevrijden van de in hun ogen ideologische en confronterende connotaties van de term Free Software. Ze brainstormden over een tactiek en een nieuw label. Open Source, mede bedacht door Peterson, was het beste dat bij hen opkwam. De week daarop werd er hard gewerkt aan het verspreiden van de term. Op 8 februari deed Raymond de eerste openbare oproep aan de gemeenschap tot het gebruiken van de nieuwe term. De oprichting van het Open Source Initiative volgde kort daarop. Op 8 april werd op Tim O'Reilly's Free Software-top ingestemd met het besluit om het gebruik van de term "Open Source" te bevorderen en om de nieuwe retoriek van pragmatische en marktvriendelijke richtlijnen, ontwikkeld door Raymond, na te volgen.

Dit was het startpunt voor veel grote bedrijven om opensourcesoftware te accepteren. Eveneens begonnen de media nu ook meer aandacht te geven aan de voorheen marginale opensourcebeweging, die nu niet meer alleen bestaat uit particulieren en non-profitorganisaties maar ook uit kleine en middelgrote bedrijven.

In de vroege jaren 2000 waren een aantal bedrijven begonnen met het publiceren van een deel van hun broncode om te bewijzen dat zij meededen aan het Open Source fenomeen, terwijl zij de belangrijke delen voor zich hielden. Dit leidde tot het ontwikkelen van de nu wereldwijd gebruikte termen Free Open Source Software en Commercial Open Source Software om een onderscheid te maken tussen helemaal open en halfopen vormen van Open Source.

Open Source Definition 
Aan de hand van de Open Source Definition (definitie van open source, OSD) bepaalt het Open Source Initiative (OSI) of een softwarelicentie de kwalificatie open source verdient. De definitie is gebaseerd op de Debian Free Software Guidelines. Beide zijn geschreven en aangepast door Bruce Perens.

Ontwikkelingsfilosofie 
Eric S. Raymond presenteerde in het door hem geschreven essay The Cathedral and the Bazaar een model voor de ontwikkeling van opensourcesoftware, bekend als de bazaar. Deze theorie beschrijft hoe software ontwikkeld zou worden in een bazaarstijl. In zijn woorden: "Een grootse brabbelende bazaar van verschillende agenda's en benaderingen."

De traditionele wijze van ontwikkeling, de kathedraal, is meer gecentraliseerd. Rollen en taken in de ontwikkeling zijn hierin duidelijk onderverdeeld. De traditionele software engineering volgt het kathedraal-model. Softwareontwikkelaar Frederick P. Brooks pleit in zijn boek The Mythical Man-Month, voor het kathedraalmodel. Hij gaat hierop verder door te pleiten voor behoud van de onkreukbaarheid van het systeem. Het systeemontwerp zou gedaan moeten worden door zo min mogelijk architecten.

Het bazaarmodel daarentegen, hanteert geen specifieke rollen. Gregorio Robles schreef dat software ontwikkeld volgens het bazaar-model de volgende patronen zou moeten volgen:

Gebruikers moeten behandeld worden als medeontwikkelaars
De gebruikers zouden als medeontwikkelaars behandeld moeten worden en ook toegang moeten krijgen tot de broncode van de software. Zij kunnen bijdragen aan verbetering van de software. Volgens de Wet van Linus zouden alle problemen in de software gevonden kunnen worden en kan het systeem optimaal getest en ontwikkeld worden.

Vroege releases
De eerste release zouden zo vroeg mogelijk uitgegeven moeten worden om medeontwikkelaars zo snel mogelijk te betrekken.

Regelmatige integratie
Code die wordt veranderd, zou zo snel mogelijk geïntegreerd moeten worden, eventueel in een gedeelde code-database, om te voorkomen dat er pas aan het eind van het project codeproblemen worden opgelost. Bij sommige open source software is dit al het geval.

Verschillende versies
Er zouden op zijn minst twee versies van een softwarepakket moeten bestaan. Een stabiele versie met beperkte functionaliteit en een minder stabiele versie met meer of betere functionaliteit. De instabiele versie of ontwikkelingsversie (ook wel bèta genoemd) is voor gebruikers die over de nieuwste functies willen beschikken en het risico durven nemen om met software te werken die nog niet grondig is getest. Gebruikers zijn op deze manier ook medeontwikkelaars door feedback te geven op de software.

Modularisering
De algemene structuur van de software zou per module geprogrammeerd moeten zijn, zodat er tegelijkertijd ontwikkelingen gedaan kunnen worden aan verschillende componenten

Dynamische besluit-structuur
Hetzij formeel of informeel, zou er een besluit-structuur moeten zijn. Deze zou strategische keuzes moeten maken afhankelijk van het veranderen van gebruikersvereisten en andere factoren.

Ontwikkeling 
De structuur van medewerkers is duidelijk verschillend van de klassieke bedrijfsstructuur. In plaats van één enkel bedrijf dat het project ondersteunt, is het meestal een combinatie van groeperingen, individuen en eventueel bedrijven. Dit heeft enkele gevolgen:

 Er is meestal geen sprake van vooraf opgestelde tijdsschema’s, de ontwikkelaars werken aan dat deel waar ze het liefst aan werken en niemand is verplicht om te werken.
 Er wordt samen tot een consensus gekomen over de uiteindelijke functionaliteit etc. van het programma. Er is geen management dat beslist wat er uiteindelijk in komt of niet in komt.
 Er is een vage grens tussen ontwerp en implementatie: de ontwerper implementeert en vice versa.

Een groot deel van het programmeren wordt ook uitgevoerd en gecontroleerd door buitenstaanders. Iedereen kan een bijdrage leveren aan de code. In plaats van te wachten tot het programma volledig af is, worden er tijdens de ontwikkeling testversies van het programma publiek gemaakt. Zo kan het al door gebruikers getest worden voordat het werkelijk af is. Dit zorgt ervoor dat bugs die nog in het programma zitten, kunnen gedetecteerd worden voordat de definitieve versie van het programma verschijnt. Vaak zijn er verschillende versies parallel beschikbaar: een stabiele versie voor algemeen gebruik en een aantal ontwikkelingsversies.

Omdat er door meerdere mensen tegelijk aan wordt gewerkt, verschilt opensourcesoftware van commerciële software qua architectuur. Commerciële software is meestal onderling afhankelijk, de afzonderlijke delen zijn veel moeilijker aan te passen omdat alles zo sterk samenhangt. Bij opensourcesoftware is dit net omgekeerd: omdat er verschillende aanpassingen worden gemaakt en toepassingen worden toegevoegd, zit alles losser ineen. Dit is nodig aangezien dit type software een continu evoluerend proces is.

Verschil met andere software 
De meeste commerciële software is eigendom ofwel proprietary. De gebruiker heeft slechts een gelimiteerde licentie en mag zeker niet wijzigen of de wijzigingen verspreiden. Soms zijn er wel mogelijkheden om extensies te maken, maar het pakket zelf is onaantastbaar voor de gebruiker. De leverancier is de enige die inzage heeft in de software en wijzigingen kan en mag aanbrengen.

Opensourcesoftware voorkomt de vendor lock-in van een enkele softwareproducent. De gebruiker heeft te allen tijde de mogelijkheid om een fork te maken (een eigen versie), mits deze zich aan de licentie houdt : meestal betekent dit dat hij met het gewijzigd systeem ook de broncode moet publiceren.

Voordelen open source 
Indien software open source is, heeft de verkrijger de licentie om te wijzigen en de wijzigingen te verspreiden mits dit plaatsvindt binnen de voorwaarden van de licentie (beschikbaar stellen van de broncode). 

Hiermee is de gebruiker ook ontwikkelaar van het pakket geworden als hij daarvoor kiest. De meeste gebruikers/ontwikkelaars trachten hun wijzigingen in het originele pakket te krijgen door het bij de relevante community aan te bieden. Als dat niet kan, dan kan de gebruiker altijd een fork van de software en het pakket onder een gewijzigde naam publiceren. Voordeel van inbrengen in het originele pakket is dat het onderhoud voortaan bij het originele team ligt en dus automatisch meegaat met toekomstige versies van het systeem.

Leveranciers van open software zoals Red Hat focussen zich op service en hebben diepgaande kennis van de pakketten die zij ondersteunen. Dankzij dit model heeft een klant meer keuze vrijheid in leverancier waardoor hij Vendor lock-in kan voorkomen. Daarnaast kan een bedrijf of een klant met geld een ontwikkelaar inhuren om wijzigen specifiek voor deze klant door te voeren. Bij kleinere pakketten maken de ontwikkelaars zich vaak beschikbaar voor betaalde wijzigingen. Als gevolg zijn de wijzigingen daarna voor alle andere gebruikers ook beschikbaar.

Een ander voordeel is dat openbaarheid van de software ook meer ogen op de software toelaat met de daarbij behorende kritiek. Deze kritiek (mits opbouwend) kan zorgen voor een hogere kwaliteit dan wanneer slechts een kleine kring van ontwikkelaars toegang heeft tot de software.

Verder heeft opensourcesoftware vaak een community waar wijzigingen onder discussie zijn en in voorbereiding zijn. Hiermee hebben gebruikers en ontwikkelaars beiden invloed op toekomstige wijzigingen. De grotere community's komen regelmatig in conferenties bij elkaar.

Een minder zichtbaar voordeel is dat als een gebruiker een fork van de software maakt (andere versie onder een andere naam) en de originele ontwikkelaars vinden de wijzigingen zinvol, zij deze wijzigingen kunnen overnemen in het originele pakket. Dit geldt met name voor de GPL versies van software omdat deze niet proprietary te maken zijn. De BSD-licenties zijn wel om te zetten, mits de gebruiker zich aan de licentie houdt (voornamelijk vermelden van de originele licentie).
Zolang de software vrije software blijft, kan elke fork weer terug in het originele pakket komen.

Zoekmachine voor code 
Met een zoekmachine zoals Google Code Search of Koders kan in de meeste opensourcesoftwareprojecten die voor iedereen toegankelijk zijn naar beschikbare programmacode gezocht worden in onder andere PHP, Ruby, Javascript, Delphi, C++ en ASP.

Overheidssoftware 
In verschillende landen zijn initiatieven gaande om overheden op te roepen zo veel mogelijk opensourcesoftware te gebruiken in plaats van propriëtaire software. In Nederland heeft de Tweede Kamer in 2002 de Motie Vendrik aangenomen. Hiermee heeft de Tweede Kamer de Nederlandse regering opdracht gegeven om er zorg voor te dragen dat de Nederlandse overheid uiterlijk 2006 zou overgaan op open software en open standaarden. In het kader daarvan is onder andere het programma OSOSS opgezet.

Zie ook 
 Vrije software en opensourcesoftware
 Vrije software
 Lijst van opensourcesoftware
 Open Source Definition (OSD)
 Open standaard
 Publicdomainsoftware
 Sharedsourcesoftware
 Softwareontwikkelmethode
 Lijst van softwarelicenties

Softwarelicentie