Kan vi undgå monopol?

Betal for udvikling og kræv at det bliver open source.
Så bliver drift ikke nær så dyrt og man binder sig ikke til leverandøren for en årrække.
Hvis man køber endnu en closed source løsning er man naiv eller har glemt hvor meget en 10 årig investering skal give i ROI for en IT-virksomhed.

Kræv at staten/kommunerne har retten til source-koden og lav så meget så muligt af den open source, således at mindre firmaer kan byde ind med rettelser. Ansæt en person med en it-uddannelse og/eller en som har prøvet at arbejde som udvikler til at styre projektet.

Det er selvfølgelig et stort problem for leverandøren af systemet, hvis han ikke har rettigheden til source-koden, da de personer der rent faktisk udvikler systemet bare kan skifte til en konkurrerende leverandør, hvis de ikke synes de får ordenlig løn eller har ordenlige arbejdsforhold. Pga. denne konkurrence er det derfor min erfaring at en leverandør meget sjældent er interesseret i at hans program er open source (i og med at direktøren af firmaet eller projektlederen normalt ikke er udviklere selv). Men det kommer jo stort set alle andre til gode.

Netop derfor burde KMD være forblevet stats eller kommune ejet. Så kunne kommunerne sammen styre retningen af udviklingen.

Om KMD så den gang blev ledet forkert eller andre årsager til monopolistiske høje priser for kommunerne ved jeg så ikke en disse om.

Når man betaler for udvikling af et system skal man sikre sig at man har ejerskabet over:

Datamodellen
Interfacemodellerne
Process beskrivelserne
Sourcekoden

Så i skal skrive i jeres kontrakt at i selvfølgelig har ejerskabet til disse komponenter. De kan så genbruges til næste udbudsforretning da I jo selv ejer komponenterne.

Om det så skal OpenSovses, i Public domain eller noget andet kan i så som kunde selv beskrive, men da vi (os alle sammen ) har betalt for funktionerne kan I nok lige så godt overføre det til Public Domain.

Lige præcis! Når jeg som skatteborger er tvunget til at betale til en softwareløsning, skal koden selvfølgelig som udgangspunkt fære fuldt offentlig, dvs. tilgængelig for mig, der har betalt.

Kræv, at alt på maskinerne er Open Source.

Kræv, at funiktionalitet primært tilvejebringes, ved at bruge alment anvendelige Open Source frameworks (f.eks. Databasesystemer, web-frameworks, m.m.). Hvis de mangler funktionalitet, er opgaven at udvikle de pågældende moduler, til at kunne understøtte funktionaliteten - helst ved at få rettelserne indført i de officielle pakker (ja, deltage i det eksisterende Open Source miljø) - alternativt lave jeres eget (midlertidige?) offentligt tilgængelige fork af projektet.

Hold mindst muligt af koden for jer selv, men lad det være kommunernes/statens ejendom. De firmaer, som byder på opgaven, er ikke ejere af koden, de stiller basalt set blot udviklere til rådighed.

Forestil jer, hvis flere nationers myndigheder samarbejdede med at udvikle åben software, som de alle kunne bruge, med mindre lokale tilpasninger - der bliver immervæk brændt en del skattekroner af på softwarelicencer og des lige på verdensplan - de kunne lige så godt blive kastet i retningen af åben software, hvor meget af basissoftwaren også ville være anvendelig for de skatteborgere, som alligevel har betalt for det.

Præcis!

"Del og hersk" er et godt gammelt datalogisk princip - bestil modulariserede løsninger (i modsætning til ét gigantisk system) hvor komponenter kan udvikles og udskiftes uafhængigt, og sæt jer benhårdt på især interfaces (protokoller, formater mv.) som nævnes ovenfor.

Måske kræver det flere ressourcer up front, men på sigt undgår i monopolisering og deraf følgende opskruning af priser.

Da der ikke er noget der hedder Public Domain i dansk jura, er det ikke en mulighed. Men igen, hvis i sørger for ejerskab over især snitflader (og tilhørende specifikationer) er det jo ikke et problem at gøre dem alment tilgængelige, hvorefter en open source løsning nemt kan poppe op i en udbudsrunde...

Forresten, til mit første indlæg. Fordelen ved at udvikle mest muligt som frit tilgængelig Open Source programmel, som andre (privatpersoner/firmaer) også kan bruge (alt fra åbne kontorpakker, databasesystemer til regnskabs/økonomisystemer, m.m.) er, at der så vil være væsentlig flere "nørder" derude, som vil hjælpe med at vedligeholde og udbygge jeres progrmpakker.

Der tror jeg nu godt man kan undgå - men bestemt ikke ved at lave endnu et kæmpeudbud. Eller ved på forhånd at stille en masse begrænsninger op af frygt for at skabe endnu et monopol.

At forfølge endnu en mega-udbuds-plan, og så forvente at der kommer andet output end en monstrøs, monolitisk, de-facto 'monopolær' løsning ud af det (som vi jo efterhånden har set mere end 1 gang) virker en kende fakta-resistent set fra mit bord.

At starte med drakoniske leverancebetingelser kommer nok heller ikke til at løse problemet - det kommer langt mere sandsynligt til at føre til en massiv risikoinddæknings-strategi fra de leverandører som ender med at turde byde (og så ender vi med endnu en omgang langtrukkent juristeri når kastanjerne skal rodes ud af ilden).

