[willemmassier]

ok. Van Wordpress weet ik niets. Dus moet ik verder passen.
Succes met de discussie.

[eblocks]

Even voorstellen, mijn naam is Remco, en dit is mijn eerste bericht in dit forum. Sinds 1999 heb ik een eigen bedrijf Art Digital, en ben werkzaam in grafische vormgeving & websites. Snel bleek dat de statische html websites niet meer voldoende waren, en ging ik op zoek naar opensource oplossingen.

Dit met het idee om voor weinig budget mijn klanten tegemoed te komen.
Deze opensource oplossingen bleken al snel de nodige minpunten te hebben.

Open source=iedereen kan de broncode inzien, men kan zo ook de veiligheidslekken in de code opsporen. Hiermee creeer je een gigantische mogelijke veiligheidslek, en je bent zo altijd verplicht de laatste updates zsm te installeren, gezien bij de bugfixes de lekken nadrukkelijk vermeld worden. Zo heb ik vaker forum's e.d. zien sneuvelen, dit niet als gerichte aanval door een professionele hacker, maar door scriptkiddies/ spiders die systematisch oude versies van de CMS'sen en fora opzoeken.

Gezien je zeer actueel moet blijven met updates, zijn custom aanpassingen bijna niet mogelijk, of je moet bij elke update je gedane wijzigingen weer doorvoeren.

Mede door deze punten had ik besloten om een eigen CMS te ontwikkelen (Eblocks), en 2 jaar geleden heb ik het roer omgegooid, en ben ik begonnen om het CMS vanaf scratch opnieuw te bouwen, dit keer centraal georienteerd. Dwz: 1 backoffice voor al mijn klanten. Het grote voordeel van deze methode voor mijn klanten is dat er continue updates gedaan worden, en voeg ik bijvoorbeeld een SEO module toe, dan profiteren gelijk alle klanten daarvan mee.

Ik ben niet zo arrogant om te zeggen dat mijn CMS niet te hacken is, of 100%veilig is (wel 99,9% ;-), echter moeten hackers heel wat meer moeite doen en gericht naar mogelijke lekken zoeken.

Gezien de gedane CMS ontwikkelingen uiteindelijk betaald moeten worden - en eigenlijk deze ontwikkelingen ook nooit zullen stoppen- zal je altijd een stuk duurder uitzijn dan met een vergelijkbaar gratis joomla pakket, die een keer zoveel gratis plugins en aanvullende modules bied.

Aan de andere kant, mijn klanten hoeven zich alleen druk te maken over de inhoud van hun website, en kunnen rekenen op een maximale inzet en korte bugfix tijd indien er toch iets misgaat. Voor een bedrijf, die de nodige waarde hecht aan zijn website, kan dat een goede reden zijn om toch te kiezen voor een betaald pakket, ondanks dat het 'neefje van de directeur op de zolderkamer' het ook had kunnen doen voor een kratje cola.

[Maxes]

Als CMS-bouwer wil ik een een belangrijk voordeel opnoemen voor de klant om te kiezen voor betaalde CMS-software: gebruiksvriendelijkheid.

Kijk, voor ons nerds is het natuurlijk gesneden koek als je Mambo, Joomla, Wordpress of Typo3 opent. Maar mijn gemiddelde klant zou gierend gek worden van alle knoppen, functies en andere zaken die het geheel als een (in zijn ogen) monster doen overkomen.

Content is king, maar als een klant direct denkt "Holymoley, dat ga ik nooit snappen!", dan kun je er donder op zeggen dat ie zijn site niet zal onderhouden.

Een CMS-leverancier heeft dan ook de morele taak een CMS te leveren met alleen die zaken die de klant daadwerkelijk gaat gebruiken en deze mogelijkheden op een dusdanig vriendelijke wijze te presenteren, dat hij denkt: "Ohw, dat ziet er makkelijk uit!"

Overigens is het leveren van naadloos geïntegreerd maatwerk bij betaalde software natuurlijk een stuk makkelijker. Je kunt wel kiezen voor een addon of een plugin, maar vaak levert dit net niet 100% de gewenste functionaliteit op, en je hebt wéér een hele rits extra knoppen in het menu.

Naast CMS-systemen lever ik ook hostingfaciliteiten. Daarmee ontdekte ik nog een ander nadeel van Open Source systemen... Hoge bomen vangen veel wind. Het nodigt in de praktijk uit om exploits te misbruiken. Ik weet: het is niet de schuld van het CMS, maar van de klant. Deze verzuimt immers de laatste patches te installeren. Maar bij betaalde CMS-systemen is het de leverancier die de boel dicht hoort te houden. Bij Open Source ligt die verantwoording bij de klant.

[eblocks]

