Avatud lähtekood ei tähenda vastutusest loobumist

Lähtekoodi avaldamine muudab seda, kes saab seda uurida, taaskasutada ja täiendada. See ei vähenda praktilist tööd, mis on seotud teadmisega, mis on...

Avatud lähtekood ei tähenda vastutusest loobumist

Hoidla on avaus, mitte lõpp

Avatud lähtekoodi kohta liigub lohutav väike lugu. Rühm avaldab koodi. Teised inimesed saavad seda lugeda. Koodist saab ühine hüve või vähemalt kasulik ühine nuhtlus. Vastutus hajub rahvahulka.

Esimesed kaks lauset võivad tõsi olla. Viimane ei ole. Avalik hoidla võib laiendada kontrollimist, taaskasutust ja panustamist. See võib anda organisatsioonile selgema väljapääsutee kui suletud teenus. See võib võimaldada avaliku sektori asutusel komponenti uurida ilma tarnijalt luba küsimata. Ükski neist ei vasta küsimusele, mis saabub tavalisel teisipäevahommikul: milline versioon siin töötab, millise litsentsi all, millise konfiguratsiooniga ja kes hakkab tegutsema, kui turvahoiatus puudutab just seda tarkvara?

Avatud lähtekood muudab vastutuse kuju. See ei muuda vastutust vabatahtlikuks. Haldajal on endiselt otsuseid teha väljalasete, turvateadete, toetatud versioonide ja litsentseerimise kohta. Organisatsioonil, kes pakendab komponendi, on endiselt otsuseid teha päritolu, uuenduste ja selle kohta, mida ta oma kasutajatele räägib. Kasutuselevõtjal on endiselt otsuseid teha inventari, kokkupuute, konfiguratsiooni, juurdepääsu ja taastamise kohta. Litsents annab õigused ja tingimused. See ei paku valveskeemi.

See on oluline, sest avatud lähtekoodist on saanud tavaline infrastruktuur. See on operatsioonisüsteemides, brauserites, avalikes teenustes, teadustöö vahendites, tööstussüsteemides ja teekides, mis muudavad toote näiliselt iseseisvamaks, kui ta tegelikult on. Küps küsimus ei ole seega see, kas organisatsioon on avatud lähtekoodi poolt või vastu. See on see, kas ta suudab kanda vastutust, mille loob tarkvara, millest ta on otsustanud sõltuda.

Euroopa poliitika on hakanud seda eristust selgemalt kirjeldama. Küberturvalisuse määrus reguleerib digielementidega tooteid ja sisaldab eraldi rada vaba ja avatud lähtekoodiga tarkvara haldajatele. See rada tunnistab, et isik või organisatsioon, kes pakub püsivat tuge vaba ja avatud lähtekoodiga tarkvarale, võib omada tegelikku kohta turvaahelas. See ei muuda iga vabatahtlikku, kes koodi avaldab, tootjaks. Samuti ei luba see ärilisel osalejal peituda avaliku hoidla taha, kui see osaleja toob toote turule.

Praktiline tagajärg on meeldivalt ebaharilik. Kohelge iga sõltuvust kui asja, mis tuleb nimetada, mõista ja mille eest hoolt kanda. See ei ole rünnak avatud lähtekoodi vastu. See on distsipliin, mis laseb avatud lähtekoodil kasulikuks jääda ka siis, kui uudsus on kadunud.

Mida avaldamine tegelikult muudab

Lähtekoodi kättesaadavus muudab korraga mitut asja. Lugeja saab uurida teostust, mitte järeldada seda turunduslehelt. Meeskond saab ehituse taasesitada, kui ehituse juhised, sõltuvused ja keskkond seda võimaldavad. Tarnijat saab kergemini asendada, kui litsents ja liidesed seda lubavad. Teadlane saab väidet testida, turvameeskond saab plaastrit üle vaadata ja avalik ostja saab küsimusi esitada ilma musta kasti põhiseadusliku põhimõttena käsitlemata.

Need on olulised avalikud hüved. Need on ka tingimuslikud. Kood, mis on nähtav, kuid mida on võimatu ehitada, on vähem kontrollitav, kui esmapilgul paistab. Kood, mida saab ehitada, kuid millel puudub selge litsents, jätab taaskasutuse ebakindlaks. Kood, mis on litsentseeritud, kuid kokku pandud tundmatutest sõltuvustest, kannab endas päritoluprobleemi. Kood, mida hooldatakse ainult harus, mida keegi ei suuda tuvastada, ei muutu usaldusväärseks pelgalt sellepärast, et hoidla leht on olemas.

Open Source Initiative kirjeldab avatud lähtekoodi heakskiidetud litsentsi ja õiguste kogumi kaudu, sealhulgas juurdepääsu lähtekoodile ning vabadust seda sätestatud tingimustel edasi levitada ja muuta. See määratlus keskendub teadlikult lubadele. See ei ole teenustaseme leping, turvasertifikaat, sobivuse garantii konkreetse avaliku ülesande jaoks ega kinnitus, et komponenti hooldatakse määramata aja jooksul. Nende lubaduste puudumine ei ole määratluse viga. See on põhjus olla täpne selle suhtes, millele organisatsioon tugineb.