Man kunne måske med fordel i stedet anvende et standard-trick fra matematikken/fysikken som f.eks. bruges til at håndtere 'gordisk-knude' problemstillinger: redefiner problemet - herunder ikke mindst: Simplificer problemet.

Til en begyndelse kunne man gribe i egen barm og se på hvor mange af de eksisterende arbejdsgange som i virkeligheden kunne løses med standard software. Dernæst kunne man se på hvor mange af de tilbageværende arbejdsopgaver som kunne laves om så de kunne løses med standard software. Endeligt var det måske en mulighed at se på om der er (pre-digitaliserings) lovgivning som modarbejder muligheden for at bruge standard software, og som måske kunne moderniseres en anelse så det ikke var så stor en barriere.
Alt sammen noget som kan udføres uden endnu et højrisiko-udbud. Og lur mig om ikke denne proces dels vil afsløre en del lavthængende frugter, dels vil være et glimrende udgangspunkt for at angribe de tilbageværende problemstillinger - og hvordan man, i småbitte bidder, vil sætte custom-strøm til disse.
Måske endda afprøve en indkøbsmodel hvor flere leverandører faktisk leverer konkurrerende implementeringer (af de tilpas små bidder), og hvor man så kan vælge den bedste - i stedet for at lade leverandørerne konkurrere om hvem som er bedst til at besvare udbud.

…and then I woke up, but the dream was really nice…

Hvor vil alle de systemer skulle driftes?
Sådan som jeg forstår det i dag bliver de fleste systemer også driftet hos KMD.
Hvem vil skulle overtage driften? Skal den udliciteres eller vil kommunerne selv skulle stå for det?
Og hvis driften outsources hvad så med opbevaring af personfølsomme data som fx. CPRnummer?

Sådan som jeg ser det er det ikke kun på software siden der skal kigges.
Det er over det hele.

Dette kan driftes over alt i EU, hvis leverandører giver garanti for at data ikke forlader EU. Om man så stoler på leverandøren er en helt anden sag. F.eks er det nok usikker om et amerikansk firma kan undsige sig Patriot Act. Og mit gæt er at Kinesiske, indiske, russiske eller filippinske firmaer (og andre for den sags skyld) ej heller kan modstå et tryk fra deres regeringer / efterretningstjenester om udlevering af data.

Men en god kryptering (+2048, med nøglen i Danmark) kan selvfølgelig løse en del af de problemer.

Ligesom de vist laver med det nye bibliotekssystem - hvor koden er oprettet i et projekt, og andre kommuner kan hente koden - og tage del i udviklingen.

På den måde vil det en kommune laver - kunne bruges og videreudvikles af andre kommuner til deres behov - og inden længe skulle projekterne gerne have commit'ere fra div. kommuner der har behov for ændringer, og sikkert flere kommuner som brugere - der kan bruge det som det er.

Sørger man for at tænke oversættelse ind - kunne kommuner i andre lande, sikkert også bruge nogen af systemerne - og det ville kun gøre det hele mere fleksibelt og fremtidssikret for alle.

Ægte Open Source handler IKKE kun om at koden er der - men om måden man gør tingene på :)

Som det er fremhævet er det danske marked lille, så det kan være svært at undgå en solo-leverandør situation hvis bare der skal være lidt stordriftsfordel. Men det kunne man vel også leve med hvis man får testet priserne gennem gen-udbud hver 4.-6. år og får et sekventielt monopol.

Kunsten i den model er at skabe porterbarhed og sikre at skiftet fra den første leverandør til det næste er med i kontrakten med den første leverandør. Sådan at den første leverandør ikke har opfyldt sine kontratuelle forpligtelser før der er bestået en afleveringsprøve til den næste leverandør.

Solo-leverandør situationen er god til at skabe kritisk masse og lav initiel pris. Man skal bare ikke blive i situationen årti efter årti. Der skal være fokus på governance, specifikationer og leverandørstyring.

Jeg er måske mere spændt på hvilke tiltag der kan gøres for at få et bredt ansøgerfelt der kan magte opgaven. Indeholder kravspecifikationen f.eks. beskrivelse af hvordan man udregner ydelserne, eller vil man kun fokusere på dem der har sådan en ekspertise, for så er der nok ikke nogen over eller ved siden af KMD. Går man efter eet stort udbud, eller udbyder man f.eks. først platform, derefter tilpasning og så drift?

Jeg tror ikke at det umiddelbart er muligt at bryde KMD's monopol. Heller ikke hvis systemerne bliver open source og overholder standarder. Problemet som jeg ser det er ikke af teknisk karakter, men af politisk. Ud over krav specifikationerne til systemerne følger der også en bunke lovtekster som skal overholdes. Det giver komplekse systemer fordi lovgivning sjældent er logisk funderet og bare lægger til hvad der var i forvejen. Jeg kan huske at Ny Alliance gerne ville have indkomst skat på 40% til alle og afskaffe fradrag. Det er sådan nogen tiltag der skal til for at gøre det offentlige simplere og muliggøre uafhængighed af leverandører.

Det er en rigtig god kommentar. Der synes at være en vis politisk forståelse for at effektiv digitalisering kan have en sammenhæng til regelforenkling. For nyeligt er underskriftskravet blev ændret så Digital Post har samme vægt som fysisk post. Men der skal jo endnu mere til af den slags. Hvis man f.eks. tror at folkepension er enkelt, så skal man blot tage fat i brøkpension for at se et patchwork af overgangsordninger, ændringer mv.