Ik het zeker met maxes eens. Soms is minder juist meer.

Je moet werken vanuit de stoel van een klant, niet vanuit de stoel van de programmeur. En dat is idd iets wat vaak ontbreekt in de opbouw filosofie van de OS pakketten..

[Thijs]

Ben ook nieuw hier, mijn naam is Thijs en heb een eigen bedrijf in webdesign waarbij sem en analytics een hoge prioriteit genieten.

Ik denk dat Maxes een goed punt heeft wat betreft de gebruiksvriendelijkheid. Al kun je veel admin interfaces prima uitkleden zodat het allemaal goed te snappen is hoor.

Ik weet: het is niet de schuld van het CMS, maar van de klant. Deze verzuimt immers de laatste patches te installeren.

Wat hosting betreft ligt het bij ons toch echt anders, wij spreken met de klant in dat wij eventuele updates van het os systeem in de gaten houden. Als het nodig is doen wij de updates, dit valt bij ons onder de noemer onderhoud.

Ik zal dit verder volgen. ben erg benieuwd naar een ideaal SEO CMS en wil graag mee denken/discussiëren.

[Bert]

Dit is een vraag die mij ook al langer bezig houdt. Op dit moment merk ik dat open source een streepje voor heeft met name in het hele SEO verhaal.
Mijn ervaring met zelf gebouwde cms-en dat ik de programmeurs moet uit gaan leggen waar ze op moeten letten. En dan praat ik over zaken die joomla of typo3 standaard aan boord hebben. Daardoor heb ik het gevoel dat ik achter de feiten aan hol. Naast het SEO gebeuren speelt ook de W3C-standaard voor mij een belangrijke rol. Met name het opsporen van bugs in een site neemt steeds meer tijd in beslag en wie gaat dat betalen?

Mijn conclusie tot nu toe: Er zijn maar weinig costom builders die het echt snappen. Er wordt dramatisch veel aangeklooid!

[Bert]

Oorspronkelijk geplaatst door Kevin

Er is een simpel maar groot voordeel aan een betaald cms. Op deze manier sta je in direct contact met de maker van dit cms en weet deze maker exact wat er allemaal kan met dit cms. Daarnaast zijn aanpassingen door hem makkelijk te doen en kunnen uitbreidingen gedaan worden. Mocht de klant speciale eisen hebben aan het cms dan kunnen deze gemaakt worden en ben je niet afhankelijk of dit al ergens een keer door iemand is ingebouwd in de open-source variant.
Op die manier ben je veel flexibeler met je cms.

Mijn ervaring is dat costom builder er een potje van maken, het kennis niveau is teleurstellend. Te vaak moet ik hun gaan vertellen wat ze moeten doen. Dan praat ik over zaken die in typo3 of joomla standaard zijn.

[chris]

Wij verkopen een zelf ontwikkeld, "closed source" en dus betaald CMS. En soms is het lastig om objectief uit te leggen waarom je klanten zouden moeten betalen voor technologie die door vergelijkbare systemen gratis wordt geboden. Gekscherend roep ik wel eens "If you pay peanuts, you get monkeys" maar dat is te kort door de bocht.

Uit dit topic heb ik in een stuk of 5 ijzersterke argumenten vóór het betaalde CMS kunnen destilleren (zonder daarmee OS te hoeven afbranden), dus daarvoor in ieder geval alvast bedankt iedereen ;-) Op onze eigen site heb ik ook ooit een argumentatie geplaatst inzake OS vs. betaald CMS (Open source CMS of commercieel CMS?). Ik moet daarbij wel eerlijk opmerken dat dat verhaal "lichtjes" ten faveure van het betaalde CMS is geschreven (het hemd is immers nader dan de rok). Maar op basis van wat ik vandaag hier op dit forum heb gelezen, ga ik dat binnenkort eens wat verder nuanceren.

Zelf denk ik dat OS-CMS wat meer geschikt is voor "advanced users" en bouwers dan voor "gewone" users (de marketing medewerker, de secretaresse, de kleine ondernemer...). In onze CMS-training krijg ik regelmatig mensen die ervaring hebben met Joomla. Ik heb meerdere keren gehoord: "Jullie CMS doet denken aan Joomla, maar dan makkelijker". Dat geeft te denken, want ons CMS doet en kan in grote lijnen hetzelfde als Joomla. Maar die perceptie van een gebruiker ligt misschien meer aan de wijze waarop Joomla door een bouwer is geïmplementeerd, dan aan Joomla zelf.

Als ik zelf de aankoopbeslissing over een CMS zou moeten nemen, zou "betaald of open source" niet bovenaan mijn criterialijstje staan (hoewel het uiteraard in het totaalplaatje wel een redelijk belangrijke rol zou spelen). De kostenverschillen tussen OS en betaald zijn namelijk -- uitgaande van een te maken keuze uit een aantal goede betaalde en OS alternatieven -- niet zo groot.