Kasulik on eristada nelja küsimust, mis sageli ühte sõbralikku sõnasse kokku pannakse. Kas lähtekood on kättesaadav? Kas see on litsentsitud kavandatud kasutuseks? Kas organisatsioon suudab kindlaks teha, kust kood ja selle sõltuvused pärinevad? Kas keegi kannab aktiivselt seda operatiivset tööd, mida see juurutamine nõuab? Jaatus esimesele küsimusele ei vasta ülejäänud kolmele.

See eristamine muudab ka vestlused vähem teatraalseks. Hankemeeskond ei pea repo suhtes entusiasmi üles näitama. Ta peab teadma, kas komponent sobib süsteemile, mida ta ostab või haldab. Insenerimeeskond ei pea vabandama lubava litsentsi kasutamise pärast. Ta peab teadma, kuidas täita litsentsiteateid, säilitada nõutud materjale, uuendada sõltuvusi ja reageerida avalikustatud probleemile. Õigusmeeskond ei pea saama väljalaskehalduriks. Küll aga vajab ta teed väljalaskeprotsessi enne, kui litsentsiprobleemist saab avalik parandus.

Lähtekood võib läbida mitu kätt. Valige kiht, et eristada avaldamise, pakendamise, toote paigutamise ja juurutamise vastutust.

Litsents on piir, mitte ilmaennustus

Litsentse koheldakse mõnikord haldusliku üksikasjana, nagu algaks õigustöö alles pärast inseneritöö lõppu. Tegelikult kujundavad litsentsivalikud inseneriotsuseid algusest peale. Need mõjutavad seda, kas komponenti saab kombineerida teise komponendiga, kas teatised peavad levitamisega kaasas käima, kas muudetud lähtekoodi tuleb teatud asjaoludel pakkuda ja kas meeskond suudab täita tingimusi, mis on seotud õigustega, mida ta soovib kasutada.

See ei tähenda, et iga insener peab saama autoriõiguse spetsialistiks. See tähendab, et organisatsioon vajab usaldusväärset tõlget selle vahel, mida ta tarkvaraga ehitab, ja kohustuste vahel, mida ta võtab selle tarkvara levitamisel, majutamisel või muutmisel. Tõlge peab toimuma siis, kui faktid on veel kättesaadavad: milline pakett valiti, millist versiooni kasutati, kas seda muudeti, kuidas see oli lingitud või kaasatud, millega see kaasa saadetakse ja milline on kavandatud levitamistee.

Universaalset litsentsivastust ei ole. Lubav litsents võib taaskasutuse lihtsaks teha, nõudes samal ajal teatisi ja autoriõiguse teksti säilitamist. Vastastikune litsents võib levitamisele või muutmisele lisatingimusi lisada. Kahe litsentsiga kokkulepe võib nõuda organisatsioonilt valikut ärilise või konkreetse avatud lähtekoodi tee vahel. Organisatsioon ei tohiks kohustusi järeldada litsentsi hüüdnimest, paketihalduri märgist või kolleegi poolt poolenisti meelde jäänud loost aastast 2014. Ta peaks lugema litsentsi teksti, fikseerima otsuse ja küsima nõu, kui kavandatud kasutus on ebakindel.

Litsentsinõuete täitmine ei ole samuti pelgalt tseremoniaalne tegevus, mis viiakse läbi väljalaskenädalal. Tarkvara koostisosade loetelu (SBOM), sõltuvuste inventuur ja väljalaskeprotokoll võivad muuta hilisema küsimuse vastatavaks: mida see artefakt sisaldas? Kuid loetelu on kasulik ainult siis, kui see kirjeldab kindlaksmääratud artefakti, versiooni ja kuupäeva. Tabel nimega dependencies-final-final.xlsx ei ole päritolusüsteem. See on arheoloogiline kiht.

Avaliku sektori asutuse jaoks on see enamat kui majapidamistöö. Asutusel võib tekkida vajadus säilitada võime selgitada, miks konkreetne komponent valiti, millised tingimused seda reguleerivad, kuidas seda asendada saab ja mis juhtub, kui hooldus lõpeb. Äriorganisatsiooni jaoks mõjutavad samad andmed lepingulisi kohustusi, tootevärskendusi ja kliendisuhtlust. Väikese meeskonna jaoks on mastaap erinev, kuid loogika ei muutu. Kui projekt ei suuda tuvastada levitatava koodi litsentsi, ei saa ta ausalt väita, et õiguslik raamistik on kontrolli all.

