Open Source CMS løsning - hvad er rimelige krav?

BLOG: Open Source er hot og sexy - ingen tvivl om det! Men når lyset brænder ud, hvem har så leveranceansvaret? Leverandøren har mulighederne, men skal kunderne selv tage ansvaret for Open Source produkterne?
Skrevet i CMS-Bloggen


Publiceret d. 4. maj 2010 kl. 10.05 | Antal kommentarer (9)


 
ANNONCE:
En kunde køber af en løsningsleverandør en løsning bygget på Closed Source CMS, og i aftalen står der, at løsningsleverandøren ikke kan drages til ansvar for 3. parts (Closed Source) moduler. Løsningsleverandøren er heller ikke ansvarlig for Closed Source CMS. Det er vel egentligt rimeligt nok. Hvis kunden oplever problemer med Closed Source CMS eller 3. parts software henvender de sig til produktleverandøren og får alt efter leverandørens kodeks og ressourcer løst sit problem efter X antal måneder.

En anden kunde køber en løsning bygget på Open Source CMS og Open Source moduler. I aftalen står der, at løsningsleverandøren ikke kan drages til ansvar overfor OSS CMS og gratis Open Source moduler. I forhold til Closed Source Leverandørerne skal han vel ikke stilles ringere, eller ..? Er det ikke rimeligt, når der nu er adgang til at rette direkte i moduler og programmer, at løsningsleverandøren faktisk har et ansvar for den samlede leverance og ikke kan dække sig ind under at de ikke har muligheden for at rette eventuelle fejl? Det kan de jo! Mange gange er der ikke mulighed for at henvende sig til en central organisation for at få tilrettet eksempelvis OS CMS (Plone, Typo3, Drupal, Joomla, etc. ) .

Det er oftest op til kunden at bestemme sig for hvilke krav, som de vil stille. Det er meget forskelligt fra organisation til organisation.

Nogle Open Source CMS løsningsleverandører dækker risikoen for mangelfulde 3. partsmoduler/CMS ved en økonomisk buffer og andre fremlægger muligheder og risici i Open Source CMS som en forretningsfordel for kunden. De har "friheden til at vælge" (om de vil betale for at løse eventuelle problemer).

Hvad er jeres erfaringer med kravene fra jer som kunder. Hvad er erfaringerne med kravene til jer som leverandører?

(skriv hvor I kommer fra, så vi kan få en afsender på svarene - hvorfor skjule det, når det ikke er deciderede reklameindlæg).

Kommentarer til blogindlæg



Både ja og nej

hvis løsningsleverandøren tager den samme pris for begge læsninger inc software, så har han tages sig bestalt for den gratis kode, og bør derfor også stå for support

men det hele bunder i hvor meget kan man i relitetet fra skrive sig
Hvad hvis Closed Source leverandøren melder tilbage at fejlen aldrig vil blive rettet eller det først vil blive det i den næste version som man skal betale for, hvad så, kunden har købt og betalt for et produkt som er fejlbehæftet

men hvad så med OSS der er det anderledes, da der generelt er flere måder en fejl kan blive løst på
* core udviklerne vil rettet fejlen
* andre vil rettet fejle
* der er ikke umidelbart nogle som vil rettet fejlen
man kan så enten vente på at nogle med tiden retter fejlen
eller betale en udvikler for at rettet fejlen
men nogle OSS projekter har firmaer bagved som man kan købe support aftaler ved, så man får den samme mulighed for at få rettet fejl som hvis det var Closed Source

"Er det ikke rimeligt, når der nu er adgang til at rette direkte i moduler og programmer, at løsningsleverandøren faktisk har et ansvar for den samlede leverance og ikke kan dække sig ind under at de ikke har muligheden for at rette eventuelle fejl? Det kan de jo!"

Æhhh - det var noget af en antagelse! :)

Der er altså ingen garanti for at en virksomhed som har specialiseret sig i grafisk design og template-building til f.eks. Drupal har de nødvendige kompetencer til at foretage rettelser i det underliggende CMS.

Et system som TYPO3 bruger det interne TYPOScript til skabeloner, så her er der meget langt mellem det at lave webløsninger til kunder, og så det at lave fejlretning på selve CMS-systemet som er skrevet i PHP.

Borteset fra det vil "uautoriserede" fejlretninger direkte i den lokale kode næsten altid ende i en tragedie når eventuelle opdateringer fra leverandøren køres ud på systemet, så medmindre man er parat til at gøre sig den ulejlighed at få eventuelle patches medtage i de officielle opdateringer skal man efter min bedste overbevisning lade være med at pille. Det er i hvert fald vigtigt at man gør sig risikoen helt klar.

