Gå videre til hovedindholdet

Alle offentlige IT-projekter burde open sources (del 2)

Sidst omgang blev noget længere end jeg lige havde regnet med.

Har du læst om Open Source - ellers bør du gøre det nu: http://www.digst.dk/~/media/Files/Arkitektur%20og%20standarder/Software/ITST_OSS_i_det_offentlige.pdf

Det lyder jo altsammen meget godt, det der står i brochuren fra Digitaliseringsstyrelsen. Alene ordlyden burde jo få alle til at springe på Open Source-vognen med det samme, men det lader mere til at være en stor hensigtserklæring. Det er tilsyneladende stadig tilladt at lave lukkede softwareløsninger til det offentlige.

Skal alt være Open Source/baseret på åbne standarder? I mit hoved, ja helst! Lige fra web- og databaseservere ned til det software som slutbrugeren sidder og arbejder med.

Nej, jeg ved godt det er utopi - man skal hverken tage brødet ud af munden på firmaer, der laver closed-source software, eller påtvinge brugerne en dårligere slutløsning, bare fordi den er Open Source. Men det skal selvfølgelig overvejes grundigt, om ikke en given arbejdsopgave kan løses af et Open Source-baseret produkt. Det er som minimum død-og-pine nødvendigt, at man kan importere/eksportere data som alm.tekst.

Softwarebørsen som der refereres til, indeholder kun brudstykker af software. Hvor er alle levningerne efter POLSAG, ProAsk osv? Jeg vil da se, hvordan man forsøgte at skrue systemet sammen. Måske kan man skrælle nogle lag af, og kitte noget sammen

Der skal ske forbedringer i offentligt IT-regi. Der skal gøres op med gamle dogmer og prøves nyt. Man vil komme til at brænde nallerne på det nye også - men vigtigst er det, at man skaber forbedringer og gør erfaringer.

Hermed mit forslag til, hvad man kan gøre fremadrettet

  • Alle offentlige projekter og herunder dokumentation skal være Open Source
    Den åbne kode sikrer, at der kan bygges videre på det fundament, der allerede er skabt. Fremtidig leverandører risikerer dermed ikke at stå på bar bund, når der skal opdateres eller udvikles nyt. Programmeringskode kan også blive "for gammelt", så det ikke er værd at bygge på. Men der er som regel altid elementer, der kan bruges eller læres fra, så man undgår at starte helt fra år 0. Åben kode decentraliserer samtidig al know-how. Det tager stadig tid at sætte sig ind i, men man er ikke afhængig af at skulle spørge den gamle leverandør til råds.

    Der skal være krav om dokumentation i koden, og dokumentation skal gennemlæses, og revideres løbende. Der er ingen programmører, der gider lave dokumentation, men så ansæt nogen der gør.
  • Staten bør vedligeholde et offentligt distribueret versionsstyringssystem
    Al kode der nyudvikles til det offentlige, bør placeres i et offentligt repository i Open Source-versionsstyringssystemer som GIT/Mercuial, på servere som staten og underleverandører driver. Det sikrer nem adgang til downloads og kodegennemsyn. Det er også en stor hjælp hvis tredjepart hjælper med f.eks ekstra moduler.
  • Staten afprøver at køre flere projekter via agile udviklingsmetoder.Agile udviklingsmetoder er "det nye sort" mange steder i softwarebranchen. De teoretiske fordele er direkte brugerinddragelse og et mindre rigidt udviklingsforløb, fordi man arbejder mere kortsigtet, og ikkeforsøger at dokumentere alt ned til mindste detalje fra start, som det er tilfældet med vandfaldsmodellen. De agile udviklingsmodeller stiller større krav til kunden, fordi der skal bruges mere brugerinput, men det bør ultimativt resultere i bedre softwareløsninger. Agil udvikling er ikke en hellig gral, men et godt fundament, når der udvikles IT til mennesker.

    http://da.wikipedia.org/wiki/Scrum
  • Data skal kunne importeres / eksporteres fra alle systemer i klartekst
    Staten iværksatte flere initiativer i 2008 vedr. åbne dokumentstandarder. I dette bilag fra 03.03.2014 http://digitaliser.dk/resource/2595559 fremgår det ret tydeligt at staten er opmærksom på at overholde egen målsætning ift. åbne dokumentstandarder (ODF, OOXML, PDF). Jeg kan dog ikke umiddelbart finde nogen undersøgelse af, hvor stor succesraten er, men det er da altid noget der er opmærksomhed omkring betydningen. Udfordringen ligger så i, at få folk til at bruge det

    Staten har etableret OIOXML, FESD, og OIOUBL som offentlig standard for dataudvekslingsformater. Fint, formaterne er ukodede og i klartekst! Men er disse standarder indbyggede i ALLE nye offentlige løsninger, eller tillader staten at leverandøren "bidrager" med sit eget dokumentformat? Der skal være fokus på, om data kan importeres/eksporteres fra alle systemer... Også om 30 år. Indenfor IT går tingene stærkt. Jeg finder personligt XML-formatet brugbart, men vælger ofte JSON-formatet, når jeg skal overføre data mellem to servere, fordi transmissionstiden formindskes, da data i JSON formatet fylder mindre. Men det gør ikke XML-standarden ubrugelig
  •  Offentlig adgang til datasæt
    Sæt data fri ... Kort og godt... Det koster penge at drive servere med offentlig data, men det lønner sig måske i sidste ende, når det inspirerer firmaer og privatpersoner til at lave løsninger, som staten måske ikke engang havde tænkt på/har økonomi/interesse for.

    (tilføjer flere punkter løbende)
