Nederlandse ontwikkelaars van open source cms-platform Drupal hebben zich verenigd in de stichting Drupal Bedrijven Nederland (SDBN). Samen maken ze een vuist tegen leveranciers van cms'en op basis van gesloten broncode.
De stichting Drupal Bedrijven Nederland (SDBN) bestaat uit concurrerende bedrijven die gezamenlijk het Nederlandse marktaandeel van het cms willen vergroten en een vuist maken tegen closed source cms’en. De website van de stichting moet een vraagbaak worden voor organisaties die leveranciersonafhankelijke informatie zoeken over het cms-platform.
‘De promotie van Drupal lag voorheen bij bedrijven die het cms implementeren. Het was tot voor kort niet goed mogelijk om onafhankelijk en als één gezicht naar buiten te treden’, vertelt secretaris Michel van Velde. ‘Commerciële partijen hebben flinke budgetten voor marketing, communicatie, pr en events. Wij kunnen ons nu ook via evenementen en showcases promoten. Het is niet de bedoeling dat deelnemers de stichting gebruiken ter promotie van hun eigen bedrijf. Er worden geen eigen bedrijfskaartjes uitgedeeld. Het gaat om het open source cms-platform’, legt de secretaris uit.
In april 2013 zijn vier Drupal-bedrijven de stichting gestart. ‘Inmiddels zijn er 26 deelnemers. Dat is een kwart van de ongeveer honderd Drupal-leveranciers die we in Nederland hebben’, vertelt Van Velde. Volgens hem zijn ook leveranciers uit België, Duitsland, Frankrijk, Denemarken en Spanje geïnteresseerd in het idee van de stichting.
2 procent
Volgens Van Velde zijn op dit moment ongeveer 2 procent van de wereldwijde websites gebouwd op basis van het Drupal-cms. ‘We verwachten dat dit de komende jaren fors gaat groeien. In de VS zijn vrijwel alle publieke websites overgestapt naar open source cms’en. Ook in België kiezen ze in de publieke sector voor open source.’ Andere leveranciers van open source cms’en zijn Hippo, Typo3 en Joomla.
Volgens Van Velde is Drupal niet te verwarren met een open source cms voor blogsites, zoals WordPress. ‘Onze toepassingen zijn uitgebreider en gericht op grote bedrijven. Het cms bevat veel meer functionaliteiten en is gericht op overheden middelgrote en grote bedrijven. Voorbeelden van closed-source concurrenten die Van Velde noemt, zijn Sitecore enTridion.
Gaat SDBN dan ook standaarden vastleggen waarin zij zich houden? Zodat je van de ene Drupal leverancier eenvoudig kunt overstappen naar de ander?
Open source is leuk, maar het concept “geen vendor-lockin” kan nog steeds praktisch van toepassing zijn als een bedrijf eea totaal afwijkend heeft opgezet. En een andere leverancier dagen moet verstoken om de spaghetti-code van de vorige leverancier moet doorgronden..
Juist Drupal is zo ontzettend flexibel dat er wel heel veel wegen naar Rome zijn, en het snel maatwerk wordt i.p.v. standaardpakket inrichten. Bij een standaardpakket speelt het probleem dat de stichting probeert op te lossen (geen informatie kunnen vinden over de implementatie) veel minder.
Standaard en maatwerk zijn nogal lastige begrippen in deze.
Klanten die vragen om bepaalde functionaliteit die niet voorhanden is, zullen altijd via programmeer maatwerk bedient moeten worden.
Daarnaast heeft Drupal ook heel veel modules die je op allerlei manieren kunt combineren, wat ook eigenlijk maatwerk is, maar geen programmeer werk vereist.
Beiden zijn niet andere routes dan bij andere (commerciele) CMS applicaties, en de enige manier om een goede overschakeling van leveranciers mogelijk te maken is of te kiezen voor een product dat heel weinig aanpassingsmogelijkheden heeft, of heel uitgebreide documentatie te vragen van je leverancier.
Dank voor je reactie @JW. Ik begrijp dat je mindere ervaringen hebt met Drupal migraties. Wil je daar wat van delen? Dat is nl. wel feedback die de open community van Drupal wel meeneemt.
Hoewel er veel out of the box mogelijk is, is minstens de helft van vrijwel ieder Drupal project maatwerk. Dat is niet zo erg, maar het wordt erg wanneer standaarden niet worden gerespecteerd en documentatie ontbreekt. Dat is meer een discipline kwestie die niet Drupal gebonden is; Die kom je al sinds jaar en dag, overal tegen in het IT landschap, ook bij Java, Sitecore, Tridion, iOS en andere omgevingen/projecten.
Wat ook meespeelt is de wensen van de klanten. Die willen innoveren en voorop lopen en nemen (al dan niet terecht) geen genoegen met out-of-the-box. Even verhuizen is er dan idd niet meer bij. Maar nog altijd sneller (en goedkoper) dan bij grote ‘enterprise’ systemen.
Ik stel klanten en leveranciers de vraag en daag uit eerlijk te antwoorden: Hoeveel kost een migratie? Sitecore, Tridion et al. zijn dure systemen met dure hosters en dure migraties. Ik geef het 1 sprint en dan draait de grootste (degelijk gemaakte) Drupal website van Nederland ergens anders. Dat lukt veelal niet voor hetzelfde geld met een ‘enterprise’ CMS. Je bent dan aan veel meer restricties (en licenties) gebonden.
Als ik me niet vergis zijn juist Hippo, Tridion en Sitecore géén opensource cms’en. Althans, als je de definitie aanhoudt dat je moet betalen om het te mogen gebruiken… Heeft de redactie misschien een andere definitie van opensource dan dat ik dat heb?
Verder heb ik het gevoel dat dit “nieuws-artikel” een verkapte reclame is voor SDBN, zonder dat er daadwerkelijk kritische vragen zijn gesteld. Als er nou bijvoorbeeld een korte vergelijking tussen Drupal en zijn concurrenten Joomla, Orchard, Typo3, Umbraco en hun populariteit bij bijvoorbeeld de overheid, dan hebben we het over een écht artikel…
Ben het met Jaco eens, mooie slogan “we schudden de markt op” maar waarom zou het inéénslaan en samenwerken de markt op schudden? Titel zou moeten zeggen “Concurrerende Drupal bedrijven gaan samenwerken om marktaandeel te vergroten”. Verder de paragraaf “2 procent”, wat is de bron? Ik lees juist dat ook veel bedrijven terugkomen van opensource.
@JW SDBN heeft niet de ambitie om een keurmerk te ontwikkelen voor Drupal bedrijven en hun manier van werken. Wel is er regelmatig overleg om zaken kwaliteit en het werken volgens de Drupal Coding Standards (https://drupal.org/coding-standards).
Bij de selectie van een Drupal implementatie partner is het van belang om duidelijke acceptatie criteria vast te stellen en na te gaan of er volgens conventies en standaarden gewerkt wordt. Door deze manier van werken voorkom je alsnog een lock-in en is wijzigen van aanbieder mogelijk. Ook als er niet volgens de standaarden is gewerkt is een transitie naar een andere aanbieder mogelijk. Wel zullen er dan afspraken moeten worden gemaakt over doorontwikkeling, SLA’s etc.
@TB @Jacco “We schudden de markt op is” inderdaad een redactionele krachtterm die voor discussie en zichtbaarheid zorgt. Doel is inderdaad dat we het marktaandeel willen vergroten door de handen in een te slaan. Dit doen we ondermeer door deelnames aan beurzen maar ook de Pers/PR activiteiten waarmee we de aandacht willen vestigen op het merk en CMS Drupal. Dat laatste is gelukt anders hadden we hier geen discussie gehad.
@jacco, een vergelijking tussen Joomla, Orchard, Typo3 en Drupal is zeker een interessant topic echter is hier al veel informatie over te vinden op het internet. Als SDBN een vergelijking zou publiceren zou dat het zelfde betekenen als “wij van wc eend adviseren wc eend”. Het is dan ook beter om dit door een onafhankelijke instantie te laten publiceren.
Er zijn zo 300 FOSS “CMSsen” waarbij de meest gebruikte zeker niet de beste is . . .
De “markt opschudden” met Drupal is zoiets als dagdromen. Drupal is goed, geen twijfel, maar ook relatief komplex. Het is ook niet alleen voor grote sites geschikt, kleinere kun je er ook mee maken.
Het grote probleem met alle CMSsen is het gebruik van modules (bij Drupal 24711 volgens de website), juist bij Drupal werken die van versie 6 bijv. niet of voorlopig niet op 7.
Onderstaand is een lijst van w3techs met de aktuele marktgegevens, daar vindt je nog steeds hoofdzakelijk FOSS.
Copyright © December 2013 W3Techs.com
rank cms usage marketshare
1. WordPress 20.8% 59.6%
2. Joomla 3.2% 9.2%
3. Drupal 1.9% 5.6%
4. Blogger 1.2% 3.3%
5. Magento 0.9% 2.6%
6. TYPO3 0.6% 1.6%
7. vBulletin 0.6% 1.6%
8. DataLife Engine 0.4% 1.3%
9. PrestaShop 0.4% 1.1%
10. Bitrix 0.3% 1.0%
Dat veel Open Source projecten door spaghetti-code en ‘forks’ niet transparant zijn en daardoor moeilijk te migreren is niet CMS specifiek is. Dat hierdoor de onderhoudskosten stijgen ligt zoals artikel al stelt ook niet zo zeer aan Open Source maar aan het loslaten van standaards, sommige projecten ontgroeien nooit de ‘hobby fase’.
Verder heb ik niet de indruk dat bedrijven weg migreren van Open Source maar vooral afscheid nemen van projecten die ‘wees’ geworden zijn door bijvoorbeeld verlies aan kennis. En dat is eigenlijk niet veel anders dan bij andere software die ‘end-of-life’ is en niet meer door leverancier ondersteund worden want uiteindelijk moeten ook deze Open Source CMS oplossingen regelmatig geupdate worden, met security fixes bijvoorbeeld:
Open Source – Community = Legacy Software
Verschillende analisten geven aan dat Open source komende jaren zal groeien waarbij de combinatie van cloud een boost geeft aan de value-added subscriptions. Nu is soms nog wel onduidelijk Wat je precies voor die ‘fee’ krijgt, net als wat je uiteindelijk mag en kan doen met de code maar dat is vaak meer een probleem van uitbesteding dan Open Source.
Een infographic over WordPress, Drupal en Joomla: http://josemmsimo.files.wordpress.com/2013/10/devious_cms.png
Voor wie de duitse taal machtig is, hier een studie van het duitse ministerie voor IT, de gehele studie is 163 pagina’s
https://www.bsi.bund.de/DE/Publikationen/Studien/CMS/Studie_CMS.html
Dat is ietwat serieuzer als de infographic.
Het is prima dat de bij de SDBN aangesloten Drupal implementatie partners onderling praten over zaken als kwaliteit en werken volgens de Drupal Coding Standards. Hoe gaat er in de praktijk vastgesteld worden of ook de niet-functionele eisen goed zijn geïmplementeerd door een Drupal implementatiepartner en in hoeverre deze zich tijdens de implementatie strak heeft gehouden aan de conventies en standaarden?
Het hebben van kwaliteitscriteria, conventies en standaarden op papier is niet voldoende. We weten allemaal dat als er in de praktijk binnen budget en planning deadlines moeten worden gehaald om de business tevreden te stellen, er bochten worden afgesneden en kwaliteit vaak het kind van de rekening wordt. De overdraagbaarheid waar JW het terecht over heeft, kan dan een grote uitdaging blijken te zijn als het op een transitie naar een andere Drupal implementatie partner aankomt.
Natuurlijk zijn er afspraken te maken over doorontwikkeling, SLA’s etc., zoals Michel van Velde aangeeft. Maar wie gaat daarvoor betalen? Uiteindelijk is het toch vaak de eindklant die geconfronteerd wordt met de meerkosten. En dat hoeft helemaal niet nodig te zijn.
Overdraagbaarheid hangt afgezien van goede documentatie in hoge mate af van hoe onderhoudbaar de maatwerkcode is gerealiseerd. Voordat een implementatie daadwerkelijk start, is het van belang om na te gaan of in het ontwerp goed rekening is gehouden met zaken als analyseerbaarheid, aanpasbaarheid, testbaarheid, modulariteit en herbruikbaarheid.
Tijdens de implementatie kan voor elke sprint via broncode analyse objectief en onafhankelijk worden vastgesteld of de implementatiepartner goed onderhoudbare en daarmee goed overdraagbare code heeft geproduceerd. Aanvullend kunnen onafhankelijke experts vaststellen hoe de ontwikkelaars zijn omgegaan met PEAR (de PHP Extension & Application Repository) door te controleren of de ontwikkelaars de PEAR componenten op de juiste wijze als 3rd party code behandelen.
Door op bovenstaande wijze technische kwaliteit/onderhoudbaarheid vooraf en tijdens de implementatie goed in het software voortbrengingsproces te borgen, zijn vervelende verrassingen tijdens de acceptatietest te voorkomen en zal een eventuele transitie naar een andere Drupal implementatiepartner een minder grote uitdaging zijn.
Een belangrijk bijkomend voordeel is dat wijzigingen aan de Drupal maatwerkomgeving veel kostenefficiënter kunnen plaatsvinden tijdens de resterende levensduur. Dat zal de eindklant enorm waarderen. En dat is toch waar we het allemaal eigenlijk voor doen?