Vastutustundlik samm on proportsionaalne, mitte suurejooneline. Pange kirja otsesed sõltuvused. Säilitage litsentside tekstid ja nõutud teatised koos väljalaskega. Dokumenteerige olulised muudatused. Määrake uute või ebatavaliste litsentsitingimuste jaoks ülevaatuspunkt. Tehke keegi vastutavaks ebakindluse lahendamise eest. Need on tagasihoidlikud kontrollimeetmed. Nende väärtus seisneb selles, et need hoiavad ära olukorra, kus ebakindlus muutub üllatuseks pärast seda, kui tarkvara on levinud.

Hooldus on töö, isegi kui see on annetatud

Avatud lähtekoodi hooldust kirjeldatakse sageli nii, nagu oleks see isiklik voorus. Mõnikord see ongi. Inimesed vaatavad läbi plaastreid, vastavad küsimustele, pakivad väljalaskeid ja hoiavad ära vanade eelduste muutumise homseks rikkeks, sest nad hoolivad tööriistast ja selle kasutajatest. See heldus väärib austust. Seda ei tohiks kasutada ärimudelina ilma ärilise otsuseta.

Hooldus on operatiivne töö. See hõlmab otsustamist, milliseid versioone toetatakse, panuste ülevaatamist, turvateabe avaldamist, väljalaskeprotsessi haldamist, teadetele vastamist, murranguliste muudatuste dokumenteerimist, ehitustaristu kasutuskõlblikuna hoidmist ja mõnikord ka äraütlemist. Viimane osa on alahinnatud. Projekt, mis ei suuda tagasi lükata funktsioonitaotlust, toetamata platvormi või ebaturvalist otseteed, ei pruugi olla avatum. See võib lihtsalt olla rohkem avatud riskidele.

Euroopa Komisjoni avatud lähtekoodi tarkvara strateegia käsitleb avatud lähtekoodi kui viisi taaskasutuse, läbipaistvuse, koostöö ja tehnoloogilise sõltumatuse parandamiseks avalikus halduses. Need eelised sõltuvad suutlikkusest. Taaskasutus eeldab, et organisatsioon mõistab, mida ta taaskasutab. Läbipaistvus eeldab, et keegi loeb avalikustatut. Sõltumatus nõuab enamat kui kloonimisnupu olemasolu: see nõuab praktilist võimet tarkvara käitada, kohandada või sellele tuge hankida, kui algne panustaja on edasi liikunud.

Seetõttu vajab küsimus „kas seda hooldatakse?“ täpsemat sisu. See võib tähendada, et on olemas hiljutised väljalasked. See võib tähendada, et on avaldatud turvakontakt. See võib tähendada, et projekt kirjeldab toetatud versioone, ehitamisjuhiseid ja panustamisprotsessi. See võib tähendada, et organisatsioon on pühendanud sellele tööle tasustatud aega. See võib tähendada, et juurutajal on oma suutlikkus hoida hargi või asendada komponent. Need on erinevad faktid. Roheline aktiivsusgraafik võib olla kasulik tõend, kuid see ei ole hooldusleping.

Vastutustundlik kasutusevõtja peaks seetõttu otsustama, millist hooldust ta vajab, enne kui ta otsustab, mida ta loodab kogukonnalt saada. Madala riskitasemega sisemine tööriist võib sobida kokku väikese projektiga ja tagasihoidliku värskendusplaaniga. Väliselt nähtava toote keskmes olev komponent vajab selgemat tugimudelit, kiiremat haavatavuse hindamist ja väljumisplaani. Erinevus ei seisne projekti prestiižis. See seisneb eksimise tagajärgedes.

Siin tasub laenata üks väike hollandi komme: ärge ajage segi sõna „gezellig" valitsemisega. Sõbralik kogukond võib olla imeline koht, kus panustada. Sel võib siiski puududa kohustus hoida teie tootmissüsteemi töös. Organisatsioon, kes selle süsteemi tootmisse viib, vastutab erinevuse eest.

Turvaaukudest teatamiseks on vaja enne loosungit kindlat teed

Enamik inimesi nõustub abstraktsel tasandil, et haavatavustest tuleks teatada vastutustundlikult. Raske osa on vähem abstraktne. Kuhu saadab teatavaks tegija oma leiust teate? Kes selle vastu võtab? Millist teavet on vaja selle taasesitamiseks? Kes otsustab, kas see mõjutab toetatud versiooni? Kuidas töötatakse välja parandus, tekitamata tarbetut avalikku kokkupuuteakent? Kuidas kasutajatele öeldakse, mida teha? Millised allavoolu paketid vajavad värskendust? Mis juhtub, kui teatavaks tegija vastust ei saa?

Need küsimused ei ole märk umbusaldusest avatud lähtekoodi vastu. Need on töö, mille eesmärk on kohelda kasutajaid inimestena, kes vajavad vastust. ENISA töö haavatavusest teatamise ja koordineeritud haavatavusest teatamise teemal kirjeldab määratletud protsesside väärtust teatavaks tegijate, müüjate ja teiste asjaosaliste vahel. Protsess ei taga, et iga teade on õige või iga parandus kiire. See võib vähendada tõenäosust, et tõsine probleem algab oma elu jälgimata postkastis.

