Voor een volledige webserver op Linux is geen uitgebreid selectietraject nodig, kies gewoon Apache. Wanneer een minimale footprint op systemen een vereiste is en alleen statische pagina’s getoond moeten worden, loont het de moeite om een alternatieve webserver te gebruiken. Op Wikipedia is een beperkte vergelijking van lichtgewicht webservers te vinden. Op basis van programmeertaal en ondersteunde operating systems kan een eerste selectie gemaakt worden. Hoe kan de verdere selectie betrouwbaar worden uitgevoerd?
Voor de selectie van commerciële software zijn best practices beschreven. Deze kunnen niet zonder meer gevolgd worden voor de selectie van open source software. Commerciële software wordt geleverd door commerciële leveranciers, die hun best doen om hun producten te verkopen. Marteniek Bierman geeft in een artikel in Computable open source communities de rol van leverancier. Volgens mij vervullen deze communities meer de rol van producent en dat nuanceverschil geeft aan dat informatie vaak gehaald moet worden en niet wordt gebracht. De communities hebben natuurlijk het volste recht zich als producent op te stellen. Het maakt het selecteren van hun software er niet altijd eenvoudiger op.
Afhankelijk van de persoonlijke ervaring met open source en met communities zal een min of meer afgewogen keuze gemaakt worden. Het is de vraag of daarbij op alle aspecten wordt gelet en daarom is het belangrijk om het selectieproces van open source software methodisch aan te pakken. Zeker voor de bedrijven die onbekend zijn met open source en bijvoorbeeld huiverig zijn voor het niveau van de ondersteuning. Een voorbeeld van een methode voor selectie van open source software is QSOS (qualification and selection of open source software). De opstellers van deze methode geloven natuurlijk zelf ook in open source en stellen de methode beschikbaar onder de GNU Free Documentation License.
Op de website www.qsos.org wordt de methode gedetailleerd beschreven. Globaal worden de volgende fases doorlopen:
1. Definitie
2. Inventarisatie
3. Kwalificatie
4. Selectie
Tijdens de eerste twee fases worden objectieve aspecten van de software geïnventariseerd, waarna in de derde fase subjectieve wegingsfactoren worden toegekend om de selectie in de laatste stap te kunnen uitvoeren. Dit is nauwelijks revolutionair te noemen. De meerwaarde van deze methode ligt dan ook in de templates, die beschikbaar zijn voor de inventarisatiefase. Hierin zijn veel specifieke aspecten van open source software opgenomen. Tijdens het invullen van de antwoorden op alle vragen, ontstaat al een goede indruk over de sterke en zwakke kanten van open source producten.
Er is software beschikbaar om het gehele proces te ondersteunen. De software bestaat uit plugins voor op Mozilla gebaseerde browsers. De verzamelde gegevens worden uiteindelijk grafisch weergegeven in een profiel, waarbij de producten gescoord worden langs assen als duurzaamheid, bruikbaarheid en strategie.
Voor diverse rubrieken software, zoals RDBMS en Bug Tracker, zijn specifieke aspecten van de betreffende rubriek toegevoegd aan de templates. De profielen van verschillende producten worden gecombineerd om met elkaar vergeleken te worden. Het volgende voorbeeld betreft de selectie van een open source DBMS. Hiervoor zijn MaxDB, PostgreSQL en MySQL met elkaar vergeleken. De vergelijking van de profielen van deze producten ziet er uit als de afbeelding links.
Dit geeft de visuele samenvatting van alle verzamelde gegevens. Ik heb pas sinds kort kennis gemaakt met MySQL (versie 5) en daarbij vielen de relationele mogelijkheden van MySQL me nogal tegen in vergelijking met die van een commercieel RDBMS waar ik in het verleden mee werkte. Dat zie ik bevestigd in de lage score op het gebied van 'RDBMS functionalities'.
Het voordeel van de methodische aanpak is dat de sterke en zwakke kanten van de producten in kaart gebracht worden en dat een afgewogen keuze mogelijk is. En behalve voor de selectie van open source van anderen, kan de methode natuurlijk ook gebruikt worden om eigen open source producten te kwalificeren en daarna de onderdelen met lage scores aan te pakken om hoger te kunnen scoren in een selectieproces. En mocht de methode een zwakke plek hebben, stel dan verbeteringen voor aan de community van QSOS.
Als committer van QSOS vind ik het erg leuk om “ons” tool op Computable terug te zien. Een tijdje geleden heb ik een korte inleiding op QSOS geschreven op de ADI blog (zie http://adi.atosoriginblog.nl/2008/07/16/qsos-selectie-van-open-source-tools/ )
Bedankt voor de post…
Ik heb het in mijn artikel over gebruikers- en aanbieders van OpenSource. En niet over communities als leverancier zoals Siem schrijft. Voor de rest ben ik het helemaal met hem eens. Juist voor organisaties die (nog) weinig ervaring met OpenSource hebben, heb ik mijn methode ontwikkeld.