I en artikkel i Teknisk ukeblad (web) kan man lese at utviklingsdirektør Lars Tveit i Bergen kommune advarer mot overdreven fokus på teknologi fremfor hva IT skal bidra til å løse.
Han mener at det er alt for sterk fokus på de tekniske løsningene fremfor oppgavene som teknologien skal løse. Fornyingsdepartementet ønsker sterk fokus på åpen kildekode for å fremme konkurranse og å redusere lisenskostnader.
I utgangspunktet blir dette rått pari sånn enkelte kommuner ser på problemstillingen. I den ene hånden har du en åpenkildekode-løsning som ikke koster noe i lisens, og i den andre hånden har du en kommersiell leverandør som skal ha x kroner initiellt og gjerne 20% av kjøpssummen årlig i lisens og vedlikehold.
Det som ofte går i glemmeboka og som de kommersielle leverandørene påpeker er at de 20% som oftest inkluderer vedlikehold (oppgraderinger, feilfikser etc). Med en åpenkildekode-løsning betaler du som oftest pr. time for slike oppdrag. I tillegg har som oftest som kommersiell leverandør en road-map og en godt planlagt plan for fremtidige versjoner og hvilke funksjoner som kommer. Dette er også noe mange åpenkildekode-løsninger mangler.
Det kan sammenliknes med å ha fast- eller flytenderente på lånet. Med fastrente (20% fast vedlikeholdsavgift) så får du forutsigbarhet på utgiftene dine. I motsatt fall kan du ende opp med ikke å få oppgradert eller fikset feil fordi du har brukt opp budsjettet for perioden.
Å tro at firma som lager og/eller leverer åpenkildekode-løsningen gir bort noe gratis er naivt. Noen har brukt tid og penger på å utvikle løsningen og noen har brukt tid og penger på å opprette et salgs-, support- og opplæringsapparat rundt løsningen. De skal ha sine penger tilbake med gevinst de også, akkurat som en leverandør av en kommersiell-løsning.
Et firma som ikke selv har brukt tid og penger på utvikling har et konkurransefortrinn ved at de ikke må tjene inn igjen utgiftene brukt til utvikling, dermed har de mulighet for å prise seg godt under en ren kommersiell leverandør som også må tjene inn igjen millioner i utviklingsutgifter. Konkurrerer to slike på like vilkår? Eller mener vår sosialistiske regjering kanskje at alle bør utvikle på community-basis. Slik at i stedet for at en leverandør bruker millioner på utvikling så står det 100-vis av frivillige bak? Disse frivillige kan jo gå på arbeidsledigshetstrygt 
for å tjene til sitt daglige brød. For å leve på “street-cred” og vann er tøft i lengden.
Jeg har selv opplevd at en kunde som trodde de hadde skutt gullfugler og kjøpt en åpenkildekode-løsning kom til oss og ønsker våre kommersielle løsning i stedet. De hadde slitt seg gjennom flere leverandører og brukt utallige timer på konsulentbistand for tilpassning, feilfiksing, opplæring etc. Allikevel var de ikke tilfreds med sluttresultatet.
For en kjøper som skal vurdere mellom en kommersiell og en “åpen” løsning er det viktigste å se på TCO (total cost of ownership) over flere år. Du må kontakte andre som alt bruker samme løsning og innhente tall fra dem.
Viktige momenter:
Innkjøpspris
Lisensavgift pr år
Årlig oppgradering til seneste versjon
Feilsøking og retting
Sikkerhet/risk (både i leverandør og løsning)
Kurs
Opplæringsmateriale
Kundesupport (telefon, epost, 24/7 eller hva som er aktuelt for dere)
Jepp. Det er i bunn og grunn kvaliteten på utviklerne som har mest å si.
Åpen kildekode er det samme som leverandør-uavhenging kode og denne egenskapen er langt viktigere enn innkjøpsprisen på koden.
Med proprietær kode kan man lett oppleve at på grunn av begrensningene i lisens-avtalen så kan en forbedring som lages etter timespris for Bergen ikke kan benyttes i Oslo uten at sistnevnte må tegne en ny lisensavtale og må ut med nye beløp.
Dermed oppnår man gjenbruk og kan lettere nå målet med at kommunens etater skal kunne tilby det samme og med samme kvalitet uansett hvor man er i landet.
Jeg har tidligere jobbet mye med et web basert CMS kalt EPiServer. Der slåss vi ofte mot feks eZ-Publish.
Argumentet med leverandør-uavhengig kode løste EPiServer veldig elegant ved å ha flere partnere som solgte produktet. Så skulle en partner gå konk, eller samarbeidet går dårlig, så finnes det nok av andre å ta av.
I tillegg var all kildekoden deponert i en såkalt Escrow-avtale. Om EPiServer selv gikk konkurs så ville alle kunder og partnere få tilgang til kildekoden.
Ja, en slik løsning er jo en klar forbedring og i prinsippet leverandøruavhengig.
Men likevel:
1. Gjenbruk:
Ferdig løsning kan ikke fritt brukes videre av alle de andre kommunene.
2. Spesialtilpasninger:
Dersom kommunene ønsker videre tilpasninger (uavhengig av behov fra andre kommuner) vil i mange tilfeller til og med partnerne komme til kort: Det vil veldig ofte være nøye avgrensede deler av koden som kun er tilgjengelig gjennom API for partnerne og som gjør at disse alltids må gjøre API-spesifikke “workarounds” for å få til spesialtilpasninger.
Dette gjelder i høyeste grad .NET-programmering mot web. Der må man enten greie seg med HTML fra 2001 (bokstavelig talt) som spyttes ut fra f.eks. tableGrid og lage workarounds eller produsere helt egne UserControls for tabeller (som jeg gjerne skulle delt med andre), for det meste fra bunnen av, for å få det til å kjøre fort nok.
Her er det dessverre ingen muligheter for å “gå til kilden” for å reparere (de ofte små) problemene og resultatet blir at det enten lages en workaround eller en separat løsning fra bunn.
Eksempelet er kanskje ikke det beste men er vel for meg kanskje noe av det som gjorde at Ting Tok Tid når det egentlig ikke var nødvendig.
(Jeg kan heller ikke ta med meg forbedringene vi gjorde til neste arbeidsgiver for å kunne gjøre jobben raskere og bedre der, ei heller kan andre benytte seg av det.)