Når tingene ikke virker - ansvar?

Online Marketing:

Når man arbejder i Open Source og har mange udviklere på, så udvikles der på forskellig vis, det er ok, men faktum er at der sjældent findes dokumentation, for hvad der er ændret og hvad der ikke er ændret i standard softwaren.

Dette er et stort problem, da en shop kan gå fuldstændig i sort, hvis dokumentationen for tidligere udførte tilretninger ikke kendes.

Ovenstående er på ingen måde noget du kan give open source skylden for, men du kan give manglende kompetence, viden og erfaring hos udviklerne skylden for ikke at underlægge koden versionkontrol i f.eks. svn/git/cvs osv og at de skriver mangelfuld dokumentation.

Jeg vil vædde med at du kan finde rigtig mange virksomheder der har kode i drift, der er langt værre end størstedelen af det opensource der findes i dag.

Så lad være med at give open source som helhed skylden for dårlige udviklere. De findes desværre overalt.

Hmm... Det er lige så meningsløst.

Vi udvikler redSHOP udvidelsen til Joomla.

Den er Open Source.

Det er det dansk udviklet webshop system som er mest downloadet i verden så vidt jeg ved pt.

Vi har et udviklingshold på 15 mand der står bag redSHOP.

Vi laver fuldstændigt supporterede og servicerede profesionelle løsninger - men alle mulige andre udbydere kan også bruge vores software.

Vi generalisere typisk kundernes feature ønsker og implementere dem i den generelle redSHOP software så kunderne slipper for omkostningerne på at vedligeholde en selvstændig branch - Dette gør vi også for alle de andre udbydere som benytter vores software.

Der er _intet_ ved vores løsning som Dandomain, Scannet, Red Pitt eller andre closed source systemer skulle kunne gøre bedre eller tilbyde som vi ikke også kan tilbyde - Vi har bare flere udviklere, mange flere releases, et kæmpe community (i dag på over 21.000 brugere) som rapportere fejl, foreslår nye features eller forbedringer og ALT sker fuldstændigt for åbne vinduer.

Hvordan vil dette scenarie nogensinde sætte folk dårligere??

Så for gud ved hvilken gang så har de ting du skriver om INTET med om det er open eller closed source men derimod om valg af system og leverandør.

Et par spredte kommentarer:

1. Når man udvikler på sin shop, om det så er open source eller et licencieret system, så gør man det ALTID i et test miljø. Det vil sige rettelser og opdateringer vil aldrig få din butik til at gå i sort.

2. Får du lavet tilretninger til din løsning hos en leverandør der ejer systemet så skal du være klar til at tage den investering igen hvis du skifter til en anden. Derfor ville OS da være et oplagt valg.

3. For næsten alle ydelser man køber står et evt. krav man vil rette mod leverandøren i forhold til købs prisen. Når i sælger varer i jeres shops ville i vel heller ikke giver en erstatning der var højere end den pris i havde fået for produktet. Med mindre i er underlagt et udvidet produkt ansvar.

Hvis din shop pris er over 300 kr. om måneden så burde du have fået en bedre service i forhold til at få løst problemet. Kan det skyldes at de havde svært ved at finde fejlen ?

/Skifter

Skifter:

1. Når man udvikler på sin shop, om det så er open source eller et licencieret system, så gør man det ALTID i et test miljø. Det vil sige rettelser og opdateringer vil aldrig få din butik til at gå i sort.

Du udvikler i et udviklingsmiljø. Når udvikleren er færdig med det så bliver det lagt på testmiljø hvor andre tester det der er lavet. Her kan udvikleren så gå videre med nye opgaver mens der testes.

Online Marketing:

Når man arbejder i Open Source og har mange udviklere på, så udvikles der på forskellig vis, det er ok, men faktum er at der sjældent findes dokumentation, for hvad der er ændret og hvad der ikke er ændret i standard softwaren.

Det har ikke noget at gøre med om det er Open Source. Der findes også klamhuggere i Closed Source virksomheder. Hvis udviklerne ikke dokumenterer deres rettelser så har det ingen betydning hvilken benævnelse systemet har.

Online Marketing:

Open Source, her har den lokale programmør mange gange været inde og ændre i selve shopfilerne (grundkodningen i shoppen) – og når en ny tager over opdateres der mange gange med uheldige konsekvenser for kunderne.

Som regel på de størrer systemer er der en kerne der skal godkende de rettelser og ellers er der andre programmører der ser rettelsen og kan rette denne. Her gælder det også at man skal dokumentere sine rettelser og gør man ikke det, så kan ens adgang til kildekoden blive fjernet. Mange Open Source systemer kræver at man skal oprettes som udvikler inden man få lov til at sende rettelser retur.

Helle - houseofkids.dk:

og vores kunder betaler heller ikke ekstra for at vi har gjort så der er alt for meget at lave. Vi tager heller ikke ekstra betaling hvis de ringer og stiller et spørgsmål ind i mellem.

Du kan ikke sammenligne rådgivningsbrancher med produktbrancher. Hvis man lever af at sælge sin tid og ekspertise, så får man altså kun den tid - og den response hastighed, som man betaler for.

Problemet i din situation lyder til at være, at der ikke helt er overensstemmelse mellem det du havde forventet og det som faktisk er aftalt. Ansvaret for det må ligge på begge parter (med mindre de faktisk HAR forsøgt at sælge dig en højere og mere passende service level aftale, som du så har sagt nej til).

Jeg er helt enig med dig i, at det er en meget alvorlig fejl, hvis man ikke kan ligge nye varer i sin shop. Det kan som du selv siger koste rigtig meget i manglende salg. Men spørgsmålet er, hvad der står i den aftale du har indgåët omkring situationer som dette. Du bør naturligvis få aftalt, hvor hurtigt de SKAL gå igang med at fikse sådanne alvorlige problemer.

Mikkel deMib Svendsen:

Du kan ikke sammenligne rådgivningsbrancher med produktbrancher. Hvis man lever af at sælge sin tid og ekspertise, så får man altså kun den tid - og den response hastighed, som man betaler for.

Enig - men igen synes jeg der bør være modifikationer. Eks er der stor forskel på om man har glemt sit password eller om man skal have ændret i en kode.

Forventningsafstemning har helt sikkert været et stort problem i dette forløb. Jeg må så tage konsekvensen af det nu, og se om jeg kan få en samarbejdsaftale på plads i forhold til retning af graverende fejl og en beskrivelse af hvad dette eks er. Det er bare ikke så nemt når vi er langt over den dato hvor kontrakten blev underskrevet.

Håber bare tingene kan løse sig og at det ikke skal være så besværligt. Jeg gider bare ikke den slags - det tager alt for meget energi.