“In het Nederlandse hoger onderwijs wordt niet alleen serieus nagedacht over open source, ook wordt er volop over het onderwerp gediscussieërd. Bieden open source toepassingen meer flexibiliteit en vrijheid dan de ’traditionele’ elektronische leeromgeving (ELO)? En zijn die goedkoper of juist duurder? Zal open source de verwachtingen inlossen?”(bron)
Soms kom je mensen offline tegen op plekken waar je ze niet verwacht had, soms ook online. Had ik na het roemruchte congres van SURF in Amsterdam al geconstateerd dat ‘onze’ leverancier zich gelukkig niet liet wegzetten in de discussie over open source v.s. ‘traditionele ELO‘, ook in de column op de Edusite zet Carl (vind ik) helder neer waarom het geen zwart versus wit discussie is (of zou moeten zijn).
Ik weet het: ik ben absoluut niet objectief, immers het is de technisch directeur van de ELO die mijn werkgever gebruikt en ik heb zo ongeveer maandelijks een dag overleg in het kader van de taakgroep hergebruik en uitwisselbaarheid waar ook Carl namens Threeships lid van is.
Ik ben absoluut voorstander van het gebruik van open source software én (is aparte keuze) nog meer van het gebruik van open standaarden. Maar ik werk bij een onderwijsinstelling die besloten heeft dat ze geen softwareleverancier is en wil zijn. En we hebben de mazzel dat we een softwareleverancier hebben weten te vinden waarmee we een relatie kunnen hebben die vergelijkbaar is met die van een interne afdeling.
Een belangrijk verschil is er natuurlijk: Threeships blijft eigenaar van de broncode en bij een conflict kan dat een risico/probleem zijn. Van de andere kant is Threeships gelukkig voor ons (nog) klein genoeg om ook ons niet graag als klant te verliezen.
Zolang die balans er is en we van elkaar realiseren hoe de verhoudingen liggen lijkt me dat dus geen probleem. Dan is het net als het bepalen of je bijvoorbeeld een verzekering ergens voor wilt afsluiten: betaal je maandelijks een bedrag X extra om het risico van het optreden van een bepaalde gebeurtenis af te kopen of niet?
Toegang tot de broncode lijkt mij toch wel erg fundamenteel voor de continuïteit van de bedrijfsvoering. :/
Toegang tot de broncode in geval van nood (bijvoorbeeld leverancier failliet) kun je echter ook met een Escrow-overeenkomst regelen.
Volgens mij is de stelling in de column: ‘In plaats van te discussiëren over "OSS versus Commercïele Software" is het beter om het over "Make or Buy" te hebben.’ niet juist.
Een FLOSS totaaloplossing hoort thuis onder het kopje ‘buy’. De implementatie van een FLOSS oplossing zal een vergelijkbare inspanning vergen als de implementatie van een commerciele oplossing. Het bijkomende voordeel van de FLOSS oplossing is dat je:
– toegang hebt tot de broncode om eventuele problemen op te kunnen lossen;
– daardoor geen afhankelijkheid hebt van je leverancier;
– een product hebt dat (potentieel) door veel meer leveranciers ingezet wordt;
– wat uiteindelijk resulteert in ‘meer ogen = meer testen = minder bugs’ en meer add-ons.
Ik vermoed dat de ‘foute’ stelling komt omdat Carl ingaat op het stuk van Joost Becking. Joost stelt namelijk dat een FLOSS oplossing altijd leidt tot maatwerk.
Dat uitgangspunt gaat m.i. alleen op wanneer je werkt met een halffabrikaat product. Daar zul je inderdaad maatwerk bovenop moeten plaatsen. Naar mijn idee is dit niet wenselijk, i.v.m. kwaliteit (zie bovenstaand testpunt) & upgradebaarheid.
Het is beter om een generieke ELO engine te ontwikkelen/gebruiken en daar generieke (configureerbare) uitbreidingen in modulevorm op te implementeren.
Zijn **programmeren** en **configureren** niet gewoon punten in een spectrum van diepte, complexiteit, en andere factoren.
De concepten zijn afhankelijk van het platform wat men kiest voor ontwikkeling. Als men bijvoorbeeld RubyOnRails als platform neemt dan is de code altijd beschikbaar, terwijl de configuratie en het programmeren elkaar behoorlijk overlappen. Het hoeft dus lang niet altijd of/of te zijn.
De wereld is niet binare: Ik hoop dat men de ogen open houd voor alle mogelijkheden en zich niet beperkt tot de huidige aanbod, maar ook rekening zal houden met de ontwikkelingen in de toekomst.