Projekt võib avaldada turvapoliitika, teatamise aadressi ja toetatud versioonide teabe. Need on kasulikud signaalid, eriti kui need kirjeldavad, mida teatavaks tegija võib oodata. Projekt võib olla ka liiga väike, et pakkuda olulisele juurutusele vajalikku reageerimisaega. See ei ole moraalne viga. See on planeerimise fakt organisatsioonile, kes sõltuvuse valib.

Sama kehtib ka allavoolu. Tootja ei saa mõistlikult väita, et haavatavus on kellegi teise probleem, lihtsalt sest haavatav komponent sai alguse avatud hoidlast. Kui tootja toob digitaalseid elemente sisaldava toote liidu turule, seab küberturvalisuse määrus nõuded haavatavuste käsitlemisele ja turvavärskenduste edastamisele toote suhtes kohalduvas raamistikus. Õiguslikud üksikasjad sõltuvad tootest ja rollist. Operatiivne seisukoht on lihtsam: pool, kes toote kättesaadavaks teeb, peab suutma teada saada, kas ülesvoolu muudatus mõjutab seda, mida ta on tarninud.

Siin muutub inventuur aktiivseks, mitte dekoratiivseks. See peab ühendama komponendi versiooniga, ehitisega, tooteväljalaskega ja omanikuga, kes suudab teatist hinnata. Omanik ei pea iga ülesvoolu viga üksi parandama. Ta peab otsustama, kas komponenti värskendada, leevendada, keelata, teavitada, kompenseerida või selle kasutamine lõpetada. „Me kasutame avatud lähtekoodi" on sisendi kirjeldus. See ei ole reageerimisplaan.

Vaatleme selgesõnaliselt hüpoteetilist näidet. Meeskond lisab dokumenditöötlusteenusesse teegi. Kuud hiljem tuvastab turvabülletään haavatava vahemiku. Kui meeskond on registreerinud komponendi, versiooni ja teenused, millesse see on ehitatud, saab ta alustada hindamist. Kui ta suudab ehitisi taasesitada ja värskendust testida, saab ta otsustada, kas lahendus on uuendus, konfiguratsioonimuudatus või ajutine piirang. Kui tal pole ei registrit ega omanikku, on esimene ülesanne detektiivitöö. Haavatavus võib mõlemal juhul olla identne. Operatiivne risk ei ole.

Teatamise tee ei luba, et iga probleem on väike. See muudab vastutustundliku järgmise sammu nähtavaks, kui probleem leitakse.

Päritolu on vastus küsimusele „mida me täpselt käivitame?“

Tarkvara päritolu võib kõlada nagu muuseumisildilt laenatud sõna. Aluseks olev küsimus on tavaline: kust see artefakt pärineb ja kas me suudame selle tee näidata? Tarkvara puhul võib tee hõlmata lähtekoodi hoidlaid, avaldatud arhiive, sõltuvuste registreid, ehitustööriistu, konfiguratsiooni, allkirjastusvõtmeid, ehitustarkvara ja avaldamissüsteeme. Vastus on harva üks elegantne fakt. See on kogum kirjeid, mis peavad piisavalt hästi kokku sobima, et inimene saaks otsuse teha.

Päritolu ei nõua organisatsioonilt täiusliku teadmise väitmist. See nõuab, et organisatsioon ütleks, mida teatakse, mida kontrolliti ja kus jääb ebakindlus. Korratav ehitus võib anda tugeva tõendi, et määratletud lähtekood ja määratletud keskkond tootsid vastava artefakti. Allkirjastatud väljalase võib aidata tuvastada võtit, millega väljalaset kinnitati. Tarkvara koostisosade nimekiri võib kirjeldada deklareeritud komponente. Ükski neist ei tõesta iseseisvalt, et kood on kahjutu, et iga kaudne sõltuvus on üle vaadatud või et väljalase sobib konkreetseks kasutuseks. Koos võivad need muuta hilisema uurimise palju vähem spekulatiivseks.

See eristus on oluline, sest päritolu müüakse sageli kui maagilist templit. See ei ole see. Räsiväärtus võib öelda, et kaks baidijada kattuvad. See ei saa öelda, et vastavale programmile tuleks lubada tundlike andmete töötlemist. Allkiri võib siduda väljalaske võtmega. See ei saa öelda, et võtit kontrolliv isik järgis head ülevaatusprotsessi. Inventuur võib nimetada komponendi. See ei saa öelda, kas komponent on ohutult konfigureeritud. Tõendid on endiselt tõendid, mitte otsustusvõime asendaja.

