Na diverse gemeentes, lijkt nu ook de Tweede Kamer Drupal te gaan gebruiken om de sites mee te bouwen. Het goede nieuws is dat diverse overheden zich hiermee weten los te breken uit de contracten en licenties van enkele grote ICT aanbieders, door Open Source een plek te geven in hun ICT-beleid. Het minder goede nieuws is, dat Drupal, als CMS, een slechte keuze is voor dit soort projecten. Er zijn veel geschiktere Open Source omgevingen om zulke grote web-projecten in uit te voeren dan "een CMS".

CMS of framework

Drupal is weliswaar een van de meest flexibele CMSen van dit moment, maar toch altijd nog een CMS. Om web-applicaties te bouwen, bestaat, naast dat CMS, ook het zogenaamde framework; een web-application framework is een platform, speciaal voor ontwikkelaars gemaakt, om web-applicaties mee te bouwen. Web-applicaties, zoals een op maat gemaakt CMS.

Frameworks zijn, in tegenstelling tot het CMS, niet gericht op eindgebruikers. Ze kennen bijvoorbeeld geen makkelijke 123-installatie, omdat dat voor grote projecten, met complexe serveromgevingen en moeilijke koppelingen, volledig irrelevant is. Maar ze kennen wél heel goed uitgedachte deployment-omgevingen en tools, iets wat voor een kleine site op een bulkhoster weer volledig irrelevant is. Het CMS en Frameworks zijn, kortom, twee heel verschillende gereedschappen voor verschillende soorten projecten.

Weghalen van basisfunctionaliteit

Een CMS heeft een duidelijk voordeel boven frameworks. Frameworks hebben weliswaar allerlei herbruikbare (standaard)functionaliteit voorhanden in de vorm van bibliotheken (zoals Jars, Packages of Gems), maar de ontwikkelaars moeten daarmee wel alles nog zelf bouwen. Vaak kost het tien, twintig uur bouwen, om te geraken waar een CMS al meteen na installatie is: user-management, permissies, (basis) artikelen beheren, bestandsbeheer enzovoort.

Maar dat drukt ook direct een duidelijke stempel op het project: vaak is het zeer nadelig, soms zelfs onmogelijk, om af te wijken van de kant-en-klare functionaliteit die met een CMS meekomt. In de Drupalwereld wordt daarom vaak gekscherend gezegd dat Drupal-development vooral bestaat uit "undoing of other stuff"; het ongedaan maken, of wijzigen van meegeleverde standaardfunctionaliteit. Het is daarom verstandig om al tijdens het ontwerptracé, Drupal, of eender welk CMS, goed te kennen en het ontwerp helemaal aan te passen aan de eigenschappen (of eigenaardigheden) van dat CMS. Dat scheelt tijd en geld; maar werkt ook heel beperkend. Andersom geredeneerd: een project dat het voordeel van het CMS gebruikt en enkel standaardfunctionaliteit levert, het maatwerk beperkt tot het absolute minimum, kan daarmee vanzelfsprekend nooit veel kosten: een basis Drupalsite opzetten kost uren, geen maanden.

De doelgroep van het CMS

Bovendien zijn frameworks helemaal geoptimaliseerd voor ontwikkelaars en -teams, iets wat bij een CMS als Drupal, juist niet het geval is: haar doelgroep is immers de eindgebruiker en niet de ontwikkelaar ervan. Voor een enkel, klein op maat te maken Drupal-moduletje, maakt het nauwelijks uit of de ontwikkelomgeving daarvan keurig object-georiënteerd is, met goed doordachte database-mapping, revisiebeheer, enzovoort. Voor grote projecten, waarvan het leeuwendeel juist bestaat uit ontwikkelen, is het echter wel van groot belang dat deployment, beheer en ontwikkeling efficiënt en goed doordacht zijn uitgewerkt.

Wanneer de kosten en uren van de initiële basisopzet slechts een fractie is van het totaal uitmaken, is het gebruik van kant-en-klare functionaliteit zelfs nadelig. Een project dat enkele tonnen euro's aan budget vraagt, alleen al om basisfunctionaliteit weg te halen en te vervangen voor maatwerk, is beter af met gereedschap dat die basisfunctionaliteit niet meelevert, maar juist overlaat aan de bouwer.

Het Open Source argument

Overigens betekent het gebruik van een framework, uiteraard, niet dat zo’n project niet Open Source is. De ontwikkelde bibliotheken, het resulterende (op maat gemaakte) CMS, of beiden, kunnen makkelijk Open Source zijn, terwijl het geleverde maatwerk voor een Drupalsite dat mogelijk weer niet mag zijn. Het is enkel de intentie van de opdrachtgever die uitmaakt of de (Open Source) gemeenschap wat van het werk terugziet, niet de gebruikte techniek.

Kortom: "The right tool, for the right job".