Notatet behandler både hvilke udfordringer der er ved open source, men også hvilke muligheder der er at finde, hvis regeringen i højere grad satser på open source.
Notatet kommer med en række konkrete anbefalinger til, hvordan strategien kan fremskyndes, og blandt andet opfordres regeringen til at yde bidrag til konkrete open source projekter.
Find rapporten her: http://www.dhs.gov/sites/default/files/publications/Open%20Source%20Software%20in%20Government%20%E2%80%93%20Challenges%20and%20Opportunities_Final.pdf
Herunder har jeg oversat "Executive summary" (ledelsesresume):
Open Source Software (OSS) kan defineres som "software, hvor kildekoden er menneskelig læsbar, klar til brug, studie, genbrug, ændring, forbedring, og videredeling".
Dette dokument "belært af erfaringer" identificerer centrale udfordringer og muligheder i regeringens anvendelse af OSS, så de uhensigtsmæssige forhindringer kan imødegås eller afbødes. Disse udfordringer og muligheder er identificeret igennem interviews af OSS eksperter, leverandører og potentielle brugere; brugere omfattede både eksterne konsulenter og offentlige ansatte. Disse interviews blev udført og bearbejdet som en del af Department of Homeland Security (DHS) videnskab og teknologi (S & T) Direktoratets Homeland Open Security Technology (HOST) projekt.
De Interviewede personers kommentarer fremhæver følgende temaer og anbefalinger til regeringen (ingen prioritet underforstået):
1. Aktuel OSS anvendelse og udvikling i regeringen
Skabe og distribuere succeshistorier som "Case studies", så andre kan bygge videre på disse erfaringer (f.eks, som eksempler som kan kopieres).
2. Træghed
Modvirke frygt for forandring ved at offentliggøre casestudier og mindske frygten for overgangsomkostninger ved at øge fokus på modularitet og standarder.
3. Frygt for lav kvalitet eller malware
Sørg for, at regeringen og dens samarbejdspartnere forstår, at OSS kan resultere i højere kvalitet på en mere gennemsigtig måde, og at der er måder til at evaluere OSS.
4. Bekymringer om kommerciel support og garantier
Sikre, at flere offentligt ansatte og konsulenter er opmærksomme på, at der er mange muligheder for support og garanti
af OSS, herunder egen support.
5. Indkøb
Giv incitamenter til regeringens programkontorer og konsulenter til at bygge samarbejdsfællesskaber og til at dele koden. I udbudsgivning bør det ikke antages at tilbudsgiverne har en bestemt forretningsmodel og bør ikke pålægges unødigt papirarbejde. Regeringen bør kræve deling af software og frigivelse software som OSS som standard, hvis det blev udviklet med offentlige midler. Dette kan forudsætte ændringer i de kontraherende strategier.
6. Certificering og Akkreditering (C & A)
Koncentrere C & A indsats på risikostyring i stedet for at gennemføre ufleksible processer. Del C&A-data og tillad at at benytte data hvor det er muligt (fx ved at være vært en for en "summer of C & A" begivenhed). Sikre, at alle relevante parter, herunder OSS leverandører, er involveret, når regeringen skal udvikle relaterede specifikationer (f.eks Common Criteria Protection Profiles). Regeringen bør investere i sikkerhedsevalueringer af centrale OSS-projekter.
7. Standarder / interoperabilitet Skift fra proprietære formater og protokoller til Modulære systemer og åbne standarder, da dette gør overgang til alternativer, herunder OSS, muligt. Regeringen bør tage en mere aktiv rolle i udviklingen af disse åbne standarder og udvikling af OSS implementeringer af dem. Et specifikt område der blev særligt fremhævet, var Security Content Automation Protocol (SCAP) og Open Vulnerability and Assessment Language (OVAL) specifikationerne, hvord er er et behov for OSS-værktøjer til at understøtte OVAL data
8. Udfordringer ved frigivelse af kode fra regeringen
Forenkle processer for at frigive software (herunder ændringer) udviklet ved hjælp af offentlige midler. Klarlægge at frigivelsen ikke forpligter regeringen til at supportere det eller bruge det selv, og det at identificere forfattere er acceptabelt. Fremskynd regeringens interne revisionsprocesser, især for eksportkontrol, og modvirk at der unødigt skabes nye konkurrerende projekter (aka "forks"). Når der frigives nye OSS-projekter til offentligheden, bør regeringen anvende eksisterende samarbejdsfora (softwareudviklingssites) med offentlige adgang. Regeringen skal støtte op om bred deltagelse, undersøgelse, og aktiv udvikling.
9. Behov for vejledning
Opret vejledning om evaluering af OSS. Dette bør omfatte vejledning om virkningen af OSS-licenser (såsom General Public License (GPL), den mest udbredte OSS licens), med henblik på at bidrage tilbage til OSS samfundet, og for at frigive nye offentligt finansierede projekter som OSS.
10. Behov for uddannelse
Tilbyd undervisning i OSS generelt; om intellektuelle rettigheder og licenser (til både offentligt ansatte og konsulenter); i offentlige indkøb (for potentielle leverandører); og i Certificering og Akkreditering (C & A).
Vi forventede at mange udfordringer gik på sikkerhed eller forestillinger om sikkerhed. Vi fandt disse, men mange af udfordringerne var på helt andre områder. Ikke desto mindre er forestillingerne om at OSS ikke er sikkert nok" vigtige, idet misforståelser kan føre til uhensigtsmæssig brug, og usikre implementeringer
For at maksimere udnyttelsen af begrænsede ressourcer, skal den amerikanske regering løse disse udfordringer for at reducere de unødvendige barrierer for brugen og udviklingen af OSS. Mange af disse udfordringer kan løses alene ved at indføre uddannelse og vejledning om OSS for forskellige roller. Den amerikanske regering bør også overgå til øget gennemsigtighed og åbenhed. Hertil kommer at flere interviewpersoner understregede, at indkøbskontrakterne bør kræve at software og C & A materialer, der er udviklet med offentlige midler skal udvikles som fællesskaber og deles bredte, overdrage de fulde rettigheder til data til regeringen (medmindre det kan godtgøres, at færre rettigheder er til gavn for regeringen som helhed), og frigives, som OSS som standard.