"Mange gange er der ikke mulighed for at henvende sig til en central organisation for at få tilrettet eksempelvis OS CMS (Plone, Typo3, Drupal, Joomla, etc. ) ."

Det er simpelthen noget vrøvl. Alle de 4 nævnte systemer har organisationer (både kommercielle og frivillige) som håndterer fejlrapporter og bugfixing, oven i købet ofte i en ret transparent form (offentlig bugzillaer, f.eks.) som gør det muligt at se forslag til eventuelle workarounds indtil en egentlig fejlretning er færdigudviklet, testet og udsendt.

En hurtig søgning på Google på "<CMS> report bug" gav links til hvordan man rapporterer fejl til de respektive udviklere af alle fire nævnte CMS-systemer som det allerførste link i alle fire tilfælde!

Mvh,
Anders

Hvis man slår op i det offentligt tilgængelige bugsystem for et open source-projekt, vil man typisk se læssevis af mere eller mindre kritiske bugs. Det er vel den slags fejl, en leverandør ikke ønsker at påtage sig ansvaret for at løse inden for den aftalte betaling.


"Hvis kunden oplever problemer med Closed Source CMS eller 3. parts software henvender de sig til produktleverandøren og får [...] løst sit problem efter X antal måneder."

Det ville da være dejligt, hvis det var sådan.

Hvis du er en stor kunde, der har købt nogle meget dyre licenser, kan det godt være, at leverandøren er interesseret i at løse dine problemer i overskuelig fremtid. Men i almindelighed kan man ikke regne med, at leverandøren retter alle indrapporterede fejl.

@Anders

"Æhhh - det var noget af en antagelse! :)

Der er altså ingen garanti for at en virksomhed som har specialiseret sig i grafisk design og template-building til f.eks. Drupal har de nødvendige kompetencer til at foretage rettelser i det underliggende CMS.

Et system som TYPO3 bruger det interne TYPOScript til skabeloner, så her er der meget langt mellem det at lave webløsninger til kunder, og så det at lave fejlretning på selve CMS-systemet som er skrevet i PHP."

LP: Ja, de leverandører vi arbejder med kender systemet godt nok til at kunne ordne de fleste af den slags bugs.

"Borteset fra det vil "uautoriserede" fejlretninger direkte i den lokale kode næsten altid ende i en tragedie når eventuelle opdateringer fra leverandøren køres ud på systemet, så medmindre man er parat til at gøre sig den ulejlighed at få eventuelle patches medtage i de officielle opdateringer skal man efter min bedste overbevisning lade være med at pille. Det er i hvert fald vigtigt at man gør sig risikoen helt klar."

LP: Selvfølgelig skal kode tilbage i versionering - alt andet ville jo være unaturligt.

"Det er simpelthen noget vrøvl. Alle de 4 nævnte systemer har organisationer (både kommercielle og frivillige) som håndterer fejlrapporter og bugfixing, oven i købet ofte i en ret transparent form (offentlig bugzillaer, f.eks.) som gør det muligt at se forslag til eventuelle workarounds indtil en egentlig fejlretning er færdigudviklet, testet og udsendt."

LP: Har du selv praktiske erfaringer med at få rettet fejl hos OSS CMS organisationer og frivillige. Det er altså ikke så ligeud af landevejen som du postulerer. Hvis det var det så kan leverandøren vel sagtens tage ansvaret. Men smid endelig konkrete erfaringer, tak!

"En hurtig søgning på Google på "<CMS> report bug" gav links til hvordan man rapporterer fejl til de respektive udviklere af alle fire nævnte CMS-systemer som det allerførste link i alle fire tilfælde!"

LP: Det er som regel ikke fejlrapporteringen som er det kritiske (det er altså ret let at sætte et fejlhåndteringssystem op), men det er rettelsen af fejl, som KAN blive en flaskehals.

Derudover er der jo også propritære (OSS) moduler hvor fejlene ikke altid håndteres af de frivillige, som retter i grundsystemet (OSS CMS).


Lars Pedersen skrev:

LP: Ja, de leverandører vi arbejder med kender systemet godt nok til at kunne ordne de fleste af den slags bugs.


Der er uden tvivl mange som rent faktisk har kompetencen til det, men efterhånden som CMS-systemerne bliver lettere tilgængelige for personer med flere grafiske talenter end programmeringsmæssige ditto (WordPress er f.eks. kommet meget langt på det område) mener jeg ikke at det er rimeligt at forvente at leverandøren skal stå for eventuelle fejlretninger i det underliggende system.

