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)."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)
Reactie geplaatst op 18-11-05 om 14:47 uur
Toegang tot de broncode in geval van nood (bijvoorbeeld leverancier failliet) kun je echter ook met een Escrow-overeenkomst regelen.
Reactie geplaatst op 18-11-05 om 15:23 uur
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.
Reactie geplaatst op 18-11-05 om 16:40 uur
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.
Reactie geplaatst op 18-11-05 om 17:34 uur
Gebruik [[URL]] of [[URL Titel]] voor het invoeren van links naar andere sites/pagina's.
Gebruik van WikiWoorden of [[wikiwoorden]] is mogelijk.
Toegang tot de broncode lijkt mij toch wel erg fundamenteel voor de continuïteit van de bedrijfsvoering. :/