Ometi muudab päritolu puudumine otsustusvõime kehvemaks. Kui meeskond ei suuda kindlaks teha, milline lähtekoodi redaktsioon loodud paketi lõi, ei suuda ta enesekindlalt siduda ülesvoolu parandust oma teenusega. Kui ta ei suuda tuvastada kaudset sõltuvust, ei suuda ta hinnata teadet või soovitust ilma tarneahelat esmalt rekonstrueerimata. Kui ehitus annab ilma selgituseta erinevaid tulemusi, ei suuda ta öelda, kas binaar on muutunud lähtekoodi, keskkonna või sekkumise tõttu. Need on praktilised piirid, mitte puhtuse testid.

Euroopa digitaalne suveräänsus taandatakse sageli serveri asukohale. Asukoht on oluline. Sellest ei piisa. Süsteem võib töötada Euroopas, toetudes samal ajal ehitustorustikule, sõltuvuste registrile või uuenduskanalile, mida operaator ei saa kontrollida, juhtida ega asendada. Teisalt võib avatud lähtekood pakkuda reaalset teed kontrollitavusele ja teisaldatavusele, jättes samas kasutajale vastutuse selle tee kasutamiseks vajaliku suutlikkuse eest. Suveräänsus on võime tegutseda surve all, mitte konteineripildile kinnitatud lipp.

Kasulik päritolukirje peaks võimaldama tehniliselt pädeval kolleegil väljalaset edasi-tagasi jälgida. Tagasi: milline lähtekood, sõltuvused ja ehitustorustik viisid siia? Edasi: milliseid teenuseid, tooteid ja kasutajaid võib mõjutada, kui seda komponenti muudetakse või eemaldatakse? Kirje võib olla proportsionaalne. Väike sisemine tööriist ei vaja lennukiprogrammi masinavärki. Kuid see vajab piisavalt tõde, et toetada selle kasutamise tagajärgi.

Kübervastupidavuse määrus tõmbab piiri, teeseldes, et maailm pole lihtne

Kübervastupidavuse määrust võetakse sageli kokku kui uus küberjulgeolekunõuete kogum ühendatud toodetele. See on tõsi, kuid mittetäielik. Selle kasulikum panus sellesse arutelusse on rollide eristamine. Vaba ja avatud lähtekoodiga tarkvara haldaja võib olla üksus, mis pakub püsivat tuge digitaalsete elementidega toodete arendamisele, mis on kvalifitseeritud vaba ja avatud lähtekoodiga tarkvarana, ja mis on loodud tagama nende toodete elujõulisuse. Määrus seab sellele rollile tingimused. See ei kohtle iga kaastöötajat samade kohustustega nagu tootjat.

See eristus tunnistab, kuidas avatud lähtekood tegelikult toimib. Projektil võib olla üksikuid kaastöölisi, ühendus, sihtasutus, ettevõte, mis pakub tuge, levitaja, mis komplekteerib tarkvara, integraator ja tootja, kes selle tootesse lisab. Nende vastutusalad on seotud, kuid mitte vahetatavad. Kaastööline võib parandada vea. Haldaja võib koordineerida projekti. Levitaja võib selle pakendada. Tootja võib toote turule tuua. Juurutaja võib otsustada, kuidas see toode käsitleb reaalseid andmeid ja reaalseid inimesi. Avalik hoidla on nende rollide kohtumispaik, mitte õiguslik segisti.

Organisatsioonidele on kõige ohutum lugemine see, et mitte muuta määrust folklooriks enne, kui see kohaldub. Määrusel on järkjärgulised kohaldamiskuupäevad ja rollipõhised sätted. Õiguslikku tõlgendust tuleks saada kohaldatavast tekstist ja pädevast nõustamisest, eriti kui on tegemist toote, äritegevuse või turule laskmisega. Operatiivne ettevalmistus ei pea aga ootama seminari külma kohvi ja slaidiga pealkirjaga „ülevaade“. Tehke komponentidest inventuur. Tehke kindlaks, kes omab uuendusi. Säilitage väljalaske tõendusmaterjal. Seadke turvateadete edastamise tee. Otsustage, mida toetatud tähendab. Need tegevused on kasulikud, olenemata sellest, kas konkreetne klausel kohaldub täna, järgmisel aastal või üldse mitte.

Määrus väldib ka valediHHHhotomiat. See ei ütle, et avatud lähtekood on ebaturvaline. Samuti ei ütle see, et avaldamine vabastab ärilise toote turvatööst. See tunnistab, et toodetes kasutatava tarkvara turvalisusel on avalikud tagajärjed ja et tegutsejate ahel vajab selgemaid vastutusi. Täpsed kohustused väärivad hoolikat õiguslikku lugemist. Põhimõte on selge: tarkvara, mis jõuab inimesteni toote kaudu, vajab kedagi, kes suudab võtta vastutuse, kui risk saab teatavaks.