Lyder det helt tosset? Det ultimative mål er, at skabe løsninger, der kan bygges videre på, samtidig med, at flere inviteres til at deltage i processen. Der er nogle kameler der skal sluges, men det kommer til at gavne alle i sidste ende. 

Kommentarer

Populære opslag fra denne blog

Brokkeindlæg - om Open Source vs. Closed Source

Jeg er ikke negativ i dag - har bare lige nogle ting der skal ud... :-) Jeg er træt .. træt af at høre om alle kompatiblitetsproblemerne, der er med Open Source-software. Der er så mange artikler på nettet, hvor diverse firmaer/organisationer "disser" Open Source-produkter, fordi det er svært at vende folk til at bruge det nye Open Source-system frem for det de er vant til. Man hører tit om "NU skifter by/afdeling/skole X til Open Source", og så et halvt år senere - så hører man "Jaeh.. vi prøvede, men det viste sig ikke at være en rentabel beslutning". En af årsagerne, tror jeg, er oftest at man glemmer, at hvis man skal indføre Open Source i sin organisation, så skal ALLE være indstillet på at skifte, og være indstillet på at det kræver en indkøringsfase og nogle kompromis'er. Lad os lege du har en virksomhed (måske har du) ... Din kontordame, lad os kalde hende Magda... Hun har måske været vant til Microsoft Word i 14 år, nu skal hun pludselig

Danmark i fare for at blive hægtet af på det semantiske web?

Forleden læste jeg i Randers Amtsavis, en lille artikel om det semantiske web. Det semantiske web er et begreb (og et buzzword) for "et intelligent internet" - altså et internet der kan hjælpe dig med at træffe logiske valg, udfra dine søgninger, og din handlemåde på nettet. Man kan sige, at når du ser Google tilpasse reklamerne efter hvilket søgeord du har skrevet, så er det en slags forsmag på det semantiske web, men det indeholder rigtig meget andet. Det lyder meget abstrakt, så lad os tage et eksempel: Forestil dig, at du sidder og leder efter en billig afgang fra Billund, fordi du skal på forretningsrejse. Når du har valgt en destination, dukker hjemmesiden op og spørger dig, om du også ønsker at leje et hotelværelse under dit ophold, fordi den kan læse i din kalender (som du selvfølgelig har online), at mødet varer fra 18-22 (tænkt eksempel), hvorfor du nok næppe springer ud i din bil for at køre hjem, hvis der er langt. Forestil dig så at du sletter mødet i din ka

Lille morgengrin på Kristi "Flyvdag"

Der skal ikke så frygtelig meget til at more mig, specielt ikke sådan en Kristi Himmelfartsdag. Jeg går med en lille spirende spiludvikler i maven, og derfor har jeg kastet mig over at prøve at udvikle mobilspil til Android. Derfor hentede jeg her til morgen kildekoden til AndEngine, en open source android spilmotor. For ligesom at forstå logikken bag, kigger jeg som regel i koden først. Det er den store force ved Open Source-projekter at man kan det. Stor var morskaben da jeg så en revisionsændring i kildekoden (-// betyder noget er fjernet fra tidligere revisioner, + tilføjet i ny) .. -// case Surface.ROTATION_0: -// /* Nothing? */ -// break; -// } + case Surface.ROTATION_0: + /* Nothing. */ + break; + } Nothing? .. Yes.. Nothing :)