LP: Selvfølgelig skal kode tilbage i versionering - alt andet ville jo være unaturligt.


- og hvor mange tror du lige der har styr på den proces? Hint: Væsentligt færre end det antal som piller i koden.

Jeg ved godt hvordan det BØR være, men min erfaring er at virkeligheden ikke kan leve op til idealet.

LP: Har du selv praktiske erfaringer med at få rettet fejl hos OSS CMS organisationer og frivillige. Det er altså ikke så ligeud af landevejen som du postulerer. Hvis det var det så kan leverandøren vel sagtens tage ansvaret. Men smid endelig konkrete erfaringer, tak!


Personligt? Nej, kun lidt småting i forbindelse med Tomcat for en del år siden, men mine kolleger har fået patches med i både TYPO3-extensions og i tidernes morgen i osCommerce extensions, og der var responstiden ganske fornuftig.

LP: Det er som regel ikke fejlrapporteringen som er det kritiske (det er altså ret let at sætte et fejlhåndteringssystem op), men det er rettelsen af fejl, som KAN blive en flaskehals.

Derudover er der jo også propritære (OSS) moduler hvor fejlene ikke altid håndteres af de frivillige, som retter i grundsystemet (OSS CMS).


Det er selvfølgelig rigtigt at det svinger meget fra projekt til projekt, og det er uden tvivl også derfor at man ser mange forks af osCommerce - den egentlige udvikler er meget utilbøjelig til at tage andres arbejde med ind i projektet.

Jeg har tænkt lidt over dit oprindelige indlæg og mit første svar, og jeg tror at vi måske taler lidt forbi hinanden:

Jeg mener ikke at det er rimeligt at forvente af leverandøren af et website at leverandøren skal være ansvarlig for fejlretning af den bagvedliggende software, MEDMINDRE der laves en aftale om at leverandøren kompenseres for dette arbejde efter tidsforbrug.

Problemet er at de fleste kunder er så vant til at betale for properitær software og de medfølgende opdateringer at de slet ikke kan følge denne tankegang.

Jeg er på det rene med at dette uden tvivl hænger meget sammen med hvilket marked man bevæger sig på, da større enterprise kunder er meget mere vant til serviceaftaler på deres software.

Mange OSS CMS-systemer bruges imidlertid af SMB'ere som er vant til at betale for en Office OEM og få alle fejlrettelser gratis, og der er det vanskeligere at forklare hvorfor de skal betale for at få lavet rettelser hvis de ikke vil vente på en "officiel" fejlrettelse.

"Når lyset brænder ud" er et kæmpe problem - uanset om det er proprietære systemer eller Open Source. Hvad hjælper et juridisk krav, hvis leverandøren "forsvinder".
På Aarhus Universitet havde vi to hovedkrav til nyt CMS:
- vi skulle være overbeviste om, at platformen om 5 år fortsat er i dynamisk udvikling.
- vi ønskede et system, hvor der til stadighed var mulighed for at vælge mellem flere mulige implementeringspartnere - altså et marked for udvikling indenfor en konkret platform.
Valget af CMS og partner startede med 16, indsnævredes til 3, 2 og til sidst valgte vi TYPO3 og Linkfactory. Sitecore var med til det sidste og vi er overbeviste om, at systemet også kunne have levet op til vores behov.
Vores vurdering var, at vi ville have fået noget for licensen i det proprietære system. M.a.o. at valget af en Open Source løsning giver ekstra omkostninger til drift og vedligehold. Vores vurdering var, at over en 5 årig periode ville der ikke være stor forskel på de to CMS, der var med i opløbet.


Som kommerciel udbyder og aktiv deltager i debatter omkring online markedsføring, CMS og closed source kontra open source, støder jeg naturligvis ofte på meget forskellige meninger vedr. emnet. Vi har vores eget closed source cms , men vi har alligevel valgt også at beskæftige os med konsulentbistand og integrering af open source løsninger, i de situationer hvor det er en fordel. Særligt til blogging (wordpress) og særlig websites som kræver integrationer med andre open source løsninger, hvor der allerede findes færdigudviklede moduler. Her anvender vi gerne open source, hvis det er en fordel.

Det er dog ikke altid open source løsningen vil være billigst, da nogen open source systemer kan være dyrere at vedligeholde og drifte.