See põhimõte on teistes valdkondades juba tuttav. Avaldatud retsept ei vabasta restorani toiduohutusnõuetest. Avaldatud ehitusstandard ei vabasta töövõtjat kohustusest seda asjatundlikult kasutada. Võrdlusel on piirid: tarkvaralitsentsidel, uuenduskanalitel ja arenduskogukondadel on oma struktuurid. Kuid põhipunkt kandub üle. Avalikuks tehtud teadmine võib võimaldada sõltumatut kontrolli. See ei eemalda vastutust osapoolelt, kes toitu serveerib või ust avab.

Mida kasutuselevõtjad endale võlgnevad

Kõige kasulikum avatud lähtekoodi poliitika on sageli tegevuspoliitika, mis on maskeeritud mõistlikuks kontrollnimekirjaks. See peaks vastama, kes võib sõltuvuse lisada, milline teave tuleb registreerida, kuidas litsentse üle vaadatakse, kuidas uuendusi hinnatakse, kuidas turvateateid edastatakse ja kes võib erandi heaks kiita. Samuti peaks see vastama, mis juhtub, kui tugi lõpeb. Poliitika, mis selgitab valikut, kuid ei ütle midagi eemaldamise kohta, on vaid pool poliitikat.

Alustage üksusest, mis tegelikult loeb: juurutatud artefaktist või teenusest, mitte abstraktsest lemmikprojektide kataloogist. Iga olulise komponendi puhul peaks organisatsioon suutma leida versiooni, lähtekoodi või registri tee, litsentsi, vastutava sisemise rolli, süsteemi, milles seda kasutatakse, ja uuendamise tee. Detailide tase peaks järgima rikke tagajärgi. Eesmärk ei ole muuta iga arendajat ametnikuks. Eesmärk on takistada oluliste faktide muutumist erateadmisteks ühes sülearvutis või ühe inimese mälus.

Seejärel otsustage, milline tõendusmaterjal muudab otsust. Avaldatud teadaanne võib käivitada hindamise. Uus väljalase võib käivitada ühilduvustesti. Litsentsi muudatus võib käivitada õigusliku läbivaatamise. Mahajäetud toetatud versioon võib käivitada migratsiooniplaani. Ehitus, mida enam reprodutseerida ei saa, võib käivitada uurimise. Ilma nende käivitajateta kipuvad inventuurid muutuma ajaloolisteks dokumentideks: täpsed päeval, mil need eksporditi, ja viisakalt ignoreeritud pärast seda.

Sea omandiõigus tegutsemise lähedale. Keskne juhtimismeeskond saab kehtestada poliitika ja pakkuda asjatundlikkust. See ei saa opereerida kõiki teenuseid. Tootemeeskond võib tunda oma juurutuse arhitektuuri. Tal ei pruugi olla oskusi iga litsentsi tõlgendamiseks. Korraldus toimib siis, kui üleandmine on selgesõnaline: tooteomanik hindab mõju, turvalisus nõustab kokkupuute ja reageerimise osas, õigus- või vastavusosakond hindab litsentsitingimusi vajaduse korral, hanked fikseerivad välised kohustused ning nimetatud otsustaja võtab vastu või lükkab tagasi olulise riski. Nimed varieeruvad. Nimede puudumine on korduv probleem.

Hoia väljapääsutee. Avatud lähtekood võib vähendada lukustumist, kuid ainult siis, kui organisatsioon suudab olude muutudes ümber ehitada, hargida, asendada või toetust lepinguga hankida. Hoidla peegel, ehitamisjuhised, vahemällu salvestatud sõltuvuste tee ja nõutava konfiguratsiooni kirje võivad tunduda igav töö, kuni algne teenus pole saadaval või suhe lõpeb. Igal tööl on hädaolukordades hea maine.

Lõpuks ole jääkriskide suhtes aus. Ükski sõltuvusprogramm ei saa garanteerida, et iga haavatavus leitakse esimesena, et iga ülemvooluprojekt jääb aktiivseks või et iga litsentsiküsimus on lihtne. Juhtimise mõte ei ole lubada võimatut. See on muuta ebakindlus piisavalt varakult nähtavaks, et vastutav inimene saaks otsustada, mida sellega teha.

Mida hooldajad mõistlikult pakkuda saavad

Hooldajad ei võlgne maailmale piiramatut tööd sellepärast, et nad avaldasid kasuliku koodi. See ootus on nii ebaõiglane kui ka ebaturvaline. Projekt võib olla taaskasutuse suhtes helde, olles samas oma võimekuse osas selgesõnaline. See võib öelda, milliseid versioone toetatakse, kuhu turvaprobleemidest teatada, kuidas väljalaskeotsuseid tehakse, milliseid panuseid saab üle vaadata ja mida ei lubata. Selged piirid on kasutajatele paremad kui soe ebaselgus.

