Uw webproject voor 3000 euro?
Posted on | oktober 10, 2009 | 34 Comments
Na de vraag van Jente en een moment van broederlijkheid met Stijn na mijn uitlating over E-commerce pakket Magento had ik het graag even over het gebruik van open-source webpakketten zoals Magento en Drupal gehad. Ventileren, weet u wel.
Het gebeurt in de webwereld maar al te vaak dat wanneer een klant een webproject op poten wilt zetten, verschillende partijen worden opgezocht wat zich concreet vertaalt in verschillende offerteaanvragen. Wanneer de bedragen op zo’n offerte enigzins binnen het budget van de klant vallen kan de webbouwer doorgaan naar een eventuele 2e ronde. In zo’n pitch gaan webbouwers hun portfolio voorstellen aan de hand van presentaties van gerealiseerde projecten.
Laat ons even het voorbeeld van een webshop nemen. Daar moet de uiteindelijke keuze vaak gemaakt worden tussen twee verschillende mogelijkheden: of men kiest voor een webbouwer die een eigen systeem gebouwd heeft (of gaat bouwen) dat precies op maat gemaakt is voor de eisen van de klant, of men kiest voor een open-source e-commerce pakket zoals Magento.
Het belangrijkste verschil tussen beiden, en dat hoeft niemand te verbazen, is uiteraard de prijs. Er bestaat zelfs een gratis “community edition” van Magento waardoor je als webbouwer onmogelijk kunt concurreren op vlak van prijs.
Wat echter vaak wordt vergeten is dat je met een pakket als Magento een standaardpakket koopt. Wat je als klant niet uit het oog mag verliezen is de kostprijs van zo’n standaardinstallatie. Zo’n standaardpakket voorziet dus niet in specifieke functionaliteit die een klant nodig kan hebben. One-click webshops en do-it-yourself webapplicaties in het algemeen zijn zever in pakskes, dat weet zelfs mijn dochter van 5 maand. Je moet dus op iemand gaan rekenen om alles op een webserver geïnstalleerd te krijgen en te configureren. Er zijn webfirma’s die zich daarin specialiseren en die dat ook goed doen. Waar ik echter een probleem mee heb is dat bedrijven waarvan de core-business niets te maken heeft met webontwikkeling zich gaan profileren als bouwers van bijvoorbeeld een webshop door de installatie van een pakket als Magento. Heel wat van die mensen kennen helemaal niets méér dan wat in de gebruikershandleiding van de applicatie staat. Een gebruikershandleiding die zowel u als ik kunnen bestuderen. (in het geval van Magento is de gebruikershandleiding trouwens betalend heb ik gemerkt, ook van de community edition)
Functionaliteit
Uiteindelijk komt het erop neer dat heel wat pitches tussen verschillende webbedrijven worden gewonnen door diegene die de beste prijs kan voorleggen, iets wat in deze tijden best begrijpelijk is. Als webontwikkelaar heb ik er echter moeite mee dat we het soms moeten afleggen tegen minder technische personen die een gebruikershandleiding vanbuiten leerden om dan wat functionaliteit van “hun” systeem te kunnen gaan presenteren. Functionaliteit die misschien initieel niet in mijn systeem terug te vinden is, maar dat zonder problemen kan toegevoegd worden. Open-source pakketten lossen dit probleem op aan de hand van “plugins”. Geen stockbeheer? Geen probleem, installeer de “stock-plugin”. Een extra taal nodig voor de frontend van de webshop of website? Geen probleem, installeer de “localization-plugin”.
Wat echter wel eens uit het oog wordt verloren is dat de meeste plugin worden ontwikkeld door third-party ontwikkelaars die niet van elkaar af weten. Daardoor kan er nooit gegarandeerd worden dat geïnstalleerde plugins met elkaar overweg kunnen. Op termijn wordt dus een systeem gecreëerd dat bestaat uit allemaal losse componenten die onderhouden worden door externe partijen, de plugin-ontwikkelaars. Wanneer er in zo’n geval een update komt van de core (bijvoorbeeld een beveilingsupdate) van het standaardpakket kan het zijn dat de geïnstalleerde plugin niet meer werkt op het vernieuwde systeem. Als de ontwikkelaar beslist om zijn plugin niet verder te onderhouden en dus geen updates doorvoert waardoor de plugin breekt op de nieuwe versie van het core-systeem moet je als webbouwer zelf aan de slag. Dit resultaat vaak in een kostprijs die voor de klant niet min is doordat het heel wat langer duurt die aanpassingen door te voeren in programmacode waarmee die persoon nog nooit in aanraking is geweest.
Er is een markt voor open-source pakketten, dat is zeker. Indien dit niet zo zou zijn zouden pakketten als Drupal en Magento nooit de naam en faam verworven hebben waarop ze de dag van vandaag kunnen rekenen. Bent u bakker, beenhouwer of hondentrimmer dan is een pakket als Drupal perfect voor u. Betaal de buurjongen om de hoek 1000 euro en iedereen tevreden. Wenst u een webshop als onderdeel van uw core-business, een community-site om uw merk te promoten of een uitgebreid video-platform, kies dan voor een op maat ontwikkeld systeem. Als uw eisen in de toekomst veranderen, en dat zullen ze, is dit de enige mogelijkheid om ook na oplevering van de initiële website over een onderhoudbaar en uitbreidbaar systeem te beschikken.
Mijn gedacht.
Comments
34 Responses to “Uw webproject voor 3000 euro?”
Leave a Reply
oktober 10th, 2009 @ 12:32
[...] This post was mentioned on Twitter by Jurgen Lust. Jurgen Lust said: RT @netlash: Wijze woorden van Dieter over 'standaard pakketten' en open source: http://bit.ly/1p3LrD [...]
oktober 10th, 2009 @ 12:47
Volledig met uw standpunt eens. Ik maak wel eens de vegelijking dat opensource pakketten als Magento met doe-het-zelf materiaal voor beginners. Je kan heus wel een aantal gaatjes boren met je klopboormachine van de aldi, perfect voor de doe-het-zelver. Moet je echter dag in dag uit gaten door beton boren dan is meestal het aldi materiaal na 1 week al uitgezongen. Een pakket als Magento is dan ook perfect om een webshop op te zetten aan een laag budget. Wil je echter een professionele webshop met alles naar jouw wens geoptimaliseerd, ben je Magento zo aan het verbouwen dat de kostprijs al snel in de buurt komt van een op maat gemaakte website.
Ik zie dat deze site met Wordpress gemaakt is dus je maakt zelf ook gebruik van de voordelen van Opensource en terecht als je hiermee genoeg functionaliteiten hebt, voor ieder project moet apart bekeken worden of je optimaal wil profiteren van de opensource community of dat maatwerk voldoende voordelen heeft om de hogere kostprijs te rechtvaardigen.
BTW Wij bij Inventis zijn natuurlijk voorstanders van maatwerk met een meerwaarde.
oktober 10th, 2009 @ 1:06
Ik volg je voor 100%.
Wij maken het ook vaak mee dat bedrijven zich profileren als leverancier voor eGovernement-toepassingen … omdat ze Plone of Drupal kunnen installeren?
Zeer vervelend, want we komen dan ook vaak op plaatsen waar we de brokken moeten lijmen – met het resterende budget.
Daar komt dan bij dat de specifieke workflows, begeleiding van de nieuwe werking in de organisatie, user experience, usability en ga zo maar door, totaal geen aandacht hebben gekregen – maar de toepassing ’staat’ er wel.
Open Source is niet gratis.
Ik zou graag eens met enkele kopjes willen samen zitten om te kijken hoe de perceptie van Open Source kan worden bijgestuurd, want daar is echt noodzaak naar.
Een oproep dus.
oktober 10th, 2009 @ 1:10
Interessant en grotendeels waar.
Maar… Een belangrijk argument los van de kostprijs om voor een open source standaard pakket te kiezen is toch ook dat er minder “lock-in” is: je bent minder afhankelijk van de webbouwer als je in de toekomst wat aan je site wilt veranderen bij een andere webbouwer?
Akkoord?
oktober 10th, 2009 @ 1:14
Staat recht en applaudiseert…. Volkomen met akkoord, had iedereen maar dit inzicht!
oktober 10th, 2009 @ 1:50
Echt gebalanceerd is dit verhaal niet. Het is waar dat met de groei van populariteit van open-source paketten sommige mensen de handleiding lezen en zich meteen een expert noemen. Deze mensen hebben echter vaak referenties noch portofolio. Het is dan aan de klant van zich voldoende te informeren en een juiste keuze te maken.
Evenzeer is het zo dat bedrijven met een gesloten custom pakket ook vaak prutsers zijn. Het probleem daarmee is dat je dat vaak pas merkt als het te laat is.
Je hebt dus competente en incompetente mensen in alle takken van de industrie.
Als je naar http://buytaert.net/tag/drupal-sites kijkt zie je dat heel wat grote bedrijven voor Drupal hebben geopteerd om hun site uit te bouwen. Wees er maar zeker van dat zij een degelijke analyse van de verschillende oplossingen gedaan hebben en om goede redenen uiteindelijk voor Drupal gekozen hebben.
oktober 10th, 2009 @ 2:02
Ik vind uw argumentatie pover, en ze loopt mank.
Wat meer is, er zitten een hoop drogredenen in.
Mijn gedacht.
Ten eerste kan elk project onvoorziene kosten met zich meebrengen. Of je met Drupal werkt of custom code aflevert, de klant loopt altijd het risico op extra ontwikkelingskosten. Dat is absoluut geen situatie die je enkel voor kan hebben bij het gebruik van open-source CMS’en.
Een systeem dat bestaat uit losse componenten kan inderdaad risico’s met zich meebrengen. Maar die risico’s worden zwaar geminimaliseerd door met goede programmeurs en verantwoordelijke dienstverleners te werken. Opnieuw is dat een algemene stelregel die geldt voor alle webontwikkeling, en niet enkel voor Drupal. Als je de buurjongen 1000 euro betaalt voor je website, dan hoef je in geen geval een deftig resultaat te verwachten. Alleen gaat ie misschien met Drupal een stuk verder geraken.
Ik vind het ironisch dat je een systeem dat bestaat uit “losse componenten” als een nadeel van een open source CMS als Drupal beschouwd. Ik heb geleerd dat goede code bestaat uit losse componenten die swapable, pluggable, kortom inruilbaar zijn. Een systeem dat bestaat uit een gigantisch kluwen code dat niet uit elkaar te houden valt, lijkt me meer op “bad coding practice” te wijzen dan het tegendeel.
Ik beweer niet dat je de producent van dat soort code bent, ik ken je niet eens persoonlijk, maar je leidt uit de “losse componenten” propositie een hoop consequenties af waartussen geen rechtstreeks verband bestaat. Uiteraard kan overmatig gebruik van plugins (in Drupal noemt men dit trouwens modules, maar soit) tot een oncontroleerbaar project leiden. Maar dan heb je jezelf gewoon een slechte ontwikkelaar cadeau gedaan, niets meer en niets minder.
You get what you pay for. Niet?
Boodschap is dus niet te gaan concurreren met je buurjongen. Ook niet als Drupal-ontwikkelaar. Een klant die enkel naar de prijs kijkt, en niet naar de kwaliteit van het product dat uiteindelijk ontstaat, daar wil je toch niet in concurrentie voor treden? Of wel? Dus wat is dan het probleem met een buurjongen die na zijn schooluren in Drupal ontwikkelt? Ik zie er alleszins geen graten in. Integendeel, misschien wordt ie van al de muren waar ie als hobbyist tegenloopt ooit misschien wel een goede Drupal-ontwikkelaar?
De buurjongen zit niet met een probleem. De klant misschien wel, maar die had maar naar een goede ontwikkelaar moeten stappen en een deftige prijs voor zijn waar moeten betalen. Daar hoef je geen traan voor te laten…
De enige reden waarom je je opwindt in hobbyisten-buurjongens die jouw markt komen verstoren is klaarblijkelijk omdat ze op middellange termijn concurrentieel blijken met bepaalde marktsegmenten. Dàt zegt veel over Drupal. Die buurjongens staan op de schouders van reuzen. Jij mag dat wereldschokkend vinden, maar ik vind dat niet eens zo erg. Jouw buurjongen lijkt me een slimme kerel. En als zijn klant tevreden is, dan lijkt het me dat de klant ook een goede zaak heeft gedaan.
De wereld veranderd. Leer ermee leven, zou ik denken.
oktober 10th, 2009 @ 3:50
Ik ga akkoord met wat Olivier Jacquet en Jan Heynen zeggen. Het probleem ligt hem helemaal niet bij het concept open of closed source, maar wel bij de leveranciers van de software en (vooral?) ook bij de (onwetendheid van de) klanten.
Ik weet dat jouw blogpost vooral (terechte) ventilatie is, maar de argumenten die je aanhaalt houden niet allemaal even veel steek. Zelf gebruiken jullie bij Marlon ook 3rd party plug-ins. Cfr op http://www.marlon.be/projecten/website-metrix/ de plug-in van Software AG. Als Software AG ermee ophoudt, dan moeten jullie ook aan de slag…
Je gaat er ook van uit dat de maintenance van een opgeleverd systeem door de ontwikkelaars ervan gebeurt, en dat is op termijn een utopie. En closed of open source software, de maintenance mensen gaan zich toch eerst enkele weken of maanden moeten inwerken.
De sleutel zit hem in goed ontwerp van de software (ik heb het dus niet over de UI), en een goede communicatie van hoe dat ontwerp in mekaar zit (en beide zijn niet evident en al zeker niet goedkoop).
oktober 10th, 2009 @ 4:10
Alvast bedankt voor jullie reacties, dit was uiteindelijk ook de bedoeling!
@Kristof: Jouw argument in verband met de “lock-in” vind ik terecht zolang het project binnen de grenzen van een standaard installatie van het pakket valt. Van zodra je plugins van derden gaat installeren en gebruiken is er voor een nieuwe partij in het verhaal niet veel verschil meer tov de volledig op maat gemaakte code van een webbouwer.
@Olivier: Het is absoluut waar dat er veel bedrijven zijn die incompetent zijn en zodoende custom systemen aanbieden die de vooropgestelde doelen niet bereiken. Maar zoals je zelf zegt heb je dat soort personen overal. Volgens mij is het echter zo dat er meer Drupal prutsers zijn die ooit ex-custom CMS bouwers waren. Programmeurs die er niet niet slaagden zelf een CMS te bouwen en het dan maar over een andere boeg gooiden. Zelfs de grootste prutser beseft op een bepaald moment dat hij aan het prutsen is. Alleen kom je met gepruts in Drupal verder dan zonder Drupal.
Zelfs kom ik dankzij mijn job in contact met grote klanten als het gaat om webprojecten in België. Je zou nog verschieten over hoe weinig kwalitatief de gemiddelde analyses zijn bij aanvang van een nieuw project. Vaak zijn die gebaseerd op de “verkoopsfolders” van bijvoorbeeld een Drupal en een Magento. Als zo’n klant u benadert met een lijst van alle functionaliteiten heb je je argumentatie over jouw eigen custom CMS maar beter voorbereid of je hangt. En meestal krijg je maar één kans. Veel van die zogenaamde Multimedia directors en Interactive directors zijn enkel geïnteresseerd in “Wat” het systeem kan, niet “Wat als” er aanpassingen of uitbreidingen op het standaard systeem moeten gebeuren…
De voorbeelden die je aangeeft op bijvoorbeeld http://buytaert.net/tag/drupal-sites zijn meestal ook enkel eenvoudige content-sites. Het is niet omdat bijvoorbeeld de naam van CNN bovenaan pronkt dat het gaat om een complex en uitdagend project.
@Jan: Modulair design is absoluut een must in een hedendaagse webapplicatie. Ik beweer dus helemaal niet dat een systeem dat uit losse componenten bestaat een slecht systeem is, integendeel.
Wat ik echter wel beweer is dat je om problemen vraagt wanneer je losse componenten uit de componenten-visvijver gaat vissen die worden geproduceerd door mensen die geen kwaliteit kunnen garanderen. Je hangt de ene zwarte doos bij de andere en verwacht dan dat je “modulair” systeem de klus wel zal klaren. Met je argument dat je jezelf dan een slechte ontwikkelaar cadeau hebt gedaan verschuif je de verantwoordelijkheid naar de klant en dat is nu net het probleem dat ik met dit artikel wou illustreren: het is aan de webbedrijven om op een ethische manier tewerk te gaan en geen dingen te beloven die ze niet kunnen waarmaken.
Ik wil ook absoluut niet gaan concurreren met mijn buurjongen. Daarom ook mijn voorbeeld dat voor de gemiddelde zelfstandige een Drupal website perfect aan de noden zal voldoen. Jouw opmerking dat Drupal projecten op middellange termijn stilaan concurrentieel blijken in bepaalde marktsegmenten baart me inderdaad (en terecht) zorgen. Dit opent perspectieven voor webbedrijven die niet over de know-how beschikken maar toch dankzij het doorslaggevende argument “prijs” een op maat gemaakt systeem gaan verdringen in een pitch.
Begrijp mij dus niet verkeerd, Drupal is een goed systeem, maar dan moet het ook goed gebruikt worden.
Persoonlijk, en dan is dit vanuit technisch oogpunt, ben ik ervan overtuigd dat de kwaliteit van de programmacode van Drupal in het niets verdwijnt tegenover de kwaliteit van een op maat gemaakt systeem. Ik kan vanuit dit perspectief uiteraard enkel oordelen vanuit ons eigen CMS-systeem.
@Steven: Op de website van Metrix wordt een externe service gebruikt, dat is volgens mij niet iets helemaal anders dan een plugin. Als bijvoorbeeld voor het Metrix project de groep Software AG ophoudt, dan heeft de hele website geen nut meer. In dit geval verhoudt een service zich dus helemaal anders ten opzichte van een plugin.
Ik ga volledig akkoord dat de sleutel te vinden is in een goed ontwerp en goede documentatie. Persoonlijk vind ik echter niet dat deze filosofie ervoor mag zorgen dat iedereen uiteindelijk met eenzelfde systeem gaat werken want dan is het plezier er ook snel af…
oktober 10th, 2009 @ 4:11
Steven, Jan, Olivier: uiteraard hebben jullie gelijk. Het is niet omdat het OS is dat het slecht is.
Maar dat is niet het punt van Dieter (zoals ik het begrijp).
Sommige klanten kiezen voor OS als Drupal of Magento in de veronderstelling dat er géén maatwerk van een ontwikkelaar nodig is.
En dat is een illusie.
Van zodra je maatwerk vraagt, is het onderscheid tussen open source of proprietaire software minder belangrijk dan het onderscheid tussen een goede en een slechte developer.
En ben je dat illusionaire voordeel van OS kwijt.
Iemand die bewust voor OS kiest, en beseft dat ook daar het nodige maatwerk nodig is: prima.
Iemand die voor OS kiest in de veronderstelling dat alles ‘vanzelf’ zal gaan: het onderwerp van deze post, en van de frustratie van vele developers.
oktober 10th, 2009 @ 5:11
(Eigenlijk heb ik geen zin om mij op een zaterdag druk te maken over dit onderwerp maar soit…)
Zoals Bart al aangeeft is de kern van de hele zaak niet “open source vs closed source” maar “maatwerk vs out-of-the-box”. (Dit geldt trouwens niet enkel voor websites maar voor elke software project.)
Of er nu uiteindelijk open source gebruikt wordt of niet is eigenlijk irrelevant. Al is het waarschijnlijk zo dat cowboys eerder open-source zullen gebruiken omdat de ze daarvoor zelf geen investering moeten doen. Maar daaruit afleiden dat open source per definitie een out-of-the-box oplossing oplevert is niet correct. Da’s je reinste FUD.
Elke goeie oplossing is maatwerk. Ik herhaal: ELKE goeie oplossing is maatwerk.
Dat gezegd zijnde heb ik zelf (en een meer en meer klanten) een sterke voorkeur voor open source om verschillende redenen. De belangrijkste reden is waarschijnlijk de onafhankelijkheid van de leverancier. In het geval van Drupal kan je bvb makkelijker je leverancier buitengooien en iemand anders zoeken met Drupal kennis. Als je werkt met OurGreatCMS dat enkel door jouw leverancier gekend is dan wordt het moeilijker om weg te gaan (door de ‘vendor lock-in’).
oktober 10th, 2009 @ 5:25
Ik heb de meeste commentaren gelezen.
Wat de klant niet zal begrijpen is dat hij moet kiezen tussen 2 “kampen”. Uiteindelijk wil de klant een professional (=webbouwer) die zijn noden invult.
En als de bakker vandaag perfect gesteld is met een Drupal maar morgen misschien beter op maatwerk overstapt, waarom zou je hem als professionele webbouwer dan dit advies niet meegeven?
Of je dan wel of niet je neus ophaalt om ook die Drupal oplossing te leveren moet je zelf maar weten.
Door als professionele webbouwer het volledige gamma van oplossingen aan te bieden zou je alleszins een streepje voor hebben op de “1-click install” concurrentie.
oktober 10th, 2009 @ 5:30
Dieter: “Je zou nog verschieten over hoe weinig kwalitatief de gemiddelde analyses zijn bij aanvang van een nieuw project.”
Een goede analyse schrijven is moeilijk. Zeker als je de business niet kent. Het is naar verluidt beter/efficiënter van de klant aan te leren hoe je goede requirements schrijft, dan een programmeur erop te zetten (want die “spreekt” te technisch)…
(en dan ga ik er van uit dat de klant zijn business kent, wat niet altijd het geval is)
(Geheel terzijde:) Een probleem dat ik vaak tegen kom, is dat programmeurs neerkijken op analyses. “Da’s allemaal niet nodig, ik programmeer dat zonder analyse ook wel hoor” e.d.
Bart & Dieter: ik snap je punt (nu), maar het komt/kwam over als “open source is slecht en evil” terwijl het probleem eigenlijk bij de perceptie door jullie klanten ligt.
oktober 10th, 2009 @ 8:35
@litrik: da’s eigenlijk nog zo’n andere illusie waar ik heel hard tegen wil vechten – namelijk dat voor een open source oplossing kiezen automatisch betekent dat je ‘leveranciers-onafhankelijk’ wordt.
Dat is even hard FUD vanuit het open source kamp.
Als elke goede oplossing maatwerk vereist (wat je zelf aangeeft), betekent dit in mijn ogen sowieso dat een nieuwe leverancier zich zal moeten inwerken in het maatwerk van de oude leverancier.
Of dit nu in Drupal gemaakt is of niet.
Het enige wat telt is: is het oude maatwerk door de oude leverancier volgens de juiste standaarden en met de nodige kwaliteit (documentatie, inline commenting, afspraken volgend, volgens de code best practices…) gemaakt.
Opnieuw: os of proprietair, maakt niet uit. Het enige wat telt is de kwaliteit van de developer.
Als makers van proprietaire systemen constant door het os-kamp aangevallen worden met de beschuldiging van FUD, dan kijken die os’ers beter zelf eerst eens in de spiegel.
De argumenten die ik van os’ers hoor om voor os te kiezen zijn te vaak ‘proprietair is lock-in, proprietair is niet out-of-the-box, proprietair is duur’.
oktober 11th, 2009 @ 3:58
Interessante discussie. Ideaal voor een zaterdagnacht zou ik zeggen.
Zoals steeds in discussies zie ik ook hier weer dat iedereen eigenlijk hetzelfde aan het vertellen is. Met name: Kwaliteit komt met een prijs. Of dat nu Open Source of Closed Source is; Modulair of Monolytisch; Old school of New School.
En zoals als steeds: Veralgemening zijn het grootste kwaad in eender welke discussie.
D’er is geen “One Shoe fits All” CMS/Framework. Soms is het beter/goedkoper/handige om Joomla te gebruiken, op andere momenten gebruik je beter Drupal, en in andere gevallen is het echt wel beter om een volledig vanaf scratch te beginnen (hopelijk met een goed applicatie framework).
We hebben onlangs twee situaties meegemaakt. Eentje waar een backend management systeem diende herbouwd te worden. Daar hebben we na een objectieve analyse uiteindelijk besloten om de ontwikkeling niet in Drupal te doen, en de klant een alternatief aan te bieden door door te verwijzen naar een andere service provider (closed source).
Een ander geval waar de extra vereisten bovenop een zoekengine zo stevig waren dat de voordelen van het gebruik van de lage kost van Drupal’s Apache Solr Search engine, volledig teniet zouden worden gedaan door extra veel tweaking achteraf. We hebben de klant weerom geadviseerd om voor een volledig custom oplossing te gaan. Hier was de klant echter zo overtuigd van de voordelen van het CMS dat hij enkele bottleneck vereisten heeft omgevormd met een minimaal budget toch een stevige drupal oplossing te krijgen.
Ik heb wel wat last met de stelling dat Drupal enkel zijn nut kan bewijzen voor het bouwen van brochure sites. Laat dat nu net hetgeen zijn waar ik Drupal liever NIET voor gebruik. Gewoonweg omdat de opstart kost te groot is, en de voordelen te miniem.
En dan de laatste opmerking.
Ik treed de stelling van Bart enigzins bij. Het is een gedeeltelijk misvatting om te denken dat het gebruik van Open Source je als klant vrijwaart van Vendor Lock-in. Immers de partij die de extra custom code en de glue code (om bestaande modules nog beter te laten samenwerken), is ook best geplaatst om toekomstige wijzigingen aan te brengen, maar het is WEL (althans in het mijn bedrijf) mogelijk om uiteindelijk met alle code naar een andere partij te stappen. Ik weet niet of dit altijd kan/mag met closed source.
Is het correct om te stellen dat het gebruik van een closed source CMS een garantie is op vendor lock-in, terwijl het gebruik van OS CMS tenminste nog een grote deur open laat om van vendor te wisselen.
BTW. Vendor Lock-in hoeft op zich ook geen slechte zaak te zijn. Als de klant tevreden is, en de vendor levert goeie kwaliteit af, dan is Closed-source vs. Open Source in deze een non-issue.
De belangrijste reden waarom ik momenteel liever OS producten/libraries/CMS’s gebruik is
“Veel ogen zien meer”.
Méér developers geeft meer kans op GOEIE developers. (en ook op slechte developers, maar diens bijdragen wordt normaliter weggefilterd door de community)
Méér testers geeft meer kans op ontdekken van bugs en security problemen.
Conclusie. De argumenten die in de OS vs. Proprietary worden gebruikt zijn volgens mij dikwijls misplaatst.
* Open Source is NIET gratis, en Proprietary hoeft niet duur te zijn.
* Vendor lockin is altijd (gedeeltelijk) aanwezig zodra er een aanzienlijke hoeveelheid custom code wordt geschreven.
* Kwaliteit van eender welke oplossing wordt niet bepaald door closed dan wel open source zijn, maar wel door de kwaliteit van de ontwikkelaars.
* Wat niet ontkent kan worden is dat de afzetmarkt voor Open Source oplossingen veel groter is, maw Meer testers en kans op meer goeie ontwikkelaars
* Wat ook niet ontkent kan worden is dat leveranciers van Closed Source hun eigen oplossing door en door kennen en dus ook heel adequaat kunnen reageren op vragen van hun klanten. (maar dit geldt ook wel een beetje voor de betere OS leveranciers).
oktober 11th, 2009 @ 11:23
@Bart
“Als elke goede oplossing maatwerk vereist (wat je zelf aangeeft), betekent dit in mijn ogen sowieso dat een nieuwe leverancier zich zal moeten inwerken in het maatwerk van de oude leverancier.”
Dit argument klopt op voorwaarde dat de klant effectief toegang heeft tot de source code en (bijkomend) het recht heeft om verder te werken vanaf die source code. Mag hij bvb die source code doorgeven aan een derde partij zodat die verdere uitbreidingen/onderhoud kan doen?
Hoe zit dat bij jullie CMS? Krijgen klanten de source? Laat jullie licentie toe dat zij een copy van hun installtie aan een derde geven om aanpassingen te laten doen?
PS: Het argument van “geen vendor-lockin met OS” is slechts één van de argumenten pro open source. Er zijn er nog een hoop andere (waarvan Roel er een aantal aanhaalt).
oktober 11th, 2009 @ 11:39
Om die vendor lock-in te voorkomen gaan we bij ons zelfs een stapje verder. Zie ook mijn presentatie op drupalcon : http://www.archive.org/details/AegirBuildOnceDeployoftenReallifeuse-cases
Voor klanten van een bepaalde grootte gebruik gebruik ik techniek: “How to loose your client, and make them feel good about it”.
Maw. We gaan zo ver dat we naast de Source Code, ook de tools en kennis ter beschikking stellen en een inhouse developer omscholen tot junior drupal developer. Op die manier kan de klant volledig in zijn eigen behoeften voorzien.
De klant kan dan uiteraard nog steeds terecht bij ons om ontwikkeling te doen die te hoog gegrepen is, of als de developer moeite heeft om bepaalde changes of upgrades door te voeren.
Achterliggende gedachte.
1# Een nieuwe drupal developer op de markt
2# Onze developers kunnen zich bezig houden met het bouwen, en iets minder met onderhoud
3# De klant voelt dat ze (bijna) volledig vrij zijn
4# Extra druk op mijn team om altijd goeie kwaliteit te leveren.
Of dit op termijn een goed business model is dat moet de tijd dan maar uitwijzen. ;)
oktober 11th, 2009 @ 1:38
Wie heeft er al een een project doorgegeven aan een compleet ander team? En gebruikte dat team toen de bestaande codebase of zijn ze opnieuw begonnen?
oktober 11th, 2009 @ 1:44
Graag de definities helder houden.
@litrik en @roel: uiteraard hebben jullie in veel punten gelijk, maar opnieuw projecteren jullie één visie op al de rest.
Ik spreek héél bewust van ‘proprietair’, en niet van closed source.
Ons werk is alles behalve closed source.
1. De basis code is gewoon open source (zie http://www.spoon-library.be ).
2. De code van ons CMS is voor onze klanten volledig toegankelijk, bekijkbaar. Als ze dat willen, geven we die code in escrow.
Meer zelfs, de licentie geeft expliciet het recht om aan de code te wijzigen, zelf of met hulp van derden developers of bureau’s.
(Er zijn 2 dingen die de licentie verbiedt:
- onze klanten mogen ons niet verbieden met diezelfde code verder te werken, de code blijft maw ons eigendom
- onze klanten mogen zelf geen commerciële exploitatie van het cms voeren, ze mogen maw niet zelf nieuwe websites met ons cms verkopen)
Ik blijf het herhalen: gelieve geen valse argumenten te gebruiken.
We kunnen uiteraard over een paar basispunten van mening verschillen.
* Ik geloof niet in de -aanhoudende- kwaliteit en continuïteit van de meeste open source omgevingen. Ik blijf ervan overtuigd dat een kwaliteitsvol toegewijd team betere resultaten zal leveren dan het principe “meer developers maakt een beter product”.
* Ik geloof dat vendor lock-in automatisch gebeurd van zodra je maatwerk vraagt, onafhankelijk van proprietair of open source. (Maar dat hebben jullie al bevestigd.)
Bovendien geloof ik dat elke goede website maatwerk vraagt.
* Ik denk ook dat er vaak voor open source gekozen wordt vanuit de illusie dat alle toekomstige uitbreidingen en upgrades automatisch/makkelijk/gratis zullen toegepast worden, en dat dit niet meer is dan hoe ik het noem – een illusie.
oktober 11th, 2009 @ 1:52
@Wolf Wij hebben een eerder ontwikkeld ecommerce project doorgegeven aan onze collega’s bij Inventis; de code wordt waarschijnlijk herschreven. Verantwoord want de code heeft een opknapbeurt – lees betere codering – nodig en de klant is zich daar van bewust.
@all Deze discussie is op 1 en 2 oktober in Paris op het Open World Forum ook opgelaaid. De oproep daar en die doe ik hier ook graag nog eens was dat we als developpers de klant moeten opvoeden als het gaat om de perceptie van Open Source en de Vendor Lock-In. @roel goeie samenvatting van de visie op Open Source.
@all 2 Samenwerken is de boodschap voor bedrijven die in de toekomst actief zullen zijn in deze sector (en andere trouwens ook).
oktober 11th, 2009 @ 2:28
Drupal aanhalen als software voor hobby projectjes en kleine zelfstandigen is best wel grappig als je de enorme lijst referenties met complexe en -inderdaad- serieus custom ontwikkelde sites ziet. Ik noem er maar enkele in België stubru.be, rtbf.be, cdenv.be, mnm.be, uitinvlaanderen.be, premier.be
Wat Bart zijn opmerking over custom code en upgraden betreft: GOEDE custom code is normaal niet moeilijk te upgraden. Ik heb echter ook al Drupal templates en modules gezien die zo slecht ontwikkeld waren (business logica en SQL in template bv) dat het zelfs goedkoper was om ze opnieuw te ontwikkelen dan te proberen upgraden. In dat opzicht is het even makkelijk om crap te maken met open source of zonder. Ik zorg zelf liever voor kwaliteit, ook al heeft dit een iets hogere prijs.
Als iemand liever met zijn eigen systeem werkt en denkt dat dit beter is dan de rest, waarom niet. Je moet je concurrenten niet overtuigen, enkel de klant en de rest doet er niet toe. :-)
De voorwaarden van bv Netlash lijken mij vrij redelijk en veilig voor de toekomst. Er zijn er echter anderen… Ik heb zelf vooral een groot probleem met leveranciers van proprietaire systemen die hun klant compleet vast zetten omdat hun systeem alleen op hun eigen infrastructuur mag draaien, je geen code krijgt en dus voor de rest van je leven met handen en voeten gebonden zit aan de leverancier. Ze maken een lage startprijs en melken de klant daarna uit met hosting en onderhoud…
Voor de rest is het allemaal, zoals onze Hollandse vrienden zeggen, “Daarom adviseren wij van WC-eend, WC-eend!”
oktober 11th, 2009 @ 2:30
Mijn visie op OS voor websites:
De toekomst van een website(platform) hangt af van de mate waarin een team achter z’n gekozen oplossing staat en blijft staan.
Een gemotiveerd team zorgt zelf voor z’n toekomstige uitbreidingen/upgrades, onafhankelijk als dit inhouse ontwikkeld werd en/of als daar ook een community achter zal blijven staan.
Naarmate de OS platformen en daarvoor bestaande uitbreidingen in de toekomst alleen maar flexibeler worden, zal de basis alleen maar gemakkelijker worden.
Wat er met die basis gedaan wordt hangt volledig af van van de ontwikkelaar, in mijn ogen is de klant dus voor het kiezen van deze ontwikkelaar jammer genoeg volledig zelf verantwoordelijk.
Er is al een kwaliteitslabel om tegen semi-professionele ontwikkelaars op te boksen – meer zal er in de nabije toekomst niet aan gedaan worden vermoed ik.
Waar teams zich in onderscheiden is de afwerking, en dit staat los van het gebruikte raamwerk maar is rechtstreeks gekoppeld aan de kwaliteit die een team aflevert (wat overigens al aan bod is gekomen).
In mijn ogen is het verschil tussen OS maatwerk en goed inhouse maatwerk (onder een andere licentie) de schaal. De rest hangt af van het team achter de website of het OS project.
De kwaliteit en de zwaktes van een OS project hangen trouwens af van de beheerder(s), ongeacht het aantal ontwikkelaars. Het staat iedereen vrij zijn eigen variant te maken en te releasen als je niet akkoord bent met deze beheerder(s), wat jammer genoeg vaak gebeurt.
oktober 11th, 2009 @ 2:49
Vind dit weer zo een typische onzinnige discussie hé. Iedereen heeft een beetje gelijk en er is geen absolute waarheid. (ik heb ze ook niet hoor)
De enige waarheid is dat onze klant een oplossing wil voor zijn probleem en wij moeten dat zo goed mogelijk doen. Desnoods in turbopascal of assembler.
Kiezen we altijd voor de beste oplossing ? neen. Er zijn zoveel factoren (tijd,schaalbaarheid, budget, klant, technologie voorkeur van de klant, politics enz.) die een impact hebben op de beslissing. En natuurlijk vertrek je vaak vanuit datgene wat je het best kent omdat het “makkelijker” is.
Het heilige huisje van maatwerk is altijd beter vind ik toch wel arrogant omdat je hiermee aangeeft dat je zonder twijfel beter bent dan een grote community van developers.
Is OS dan altijd beter ? Neen; Het dwingt je vaak binnen een keurslijf en geeft je minder vrijheid. Dus de vraag blijft “wat heeft de klant nodig om zijn doelstelling te behalen.
(over code spreek ik me niet uit omdat ik geen developer ben)
Bij nascom leverden we tot een jaar of 2 geleden ook enkel maatwerk. Dit is nu niet meer efficient om enkele deze kaart te trekken. Omdat er zoveel goede oplossingen op de markt zijn. Drupal ea zijn het stadium van de bakker allang voorbij en vergeet het maar dat dit out-of-the box is en geen development meer vereist.
Het past allemaal in ons streven naar meer efficientie en vooruitgang. Je kan telkens het wiel heruitvinden en van nul starten (wat niemand echt doet, dus puur maatwerk bestaat niet), je eigen module-library opbouwen, Je eigen CMS maken, starten van een open-source pakket etc… Geen is beter of slechter dan de andere. Het is een keuze. En tijd zal uitwijzen wat het beste is/was. (heb gene glazen bol)
ik vrees wel dat diegenen die enkel nog maatwerk propaganderen in de doelgroep van de slagers doelgroep terecht zullen komen. Je kan het gewoon nooit halen van de community van developers die wereldwijd samen werken aan vernieuwing.
Ivm kwaliteit, Maatwerk garandeert ook geen betere kwaliteit hé. Kwaliteit is het samen gaan van een goede analyse, design, IA, goede developers, kennis en tijd en budget. Niet OS vs maatwerk. We hebben bij nascom al geregeld rotzooi opgekuist van ondermaats maatwerk verkocht tegen een belachelijk lage prijs.
En dit is voor mij de grootste problematiek nu. Prijs is precies het enige criterium geworden en kwaliteit secundair. En ik denk dat iedereen in de sector het moeilijk gaat krijgen om kwaliteit te garanderen met de beschikbare budgetten.
En wat zeg je dan eigenlijk van site die tridion en ea mastodonten van CMS’en draaien die op zich ook op ne drupal zouden kunnen draaien ? Dit vind ikzelf dan veel erger. Waste of money !
Mijn gedacht op dit moment is maatwerk voor zeer specifieke problematieken, OS voor de rest.
My 2 cents ;-)
oktober 11th, 2009 @ 4:26
Of je nu een eigen gebouwd dan wel open-source cms gebruikt, speelt weinig rol. Welk van de twee het beste is, lijkt me meer een uitgangspunt. En dit is waarschijnlijk nog afhankelijk van de klant of het project.
Hoewel ik de drijfveren van de schrijver snap, (zelfverklaarde experts zijn er idd genoeg), wil ik toch nuanceren dat open-source soft vaak snel groeit door de community, veel beter getest is door een grote community etc. etc.. en dus zeker niet hoeft onder te doen voor custom-made.
Daarbij, met plugins en andere stukken custom code bouwen experts wel degelijk verder op de bestaande core. Out-of-the-box heb je meestal toch niets interessants. En je moet de front-end ook nog bouwen, dat wordt in deze discussie nog vergeten.
“Mijn gedacht op dit moment is maatwerk voor zeer specifieke problematieken, OS voor de rest. ” lijkt me ook een goede samenvatting van mijn opinie hierover.
T.
oktober 11th, 2009 @ 7:55
De stellingen in het artikel zijn allemaal irrelvant, sommige onzinnig, andere scheef, of zelfs onjuit.
Irrelevant, want het gáát helemaal niet om de licentie waarmee iets is vrijgegeven.
Een licentie voegt wat extra’s toe, of zal op zijn hoogst voor een andere werkwijze zorgen. Maar is nooit meer dan gewoon de licentie.
Closed source projecten, maatwerk, Open Source projecten, plugins, modules: ik heb van allemaal voorbeelden waar ik bijna van moest huilen zo slecht waren ze. Recent nog een door een gerenommeerd bureu gebouwd systeem achter een Flash-spelletje: het send-a-friend deel, in PHP, bevatte in haar luttele 60 regels maar liefst 7 kritieke beveiligingsgaten.
En laat bij dat specifieke voorbeeld de klant erg tevreden geweest zijn over dat resultaat.
Veel klanten meten “kwaliteit van het eindproduct” op vele niveaus. Technische perfectie, security is er daar slechts één van.
Maar ik ken ook Drupal plugins, waar met één blik veiligheidslekken zichtbaar werden. En ik ken stukken code in proprietaire CMSen die zó dom geprogrammeerd waren, dat mijn kat die over mijn toetsenbord loopt nog beter werk levert.
In alle gevallen was de klant redelijk tevreden. Of heel tevreden.
Ik ken echter ook heel net gebouwde, strak gearchitectureerd, netjes MVC, keurig gedocumenteerd enzovoort projecten (open én gesloten) waar de klant over het eindproduct niet te spreken was. Soms omdat (communicatie!) het eenvoudig niet was wat ze voor ogen hadden. Soms omdat het design gewoon lelijk uitgevoerd was enzovoort.
Tevreden klanten, goede projecten hebben geen ene moer met de licentie te maken. En alles met kwaliteit op alle gebied van het bouwen van een site. Dat geld voor de bakker. Dat geld voor de VRT.
Als je wilt aantonen dat Open source slechtere projecten oplevert, dan moet dat onderbouwd worden. Met doorlooptijden, onderhoudskosten, urenstaten en behaald eindresultaat (op velerlei vlakken, niet enkel technisch). En moet dat niet aangetoond worden door een fictieve zolderkamerprogrammeur als “Open Source” op te voeren en een deftig ontwikkelteam de naam “Proprietair” te geven. Want met een eenvoudige zoek-vervang actie is uw bovenstaande artikel precies even waar, maar staat daar het “bewijs” dat open source betere projecten levert.
oktober 11th, 2009 @ 8:24
@Bèr: Vindt u consistentie belangrijk? http://webschuur.com/publications/blogs/2009-08-04-reply_on_quotdrupal_is_shitquot_by
oktober 11th, 2009 @ 8:25
@Bèr: wat natuurlijk exact mijn punt is.
Ik wil niet zeggen dat open source slechter is dan proprietair.
Ik wil dat men stopt met zeggen dat proprietair slechter is dan open source.
oktober 11th, 2009 @ 9:45
Robby Remmerie, you’re the man.
^^
oktober 12th, 2009 @ 9:35
Als hoster kan ik je zeggen dat het NIET ligt aan de keuze van het CMS, sorry Dieter. Ik snap je frustratie en een stuk van je redenering, maar je maakt een cruciale fout in mijn ogen door te stellen dat wie een custom “op maat” CMS maakt, een site aflevert waar de klant meer mee gediend is.
Helaas klopt dat niet. Er zijn ook “prutsers” die een zelf-gemaakt-volledig-op-maat-dat-eigenlijk-copy-paste-is CMS afleveren voor de klant, en helaas zijn dat degene waar wij als hosters het meest last mee hebben. Geef mij maar een goed opgezette Drupal over een slecht opgezet “custom” cms, any day!
De gebruikte tool is volgens mij irrelevant in vergelijking met de expertise van de webbouwer. En of die webbouwer dat nu doet met Magento, Drupal, een “eigen” (maar standaard) CMS of iets 100% op maat voor die klant, maar meestal weinig uit als de webbouwer genoeg “craftmanship” en expertise heeft. Omgekeerd is het wel zo, dat als een “pruts-webbouwer” een site bij ons host, ik liever heb dat ze iets open source en bestaand gebruiken, omdat daar dan meestal de security-problemen minder groot zijn.
Disclaimer: wij hosten *hele* grote B2B webshops die van scratch geschreven zijn, maar hosten ook hele grote Drupal sites.
oktober 12th, 2009 @ 9:53
Om eerlijk te zijn heb ik soms meer vertrouwen in een opensource project met een behoorlijke community dan een from-scratch geschreven applicatie van een (goedkope) webontwikkelaar. Daarmee wil ik niet zeggen dat alle Vlaamse webdevelopers slordige software afleveren, maar tijdsdruk en winstmaximalisatie kunnen wel dit effect hebben.
Bovendien heeft elke webontwikkelaar zijn interne libraries / frameworks die sowieso gebruikt worden. Het is dus zeker niet zo dat élke webshop aan élke klant aangepast wordt.
Maar dat heeft dan helemaal geen verschil met open source software: als een bedrijf weken development kan uitsparen door zijn applicaties te baseren op iets wat reeds bestaat en door honderden developers ondersteund wordt, lijkt me dat een plus voor die software! Zo kunnen twee bedrijven die zich baseren op Drupal gemakkelijk projecten uitwisselen.
Dat betekend niet dat iedereen die Drupal kan installeren ook zomaar webdeveloper moet worden! Het belangrijkste lijkt mij dat de webdev ook in staat is het resultaat dat de klant WIL kan leveren. Of dat nu een aangepaste versie van Drupal is, of een from scratch geschreven CMS: voor de klant maakt dat toch niet uit? Behalve dan een paar extra duiten in het zakje…
En als je schrijft dat “plugins een negatief effect hebben op upgradebaarheid” weet ik niet of ik jou zou inhuren… Het lijkt me juist dat een goedgeschreven plugin véél meer waard is dan een aangepaste core. (Voorwaarde is dan natuurlijk dat de plugin en het plugin framework deftig geschreven zijn.)
Liever een Drupal met wat op maat afgwerkte plugins dan een custom CMS die crasht als je Hélène intikt.
oktober 13th, 2009 @ 4:19
De hele fine fleur van web-ondernemerschap heeft ondertussen zijn onbetaalbare mening over dit hete hangijzer geventileerd (inclusief obligate dt-fouten), laat me dan maar toe mijn twee cent bij te dragen.
Als de kwestie gaat tussen goeie en slechte developers: “a fool with a tool is still a fool”. En volgens Marc Portier zelfs “a dangerous fool”.
Ja, een slechte developer aan de slag laten gaan met Drupal zal ongetwijfeld desastreuze gevolgen hebben, de klant zal niet tevreden zijn, en wie dit project overneemt zal best from scratch herbeginnen – met of zonder Drupal. Dit is eigen ondervinding.
Wie dit project overneemt, zal veel moeite hebben om aan die klant uit te leggen dat het niet aan Drupal lag, maar aan die developer.
Een goede developer kan ook nog foute keuzes maken, en een allegaartje aan community modules kiezen zonder deze grondig te reviewen & samen te testen. Again, project kan hierdoor schade oplopen.
Ik zie het als de verantwoordelijkheid van elke “goede” developer om al het materiaal wat in een project samengebracht wordt – CMS, contrib modules & eigen modules – kwalitatief te testen.
En ik ben het volledig eens met roel: meer ogen zien meer. Technisch gezien zal de eigen module misschien beter onder controle zijn, functioneel gezien zal die meestal armer zijn, want dient maar één doel.
Ik vind Open Source een schitterend model; niet telkens opnieuw het wiel uitvinden, maar gelijkgestemde personen laten samenwerken ter voordeel van ieder.
oktober 24th, 2009 @ 12:44
Uit ervaring weet ik dat prijs bijna nooit het echte probleem is. 95% van de keren dat iemand je product of dienst te duur vindt, is het omdat hij niet inziet waarom hij er beter van wordt.
Jouw job als professionele manager is om je te trainen om te concurreren, voet bij stuk te houden en de business binnen te halen… op andere dingen dan prijs. Train je om klanten tevreden te houden onafhankelijk van de prijs omdat je bedrijf iets biedt wat de klant zal moeten opgeven als hij of zij enkel op prijs koopt.
Karen Massin
november 9th, 2009 @ 6:48
Use the right tools and the right people for the right job.
En Drupal is juist niet geschikt voor de voorbeelden uit het artikel. Wanneer de buurjongen ermee aan de slag gaat zal er namelijk geen bevredigend resultaat uit komen (tenzij de buurjongen een drupal-ninja is).
Het systeem blinkt pas uit wanneer je het als framework gebruikt en er een CMS op maat mee bouwt.
november 10th, 2009 @ 3:56
Voor al die Drupal lovers ^^
http://www.slate.com/id/2233719/