I sidste ende handler det for os om at levere den bedste mulige løsning til vor kunde, til en konkurrence-dygtig pris. I forhold til hvor ofte der tales om krav til at en løsning ikke må være "låst / closed" og skal være open source og så leverandør-uafhængig som muligt m.v., er det dog påfaldende at det sjældent er et decideret krav fra vore kunder.
De kravspecifikationer vi møder er oftest fokuseret på pris og funktionalitet, og sjældent på om det er open source / closed source.

En hurtig:

"I forhold til hvor ofte der tales om krav til at en løsning ikke må være "låst / closed" og skal være open source og så leverandør-uafhængig som muligt m.v., er det dog påfaldende at det sjældent er et decideret krav fra vore kunder."

LP: Hvis det er ufravigelige krav, så bliver de vel sjældent kunder hos jer? (No offence).


Lars P > Nej, for som jeg skriver i mit indlæg, så yder vi også konsulentbistand og integrering af open source løsninger.

Så vi har også kunder som vi har leveret open-source løsninger til. Det er sådan set mere eller mindre hele essensen i mit indlæg, at vi leverer det efterspurgte, fremfor at være fastlåst til én bestemt type system.

Kommentér
Ytringer på debatten er afsenders eget ansvar - læs debatreglerne

Mere fra CMS-Bloggen


Thore og compagnon har sat et godt projekt i søen med brugertest.nu. Muligvis er der mange værktøjer derude mangen til (f.eks usabilitytest.com), men det her ser ud til at fungere godt, bare ikke helt godt nok endnu.
10. marts 2011 kl. 09.37 | læs »



Projekter, der gennemføres ved af agile metoder kan næsten per definition ikke gå galt uanset kvalifikationerne hos deltagerne. Metoden er således attraktiv for de uerfarne projektledere på kundesiden og Account Managers og udviklere på leverandørsiden.
7. oktober 2010 kl. 08.44 | læs »



På udbudportalen skriver Andreas Christensen, partner i Horten advokatfirma, at SKI-aftalerne ikke er gyldige i den nuværende form. Hvis det er rigtigt, ligger der en mindre bombe under en del af aftalerne mellem offentlige kunder og leverandørerne, der hviler på SKI's rammeaftaler.
16. juni 2010 kl. 07.54 | læs »



Vi kan nu med baggrund i projekter og kunder i 2009/2010 konstatere at Open Source CMS systemer trives særdeles godt på det nuværende (Web) Content Management (WCMS/CMS) marked.
2. juni 2010 kl. 10.08 | læs »



Open Source er hot og sexy - ingen tvivl om det! Men når lyset brænder ud, hvem har så leveranceansvaret? Leverandøren har mulighederne, men skal kunderne selv tage ansvaret for Open Source produkterne?
4. maj 2010 kl. 10.05 | læs »








Lars Pedersen
Lars Pedersen (cand.scient i datalogi) har arbejdet med Content Management siden 1996. Både som udvikler, brugervenlighedsekspert og projektleder i forbindelse med tilblivelsen af et landets tidligste CMS. Er i dag partner og analytiker i det uafhængige konsulentfirma BNP, der i 2000, som den første danske virksomhed, specialiserede sig i uvildig CMS rådgivning. Vil på Bloggen prøve at smide både personlige betragtninger og provokationer.

Følg også med på vores engelsk-/dansksprogede blogs www.cmshardtalk.com og www.cmshardtalk.com/dk
Besøg dine gratis, uafhængige communities. INGEN Leverandører eller konsulenter, Kun dine Sitecore kolleger og uafhængige eksperter.

Generelt CMS/Portal Community, hvor vi mødes på tværs af systemplatforme

Sitecore community til at understøtte brugere af sitecore.

Sharepoint/MOSS 2007 community til at udnytte din Sharepoint Portal Server bedre.

 


Mest læste seneste uge

Kan gratis sikkerhedssoftware virkelig beskytte din pc? Svaret er ja, hvis du vælger det rette produkt. Læs her en test af de mest pålidelige gratis sikkerhedsprogrammer.

Næsten 200 IBM-ansatte får med få timers varsel sidste arbejdsdag i dag. Ingen var orienteret forud for dagens massefyring, som effektueres øjeblikkeligt.

Flyselskabet SAS har brugt op mod trekvart milliarder kroner og seks år på at udskifte sit bookingsystem. Undervejs har der været flere projekt-udfordringer, som kulminerede en vinternat med en big bang-migrering.

Her er forklaringen på, at IBM Danmark med direktør Lars Mikkelgaard-Jensen i spidsen fyrer 170 medarbejdere.

IBM Danmark lader hovederne rulle.