Isegi väike projekt saab operatiivset üleandmist parandada mõne püsiva dokumendiga: litsentsifail, loetav väljalaskeprotsess, turvakontakt või avalikustamispoliitika, versiooniteave, vajaduse korral sõltuvuste juhend ja selge avaldus selle kohta, kas hooldus on aktiivne, piiratud või lõppenud. Ükski neist ei loo garantiid. Igaüks neist aitab allavoolu kasutajal teha teadlikuma valiku.

Kui projektil on organisatsiooniline tugi, saab vestlus minna kaugemale. Organisatsioon saab avaldada toetatud versioonide poliitika, kirjeldada oma juhtimist, fikseerida oma väljalaske allkirjastamise tava, hoida haavatavustele reageerimise tee ja selgitada, kuidas kasutajad saavad tuge. Need ei ole maandumislehe märgid. Need on operatiivsed lubadused ja need tuleks kirjutada ainult siis, kui organisatsioon on valmis neid täitma.

Kõige ausam hooldussõnum võib mõnikord olla „me ei saa seda enda peale võtta“. See võib tähendada, et funktsioon on ulatusest väljas, platvormi ei saa testida, turvateade vajab rohkem teavet, haru ei toetata enam või väljalaskekuupäeva ei saa lubada. Selge keeldumine annab kasutajatele midagi, mille ümber planeerida. Vaikus annab neile loo, mida endale rääkida, mis on üldiselt kallim sisend.

On ka vastutus kasutajatel, kes sõltuvad projektist. Teata defektidest piisava detailiga reprodutseerimiseks. Järgi turvateed, kui see on olemas. Panusta testimisse, dokumentatsiooni, rahastusse või ülevaatamisse, kus võimalik. Ära nõua vabatahtlikult projektilt teenindussuhet, keeldudes samal ajal tunnistamast, et teenindussuhe maksab raha. Vastastikusus ei kaota erinevaid rolle, kuid see võib muuta ahela vähem hapraks.

Avatud lähtekood võib tugevdada vastutust

Pärast kõigi nende kohustuste loetlemist tekib kiusatus järeldada, et avatud lähtekood tekitab liiga palju tööd. See ei tekita. Töö on olemas olenemata sellest, kas lähtekood on nähtav või mitte. Suletud sõltuvused vajavad samuti inventuuri, litsentsiteadlikkust, turvaaukudele reageerimist, päritolutõendit ja väljumisplaani. Need lihtsalt muudavad osa tõendusmaterjalist raskemini kontrollitavaks ja osa alternatiive raskemini kasutatavaks.

Avatud lähtekood võimaldab tugevamat vastutuse hoidmist. Ostja saab arhitektuuri üle vaadata. Operaator saab säilitada lähtekoodi ja ehitamisjuhiste koopia. Sõltumatu hindaja saab väidet testida. Avalik asutus saab vältida olukorda, kus tarnija eraviisiline teekaart on ainus tee paranduseni. Kogukond saab leida ja parandada probleemi, mille üks organisatsioon märkamata jättis. Need on olulised eelised, eriti Euroopa kontekstis, kus avalik väärtus, järjepidevus ja vaidlustatavus ei ole valikuline kaunistus.

Kuid võimalus ei ole täitumine. Kontrollitavus aitab ainult seda, kes on võimeline ja volitatud kontrollima. Teisaldatavus aitab ainult seda, kes on artefaktid säilitanud ja teab, kuidas neid liigutada. Hargnemine on väljumisstrateegia ainult siis, kui selle elluviimiseks on meeskond, eelarve ja õiguslik tee. „Kood on GitHubis" ei ole järjepidevusplaan, nagu ka „failid on kapis" ei ole arhiivistrateegia.

Meie avatud lähtekoodiga seotud töö Dweve juures hoiab seda piiri silme ees. Knot on meie avalikes materjalides kirjeldatud kui allkirjastatud, rikkumist tuvastav auditijälg AI-agendi käituste jaoks, mille puhul saab saadud kirjet avaliku võtmega võrguühenduseta kontrollida. See muudab väite paremini kontrollitavaks. See ei otsusta, mida organisatsioon peaks logima, kellel on õigus kirjele juurde pääseda, kui kaua seda säilitada või kes uurib ootamatut tulemust. Need jäävad tööriista ümber tehtavateks juhtimisotsusteks. Tööriist saab tõendusmaterjali säilitada. See ei saa kellegi eest vastutavaks organisatsiooniks saada.

See on tagasihoidlik lubadus, mida tasub hoida. Avatud lähtekood saab anda inimestele rohkem tõendusmaterjali, rohkem valikuid ja rohkem ruumi panustamiseks. Sellelt ei tohiks oodata fiktiivset vabastust hooldusest, turvalisusest, litsentsimisest ega operatiivsest otsustusest.

Vastutus jääb alles ka pärast avaldamisnupu vajutamist