"O ja Chris, hoe zit dat dan?"

Nou, dat zit zo:

Een goed CMS hoeft niet meer gebouwd te worden, maar bestaat al en hoeft alleen nog maar geïmplementeerd te worden. Zit je als klant met een internetbureau aan tafel dat zegt een CMS voor je te kunnen bouwen, maak dan dat je als den donder wegkomt. Een goed internetbureau zou namelijk namelijk "van de plank" een CMS moeten kunnen bieden dat direct uit de doos voorziet in alle voor de hand liggende functies, bij voorkeur modulair uit te breiden met iets minder voor de hand liggende, maar ook veelgevraagde functies. Elk wiel is al tig keer uitgevonden en als klant zou je niet meer moeten hoeven te betalen voor de ontwikkeling van wiel nummer zoveel.

In het bovenstaande kan uiteraard worden voorzien met OS. Maar ook serieuze leveranciers van betaalde CMS-en kunnen dit bieden. Daarvan uitgaande hoeven de eenmalige kosten van de bouw van een website met een betaald CMS niet hoger te zijn dan die van een site met een OS-CMS. Die kosten worden betaald door aantal uren x uurtarief, en er zal weinig tijdsverschil* zitten tussen beide varianten.

( * Je zou kunnen redeneren dat de leverancier van een betaald CMS zijn eigen techniek beter kent dan een leverancier die werkt met OS, omdat hij het echt helemaal zelf heeft gemaakt. Ergo zou je kunnen redeneren dat de betaald-CMS-leverancier sneller en dus goedkoper zou kunnen werken. Ik weet uit onze eigen praktijk dat het implementeren van een website -- uiteraard wel afhankelijk van eisen, wensen en complexiteit -- een kwestie van een paar muisklikken kan zijn, maar kan niet oordelen over hoe dat zit met OS. )

Het kostenverschil zit 'm dan ook meestal alleen in de licentiekosten. De ontwikkelaar van een betaald CMS heeft betaalde menstijd geïnvesteerd en zal die terug willen en moeten verdienen. Bovendien moet hij zijn CMS up to date en dus door blijven ontwikkelen. Veel betaald-CMS leveranciers (wij ook) vragen dan ook een periodiek licentiebedrag. Dat zorgt ervoor dat ze niet alleen maar afhankelijk zijn van "uurtje/factuurtje", bedrijfseconomische continuïteit kunnen garanderen en tijd kunnen vrij maken en houden voor doorontwikkeling. Het licentiebedrag omvat ook gebruikers- en technische support aan klanten. Op een wat hoger niveau is het voor een klant wellicht ook geruststellend dat zijn internetbureau een vaste stroom van inkomsten heeft en niet zomaar van de ene dag op de andere dag "om kan vallen" (erg actueel item, met de huidige economische crisis).

Maar laat ik eens wat harde cijfers noemen (ik begon immers met de stelling dat de kostenverschillen tussen een OS-CMS en betaald CMS niet zo groot hoeven te zijn).

Ervan uitgaande dat de eenmalige implementatiekosten gelijk zijn, resteert alleen het verschil dat wordt gecreëerd door de licentiekosten van een betaald CMS (ik negeer even hostingkosten, omdat we allemaal weten dat hosting in goede kwaliteit tegen lage kosten verkrijgbaar is; bij ons is hosting -- tot een x capaciteit -- gewoon inbegrepen in de licentiekosten en we speciferen die kosten momenteel niet eens apart).

Ons CMS kost (instapversie) € 39 per maand. De volledige versie kost € 69 per maand. Prijzen van aanvullende modules variëren van € 2,50 tot € 15,00 per maand. De meeste klanten nemen altijd wel een paar aanvullende modules. In de praktijk varieert het maandbedrag dat klanten betalen tussen ca. € 50 en € 125. In dat laatste geval hebben we overigens vaak wel over organisaties die zeer intensief aan hun website werken en veel functionaliteit gebruiken. Dus, onder de streep, is ons CMS tussen € 600 en € 1.500 per jaar "duurder" dan een OS-CMS. Natuurlijk, elke euro telt, maar toch zijn dit prima verdedigbare bedragen (per maand bekeken valt de GSM-rekening van de gemiddelde verkoopmedewerker hoger uit...), mits er uiteraard kwaliteit en continuïteit tegenover staat.

Of een opdrachtgever dat kostenverschil er voor over heeft, is uiteindelijk afhankelijk van een heleboel factoren die in deze topic erg mooi aan de orde zijn gekomen.