Lähtekoodi avaldamine on kasulik tegu. See võib kutsuda esile kontrolli, alandada taaskasutamise tõkkeid ja muuta tehnilise valiku lihtsamini vaidlustatavaks. Terves tehnoloogiakultuuris peaks olema normaalne, et avalikud asutused ja ettevõtted kaaluvad avatud lähtekoodi tõsiselt, toetavad seda korralikult ja selgitavad oma valikuid ilma ebausuta.

Avaldamisnupp ei ole aga vastutuse alt väljapääs. See ei kõrvalda vajadust teada, mida toode sisaldab. See ei plaasterda kasutusel olevat teenust. See ei säilita litsentsimärget, ei tegele avalikustatud turvaaukudega, ei hoolda ehitust ega otsusta, kas süsteem peaks kasutusel jääma. Need ülesanded kuuluvad endiselt inimestele ja organisatsioonidele, kellel on rollid, eelarved, volitused ja tagajärjed.

Hea uudis on see, et vastutustundlik praktika ei ole müstiline. Nimeta sõltuvus. Loe litsents. Säilita päritolutõend. Otsusta, kes omab uuendust. Anna turvateadetele tee. Säilita väljumisvõimalus. Ütle selgelt, mis on toetatud ja mis mitte. Kui need harjumused on olemas, muutub avatud lähtekood enamaks kui žest läbipaistvuse suunas. Sellest saab taristu, mida saab kontrollida, hooldada ja usaldada põhjustel, mis peavad vastu ka raskel päeval.

Küsimus küsimuse taga

Kui meeskond küsib, kas komponent on avatud lähtekoodiga, küsib ta sageli korraga mitut vaiksemat küsimust. Kas me saame seda usaldada? Kas me saame sellelt lahkuda? Kas me saame seda muuta? Kas keegi teine saab seda auditeerida? Kas me saame abi, kui midagi läheb katki? Litsents ja hoidla võivad aidata vastusele kaasa aidata, kuid kumbki ei suuda sellele üksi vastata. Usaldus tuleneb tõenditest, pädevusest, stiimulitest ja sellest, kuidas konkreetset juurutust hallatakse. Lahkumine sõltub liidestest, andmevormingutest, ehitusteabest ja ressurssidest. Muutmine sõltub tehnilisest suutlikkusest ja tingimustest, mille alusel muudatust teha saab. Abi sõltub tegelikust tugisuhtest või võimest ilma selleta hakkama saada.

Need eristused on kaitseks nii küünilisuse kui ka soovmõtlemise vastu. Küünilisus ütleb, et avatud lähtekood on lihtsalt tasuta töö. Soovmõtlemine ütleb, et see on automaatselt turvalisem, sest paljud silmad võivad seda kontrollida. Kumbki väide ei ütle operaatorile, mida edasi teha. Operaator peab teadma, millised silmad tegelikult asjakohast versiooni üle vaatasid, kes saab plaastrit testida, milline volitus on muudatuse tegemiseks ja kuidas tulemus mõjutatud süsteemini jõuab. Turvalisus on kontrollitud toimingute ahel, mitte vanasõna rahvahulgast.

Sama vaoshoitus kehtib ka hankimisel. Tarnijalt avatud lähtekoodiga komponendi küsimine ei muuda lepingut vähem oluliseks. See muudab küsimusi, mida hea leping saab esitada: millised ülemvoolukomponendid on kaasatud, kuidas käsitletakse teateid ja lähtekoodi kohustusi, milliseid versioone toetatakse, millised tõendid saadavad väljalaset, mis saab parandustest toetusperioodi jooksul ja millist materjali saab klient järjepidevuse säilitamiseks endale jätta. Ostja peaks väärtustama võimet kontrollida ja liikuda. Samuti peaks ta hindama selle võime kasutamiseks vajalikku suutlikkust.

Pole mingit voorust luua tohutut protsessi pisikese utiliidi jaoks ega mingit ettenägelikkust kasutada ühte tegevusskeemi kriitilise teenuse haldusmudelina. Proportsionaalsus on siin praktiline kunst. Mida laiem on kokkupuude, mida kaalukamad on andmed, mida raskem on taastumine ja mida kesksem on komponent, seda tugevamad peaksid olema dokumendid ja toimimiskorraldus. See ei ole bürokraatia bürokraatia pärast. See on katse hoida tegelik otsus tegeliku tagajärje lähedal.

Avatud lähtekood teenib oma kohta Euroopa digitaristus, kui see aitab institutsioonidel jääda suutlikeks: suutlikeks kontrollima, suutlikeks muutma, suutlikeks selgitama ja suutlikeks jätkama. Suutlikkus omandatakse aeglasemalt kui entusiasm. See vajab aega, inimesi, dokumentatsiooni, testimist ja aeg-ajalt valmisolekut rahastada tööd, millest ei saa kunagi konverentsi peaettekannet. See on ka see, mis jääb alles, kui populaarne hoidla, tarnijasuhe või väljalaskeplaan muutub ilma luba küsimata.

See on vastutus oma kasulikus, ebaharilikus ja täiesti avalikus vormis.

Allikad