Το ανοιχτό λογισμικό δεν απαλλάσσει από την ευθύνη

Η δημοσίευση του πηγαίου κώδικα αλλάζει ποιος μπορεί να τον επιθεωρήσει, να τον επαναχρησιμοποιήσει και να τον βελτιώσει. Δεν αφαιρεί την πρακτική εργασία...

Το ανοιχτό λογισμικό δεν απαλλάσσει από την ευθύνη

Ένα αποθετήριο είναι μια αρχή, όχι ένα τέλος

Υπάρχει μια παρηγορητική μικρή ιστορία για το ανοιχτό λογισμικό. Μια ομάδα δημοσιεύει κώδικα. Άλλοι άνθρωποι μπορούν να τον διαβάσουν. Ο κώδικας γίνεται ένα κοινό αγαθό, ή τουλάχιστον μια χρήσιμη κοινή ενόχληση. Η ευθύνη διαλύεται μέσα στο πλήθος.

Οι δύο πρώτες προτάσεις μπορεί να είναι αληθείς. Η τελευταία δεν είναι. Ένα δημόσιο αποθετήριο μπορεί να διευρύνει την επιθεώρηση, την επαναχρησιμοποίηση και τη συνεισφορά. Μπορεί να δώσει σε έναν οργανισμό μια σαφέστερη οδό εξόδου από ό,τι μια κλειστή υπηρεσία. Μπορεί να επιτρέψει σε έναν δημόσιο φορέα να εξετάσει ένα στοιχείο χωρίς να ζητήσει άδεια από έναν προμηθευτή. Τίποτα από αυτά δεν απαντά στην ερώτηση που φτάνει ένα συνηθισμένο πρωινό Τρίτης: ποια έκδοση τρέχει εδώ, με ποια άδεια, με ποια διαμόρφωση, και ποιος θα αναλάβει δράση αν ισχύει η συμβουλή ασφαλείας;

Το ανοιχτό λογισμικό αλλάζει το σχήμα της ευθύνης. Δεν καθιστά την ευθύνη προαιρετική. Ο συντηρητής εξακολουθεί να έχει αποφάσεις να λάβει σχετικά με τις εκδόσεις, τις αναφορές ασφαλείας, τις υποστηριζόμενες εκδόσεις και την αδειοδότηση. Ο οργανισμός που συσκευάζει ένα στοιχείο εξακολουθεί να έχει αποφάσεις να λάβει σχετικά με την προέλευση, τις ενημερώσεις και το τι λέει στους χρήστες του. Αυτός που αναπτύσσει εξακολουθεί να έχει αποφάσεις να λάβει σχετικά με το απόθεμα, την έκθεση, τη διαμόρφωση, την πρόσβαση και την ανάκτηση. Μια άδεια παρέχει δικαιώματα και όρους. Δεν παρέχει ένα πρόγραμμα εφημερίας.

Αυτό έχει σημασία επειδή το ανοιχτό λογισμικό έχει γίνει συνηθισμένη υποδομή. Βρίσκεται σε λειτουργικά συστήματα, προγράμματα περιήγησης, δημόσιες υπηρεσίες, ερευνητικά εργαλεία, βιομηχανικά συστήματα και τις βιβλιοθήκες που κάνουν ένα προϊόν να φαίνεται πιο αυτόνομο από ό,τι είναι. Το ώριμο ερώτημα δεν είναι λοιπόν αν ένας οργανισμός είναι υπέρ ή κατά του ανοιχτού λογισμικού. Είναι αν μπορεί να φέρει τις ευθύνες που δημιουργεί το λογισμικό από το οποίο επιλέγει να εξαρτάται.

Η ευρωπαϊκή πολιτική έχει αρχίσει να περιγράφει αυτή τη διάκριση πιο καθαρά. Ο νόμος για την ανθεκτικότητα στον κυβερνοχώρο ρυθμίζει τα προϊόντα με ψηφιακά στοιχεία και περιλαμβάνει μια συγκεκριμένη οδό για τους διαχειριστές ελεύθερου και ανοιχτού λογισμικού. Η οδός αναγνωρίζει ότι ένα άτομο ή ένας οργανισμός που παρέχει συνεχή υποστήριξη για ελεύθερο και ανοιχτό λογισμικό μπορεί να καταλάβει μια πραγματική θέση στην αλυσίδα ασφαλείας. Δεν μετατρέπει κάθε εθελοντή που δημοσιεύει κώδικα σε κατασκευαστή. Ομοίως, δεν επιτρέπει σε έναν εμπορικό φορέα να κρύβεται πίσω από ένα δημόσιο αποθετήριο όταν αυτός ο φορέας φέρνει ένα προϊόν στην αγορά.

Η πρακτική συνέπεια είναι ευχάριστα μη ρομαντική. Αντιμετώπισε κάθε εξάρτηση ως κάτι που πρέπει να ονομαστεί, να κατανοηθεί και να φροντιστεί. Αυτό δεν είναι επίθεση στο ανοιχτό λογισμικό. Είναι η πειθαρχία που επιτρέπει στο ανοιχτό λογισμικό να παραμείνει χρήσιμο όταν έχει φύγει η καινοτομία.

Τι αλλάζει πραγματικά η δημοσίευση

Η διαθεσιμότητα του πηγαίου κώδικα αλλάζει πολλά πράγματα ταυτόχρονα. Ένας αναγνώστης μπορεί να επιθεωρήσει την υλοποίηση αντί να την συμπεράνει από μια σελίδα μάρκετινγκ. Μια ομάδα μπορεί να αναπαράγει μια μεταγλώττιση αν οι οδηγίες μεταγλώττισης, οι εξαρτήσεις και το περιβάλλον το επιτρέπουν. Ένας προμηθευτής μπορεί να αντικατασταθεί πιο εύκολα όταν η άδεια και οι διεπαφές το επιτρέπουν. Ένας ερευνητής μπορεί να δοκιμάσει έναν ισχυρισμό, μια ομάδα ασφαλείας μπορεί να εξετάσει μια επιδιόρθωση, και ένας δημόσιος αγοραστής μπορεί να κάνει ερωτήσεις χωρίς να αντιμετωπίζει ένα μαύρο κουτί ως συνταγματική αρχή.

Αυτά είναι σημαντικά δημόσια αγαθά. Είναι επίσης υπό όρους. Ο κώδικας που είναι ορατός αλλά αδύνατο να μεταγλωττιστεί είναι λιγότερο επιθεωρήσιμος από ό,τι φαίνεται αρχικά. Ο κώδικας που μπορεί να μεταγλωττιστεί αλλά δεν έχει σαφή άδεια αφήνει την επαναχρησιμοποίηση αβέβαιη. Ο κώδικας που έχει άδεια αλλά συναρμολογείται από άγνωστες εξαρτήσεις φέρει ένα πρόβλημα προέλευσης. Ο κώδικας που συντηρείται μόνο σε έναν κλάδο που κανείς δεν μπορεί να αναγνωρίσει δεν γίνεται αξιόπιστος από το γεγονός ότι υπάρχει μια σελίδα αποθετηρίου.

Ο Οργανισμός Ανοιχτού Κώδικα περιγράφει το ανοιχτό λογισμικό μέσω μιας εγκεκριμένης άδειας και ενός συνόλου δικαιωμάτων, συμπεριλαμβανομένης της πρόσβασης στον πηγαίο κώδικα και της ελευθερίας αναδιανομής και τροποποίησης υπό καθορισμένους όρους. Αυτός ο ορισμός αφορά σκόπιμα τις άδειες χρήσης. Δεν είναι συμφωνία επιπέδου υπηρεσιών, πιστοποίηση ασφαλείας, εγγύηση καταλληλότητας για ένα συγκεκριμένο δημόσιο έργο ή διαβεβαίωση ότι ένα στοιχείο θα συντηρείται επ' αόριστον. Η απουσία αυτών των υποσχέσεων δεν αποτελεί ελάττωμα του ορισμού. Είναι ένας λόγος να είμαστε ακριβείς ως προς το τι επωμίζεται ένας οργανισμός.

Βοηθά να διαχωρίσουμε τέσσερα ερωτήματα που συχνά συγχέονται σε μία φιλική λέξη. Είναι διαθέσιμος ο πηγαίος κώδικας; Έχει άδεια για την προβλεπόμενη χρήση; Μπορεί ο οργανισμός να εξακριβώσει από πού προήλθε ο κώδικας και οι εξαρτήσεις του; Αναλαμβάνει κάποιος ενεργά το επιχειρησιακό έργο που απαιτεί αυτή η ανάπτυξη; Ένα «ναι» στο πρώτο ερώτημα δεν απαντά στα άλλα τρία.

Αυτός ο διαχωρισμός κάνει επίσης τις συζητήσεις λιγότερο θεατρικές. Μια ομάδα προμηθειών δεν χρειάζεται να επιδείξει ενθουσιασμό για ένα αποθετήριο. Χρειάζεται να γνωρίζει αν το στοιχείο είναι κατάλληλο για το σύστημα που αγοράζει ή λειτουργεί. Μια ομάδα μηχανικών δεν χρειάζεται να απολογείται που χρησιμοποιεί μια επιτρεπτική άδεια. Χρειάζεται να γνωρίζει πώς θα τηρήσει τις ειδοποιήσεις άδειας, θα διατηρήσει τα απαιτούμενα υλικά, θα ενημερώσει τις εξαρτήσεις και θα ανταποκριθεί σε ένα δημοσιοποιημένο ζήτημα. Μια νομική ομάδα δεν χρειάζεται να γίνει διαχειριστής εκδόσεων. Χρειάζεται όμως μια διαδρομή προς τη διαδικασία έκδοσης πριν ένα πρόβλημα άδειας μετατραπεί σε δημόσια διόρθωση.

Ο πηγαίος κώδικας μπορεί να περάσει από πολλά χέρια. Επιλέξτε ένα επίπεδο για να διακρίνετε τις ευθύνες δημοσίευσης, συσκευασίας, τοποθέτησης προϊόντος και ανάπτυξης.

Η άδεια είναι ένα όριο, όχι μια πρόγνωση καιρού

Οι άδειες αντιμετωπίζονται μερικές φορές ως διοικητική λεπτομέρεια, σαν η νομική εργασία να ξεκινά αφού τελειώσει η μηχανική. Στην πράξη, οι επιλογές άδειας διαμορφώνουν τις μηχανικές αποφάσεις από την αρχή. Επηρεάζουν το αν ένα στοιχείο μπορεί να συνδυαστεί με άλλο στοιχείο, αν οι ειδοποιήσεις πρέπει να συνοδεύουν μια διανομή, αν ο τροποποιημένος κώδικας πρέπει να προσφερθεί σε συγκεκριμένες περιστάσεις και αν μια ομάδα μπορεί να πληροί τους όρους που συνδέονται με τα δικαιώματα που θέλει να χρησιμοποιήσει.

Αυτό δεν σημαίνει ότι κάθε μηχανικός πρέπει να γίνει ειδικός πνευματικής ιδιοκτησίας. Σημαίνει ότι ο οργανισμός χρειάζεται μια αξιόπιστη μετατροπή μεταξύ του λογισμικού που κατασκευάζει και των δεσμεύσεων που αναλαμβάνει όταν διανέμει, φιλοξενεί ή τροποποιεί αυτό το λογισμικό. Η μετατροπή πρέπει να γίνεται όσο τα δεδομένα είναι ακόμη διαθέσιμα: ποιο πακέτο επιλέχθηκε, ποια έκδοση χρησιμοποιήθηκε, αν τροποποιήθηκε, πώς συνδέθηκε ή συμπεριλήφθηκε, με τι αποστέλλεται και ποια είναι η προβλεπόμενη διαδρομή διανομής.

Δεν υπάρχει καθολική απάντηση για τις άδειες. Μια επιτρεπτική άδεια μπορεί να κάνει την επαναχρησιμοποίηση απλή, ενώ εξακολουθεί να απαιτεί ειδοποιήσεις και διατήρηση του κειμένου πνευματικής ιδιοκτησίας. Μια αμοιβαία άδεια μπορεί να προσθέσει πρόσθετους όρους στη διανομή ή την τροποποίηση. Μια ρύθμιση διπλής άδειας μπορεί να απαιτεί από τον οργανισμό να επιλέξει μια εμπορική διαδρομή ή μια συγκεκριμένη διαδρομή ανοιχτού κώδικα. Ένας οργανισμός δεν πρέπει να συνάγει υποχρεώσεις από ένα παρατσούκλι άδειας, ένα σήμα διαχειριστή πακέτων ή μια μισοθυμημένη ιστορία συναδέλφου από το 2014. Θα πρέπει να διαβάσει το κείμενο της άδειας, να καταγράψει την απόφαση και να ζητήσει συμβουλή όπου η προβλεπόμενη χρήση είναι αβέβαιη.

Η συμμόρφωση με τις άδειες χρήσης δεν είναι επίσης μια τυπική διαδικασία που εκτελείται την εβδομάδα της κυκλοφορίας. Ένας κατάλογος λογισμικού, ένας κατάλογος εξαρτήσεων και ένα αρχείο κυκλοφορίας μπορούν να απαντήσουν στο μεταγενέστερο ερώτημα: τι περιλαμβανόταν σε αυτό το τεχνούργημα; Αλλά μια λίστα είναι χρήσιμη μόνο αν περιγράφει ένα συγκεκριμένο τεχνούργημα, έκδοση και ημερομηνία. Ένα υπολογιστικό φύλλο που ονομάζεται dependencies-final-final.xlsx δεν αποτελεί σύστημα προέλευσης. Είναι ένα αρχαιολογικό στρώμα.

Για έναν δημόσιο φορέα, αυτό είναι κάτι περισσότερο από εσωτερική διαχείριση. Ο φορέας μπορεί να χρειαστεί να διατηρήσει την ικανότητα να εξηγήσει γιατί επιλέχθηκε ένα στοιχείο, ποιοι όροι το διέπουν, πώς μπορεί να αντικατασταθεί και τι συμβαίνει αν σταματήσει η συντήρηση. Για έναν εμπορικό οργανισμό, τα ίδια αρχεία επηρεάζουν τις συμβατικές δεσμεύσεις, τις ενημερώσεις προϊόντων και την επικοινωνία με τους πελάτες. Για μια μικρή ομάδα, η κλίμακα είναι διαφορετική αλλά η λογική δεν είναι. Αν ένα έργο δεν μπορεί να προσδιορίσει την άδεια χρήσης του κώδικα που διανέμει, δεν μπορεί να ισχυριστεί με ειλικρίνεια ότι το νομικό πλαίσιο είναι υπό έλεγχο.

Η υπεύθυνη κίνηση είναι αναλογική, όχι μεγαλεπήβολη. Καταγράψτε τις άμεσες εξαρτήσεις. Διατηρήστε τα κείμενα των αδειών και τις απαιτούμενες κοινοποιήσεις μαζί με την κυκλοφορία. Καταγράψτε τις ουσιώδεις τροποποιήσεις. Ορίστε ένα σημείο επανεξέτασης για νέους ή ασυνήθιστους όρους αδειοδότησης. Ορίστε κάποιον υπεύθυνο για την επίλυση της αβεβαιότητας. Αυτοί είναι μετριοπαθείς έλεγχοι. Η αξία τους έγκειται στο ότι αποτρέπουν την αβεβαιότητα από το να γίνει έκπληξη αφού το λογισμικό έχει διανεμηθεί.

Η συντήρηση είναι εργασία, ακόμη και όταν προσφέρεται εθελοντικά

Η συντήρηση ανοιχτού κώδικα συχνά περιγράφεται σαν να ήταν προσωπική αρετή. Μερικές φορές είναι. Οι άνθρωποι εξετάζουν διορθώσεις, απαντούν σε ερωτήσεις, συσκευάζουν εκδόσεις και αποτρέπουν τις παλιές υποθέσεις από το να γίνουν αυριανή διακοπή λειτουργίας επειδή νοιάζονται για ένα εργαλείο και για τους ανθρώπους που το χρησιμοποιούν. Αυτή η γενναιοδωρία αξίζει σεβασμό. Δεν θα έπρεπε να χρησιμοποιείται ως επιχειρηματικό μοντέλο χωρίς επιχειρηματική απόφαση.

Η συντήρηση είναι λειτουργική εργασία. Περιλαμβάνει την απόφαση για το ποιες εκδόσεις υποστηρίζονται, την εξέταση των συνεισφορών, τη δημοσίευση πληροφοριών ασφαλείας, τη διαχείριση της διαδικασίας κυκλοφορίας, την ανταπόκριση σε αναφορές, την τεκμηρίωση των αλλαγών που σπάνε τη συμβατότητα, τη διατήρηση της υποδομής κατασκευής σε λειτουργική κατάσταση και, μερικές φορές, το να λέει κανείς όχι. Το τελευταίο υποτιμάται. Ένα έργο που δεν μπορεί να απορρίψει ένα αίτημα για νέα λειτουργία, μια μη υποστηριζόμενη πλατφόρμα ή μια επικίνδυνη συντόμευση δεν είναι απαραίτητα πιο ανοιχτό. Μπορεί απλώς να είναι πιο εκτεθειμένο.

Η Στρατηγική Λογισμικού Ανοιχτού Κώδικα της Ευρωπαϊκής Επιτροπής αντιμετωπίζει τον ανοιχτό κώδικα ως τρόπο βελτίωσης της επαναχρησιμοποίησης, της διαφάνειας, της συνεργασίας και της τεχνολογικής ανεξαρτησίας στη δημόσια διοίκηση. Αυτά τα οφέλη εξαρτώνται από την ικανότητα. Η επαναχρησιμοποίηση απαιτεί από έναν οργανισμό να κατανοεί τι επαναχρησιμοποιεί. Η διαφάνεια απαιτεί κάποιον να διαβάσει τι αποκαλύπτεται. Η ανεξαρτησία απαιτεί κάτι περισσότερο από την κατοχή ενός κουμπιού αντιγραφής: απαιτεί την πρακτική ικανότητα να λειτουργεί, να προσαρμόζει ή να προμηθεύεται υποστήριξη για το λογισμικό όταν ο αρχικός συνεισφέρων έχει αποχωρήσει.

Γι' αυτό το ερώτημα «συντηρείται;» χρειάζεται περισσότερη σαφήνεια. Μπορεί να σημαίνει ότι υπάρχουν πρόσφατες εκδόσεις. Μπορεί να σημαίνει ότι έχει δημοσιευτεί ένα σημείο επικοινωνίας για θέματα ασφαλείας. Μπορεί να σημαίνει ότι το έργο περιγράφει τις υποστηριζόμενες εκδόσεις, τις οδηγίες κατασκευής και μια διαδικασία συνεισφοράς. Μπορεί να σημαίνει ότι ένας οργανισμός έχει δεσμεύσει αμειβόμενο χρόνο για την εργασία. Μπορεί να σημαίνει ότι ένας αναπτύσσων έχει τη δική του ικανότητα να συντηρεί ένα fork ή να αντικαθιστά ένα στοιχείο. Αυτά είναι διαφορετικά δεδομένα. Ένα πράσινο γράφημα δραστηριότητας μπορεί να είναι χρήσιμη απόδειξη, αλλά δεν αποτελεί συμβόλαιο συντήρησης.

Ένας υπεύθυνος υιοθέτης θα πρέπει επομένως να αποφασίσει τι είδους συντήρηση χρειάζεται πριν αποφασίσει τι ελπίζει ότι θα προσφέρει μια κοινότητα. Ένα εσωτερικό εργαλείο χαμηλού κινδύνου μπορεί να είναι συμβατό με ένα μικρό έργο και ένα μέτριο πρόγραμμα ενημερώσεων. Ένα στοιχείο στο επίκεντρο ενός προϊόντος που εκτίθεται εξωτερικά χρειάζεται ένα σαφέστερο μοντέλο υποστήριξης, ταχύτερη αξιολόγηση ευπαθειών και ένα σχέδιο εξόδου. Η διάκριση δεν αφορά το κύρος του έργου. Αφορά τις συνέπειες του να κάνει κανείς λάθος.

Υπάρχει μια μικρή ολλανδική συνήθεια που αξίζει να δανειστούμε εδώ: μην μπερδεύετε το gezellig με το κυβερνημένο. Μια φιλόξενη κοινότητα μπορεί να είναι ένα υπέροχο μέρος για να συνεισφέρει κανείς. Μπορεί ωστόσο να μην έχει καμία υποχρέωση να διατηρεί το παραγωγικό σας σύστημα σε λειτουργία. Ο οργανισμός που θέτει αυτό το σύστημα σε παραγωγή είναι αυτός που φέρει τη διαφορά.

Η διαδικασία γνωστοποίησης ευπαθειών χρειάζεται διαδρομή πριν χρειαστεί σύνθημα

Οι περισσότεροι συμφωνούν, θεωρητικά, ότι οι ευπάθειες θα πρέπει να γνωστοποιούνται υπεύθυνα. Το δύσκολο μέρος είναι λιγότερο θεωρητικό. Πού στέλνει ένας αναφέρων τα ευρήματά του; Ποιος τα παραλαμβάνει; Ποιες πληροφορίες χρειάζονται για την αναπαραγωγή τους; Ποιος αποφασίζει αν επηρεάζουν μια υποστηριζόμενη έκδοση; Πώς αναπτύσσεται μια επιδιόρθωση χωρίς να δημιουργείται περιττό δημόσιο παράθυρο έκθεσης; Πώς ενημερώνονται οι χρήστες για το τι πρέπει να κάνουν; Ποια μεταγενέστερα πακέτα χρειάζονται ενημέρωση; Τι συμβαίνει αν ο αναφέρων δεν λάβει καμία απάντηση;

Αυτές οι ερωτήσεις δεν αποτελούν ένδειξη δυσπιστίας προς το ανοιχτό λογισμικό. Είναι η δουλειά του να αντιμετωπίζει κανείς τους χρήστες ως ανθρώπους που χρειάζονται μια απάντηση. Η εργασία του ENISA για τη γνωστοποίηση ευπαθειών και τη συντονισμένη γνωστοποίηση ευπαθειών περιγράφει την αξία των καθορισμένων διαδικασιών μεταξύ αναφερόντων, προμηθευτών και άλλων ενδιαφερόμενων μερών. Μια διαδικασία δεν μπορεί να εγγυηθεί ότι κάθε αναφορά είναι σωστή ή ότι κάθε επιδιόρθωση είναι γρήγορη. Μπορεί να μειώσει την πιθανότητα ένα σοβαρό ζήτημα να ξεκινήσει τη ζωή του σε ένα ανεπιτήρητο εισερχόμενα.

Ένα έργο μπορεί να δημοσιεύσει μια πολιτική ασφαλείας, μια διεύθυνση αναφοράς και πληροφορίες για τις υποστηριζόμενες εκδόσεις. Αυτά είναι χρήσιμα σήματα, ειδικά όταν περιγράφουν τι μπορεί να περιμένει ένας αναφέρων. Ένα έργο μπορεί επίσης να είναι πολύ μικρό για να παρέχει τον χρόνο απόκρισης που χρειάζεται μια σημαντική εγκατάσταση. Αυτό δεν αποτελεί ηθική αποτυχία. Είναι ένα γεγονός προγραμματισμού για τον οργανισμό που επιλέγει την εξάρτηση.

Το ίδιο ισχύει και για τα μεταγενέστερα στάδια. Ένας κατασκευαστής δεν μπορεί εύλογα να ισχυριστεί ότι μια ευπάθεια είναι πρόβλημα κάποιου άλλου, απλώς επειδή το ευάλωτο στοιχείο ξεκίνησε σε ένα ανοιχτό αποθετήριο. Αν ο κατασκευαστής διαθέτει στην αγορά της Ένωσης ένα προϊόν με ψηφιακά στοιχεία, ο κανονισμός για την ανθεκτικότητα στον κυβερνοχώρο θέτει απαιτήσεις σχετικά με τον χειρισμό ευπαθειών και την παροχή ενημερώσεων ασφαλείας εντός του πλαισίου που ισχύει για το προϊόν. Η νομική λεπτομέρεια εξαρτάται από το προϊόν και τον ρόλο. Το επιχειρησιακό σημείο είναι απλούστερο: το μέρος που καθιστά το προϊόν διαθέσιμο χρειάζεται έναν τρόπο να γνωρίζει αν μια αλλαγή ανάντη επηρεάζει ό,τι έχει προμηθεύσει.

Εδώ είναι που ένα απογραφικό σύστημα γίνεται ενεργό αντί για διακοσμητικό. Πρέπει να συνδέει ένα στοιχείο με μια έκδοση, μια κατασκευή, μια έκδοση προϊόντος και έναν ιδιοκτήτη ικανό να αξιολογήσει την αναφορά. Ο ιδιοκτήτης δεν χρειάζεται να διορθώσει μόνος του κάθε ελάττωμα ανάντη. Πρέπει όμως να αποφασίσει αν θα ενημερώσει, θα μετριάσει, θα απενεργοποιήσει, θα ειδοποιήσει, θα αποζημιώσει ή θα σταματήσει να χρησιμοποιεί το στοιχείο. «Χρησιμοποιούμε ανοιχτό λογισμικό» είναι μια περιγραφή μιας εισροής. Δεν είναι σχέδιο απόκρισης.

Εξετάστε ένα ρητά υποθετικό παράδειγμα. Μια ομάδα περιλαμβάνει μια βιβλιοθήκη σε μια υπηρεσία επεξεργασίας εγγράφων. Μήνες αργότερα, μια συμβουλευτική ανακοίνωση ασφαλείας εντοπίζει ένα ευάλωτο εύρος. Αν η ομάδα έχει καταγράψει το στοιχείο, την έκδοση και τις υπηρεσίες στις οποίες είναι ενσωματωμένο, μπορεί να ξεκινήσει μια αξιολόγηση. Αν μπορεί να αναπαράγει τις κατασκευές και να δοκιμάσει την ενημέρωση, μπορεί να αποφασίσει αν η θεραπεία είναι μια αναβάθμιση, μια αλλαγή διαμόρφωσης ή ένας προσωρινός περιορισμός. Αν δεν έχει ούτε αρχείο ούτε ιδιοκτήτη, το πρώτο καθήκον είναι αστυνομική έρευνα. Η ευπάθεια μπορεί να είναι ίδια και στις δύο περιπτώσεις. Ο επιχειρησιακός κίνδυνος δεν είναι.

Μια διαδρομή γνωστοποίησης δεν υπόσχεται ότι κάθε ζήτημα είναι μικρό. Κάνει ορατή την επόμενη υπεύθυνη ενέργεια όταν εντοπίζεται ένα ζήτημα.

Η προέλευση είναι η απάντηση στο «τι ακριβώς τρέχουμε;»

Η προέλευση λογισμικού μπορεί να ακούγεται σαν όρος δανεισμένος από ετικέτα μουσείου. Το υποκείμενο ερώτημα είναι συνηθισμένο: από πού προήλθε αυτό το τεχνούργημα και μπορούμε να αποδείξουμε τη διαδρομή του; Για το λογισμικό, η διαδρομή μπορεί να περιλαμβάνει αποθετήρια πηγαίου κώδικα, εκδοθέντα αρχεία, μητρώα εξαρτήσεων, εργαλεία κατασκευής, διαμόρφωση, κλειδιά υπογραφής, περιβάλλοντα κατασκευής και συστήματα δημοσίευσης. Η απάντηση σπάνια είναι ένα μοναδικό κομψό γεγονός. Είναι μια συλλογή εγγραφών που πρέπει να συμφωνούν αρκετά καλά ώστε ένα άτομο να λάβει απόφαση.

Η προέλευση δεν απαιτεί από έναν οργανισμό να ισχυρίζεται τέλεια γνώση. Απαιτεί να δηλώνει τι είναι γνωστό, τι ελέγχθηκε και πού παραμένει αβεβαιότητα. Μια αναπαραγώγιμη κατασκευή μπορεί να παρέχει ισχυρές αποδείξεις ότι ένα καθορισμένο αρχείο πηγής και ένα καθορισμένο περιβάλλον παρήγαγαν ένα αντίστοιχο τεχνούργημα. Μια υπογεγραμμένη έκδοση μπορεί να βοηθήσει στον εντοπισμό του κλειδιού που χρησιμοποιήθηκε για την έκδοση. Μια λίστα υλικού λογισμικού μπορεί να περιγράφει δηλωμένα στοιχεία. Καμία από αυτές δεν αποδεικνύει από μόνη της ότι ο κώδικας είναι αβλαβής, ότι κάθε μεταβατική εξάρτηση έχει ελεγχθεί ή ότι μια έκδοση είναι κατάλληλη για συγκεκριμένη χρήση. Μαζί, μπορούν να κάνουν μια μεταγενέστερη έρευνα πολύ λιγότερο εικαστική.

Αυτή η διάκριση είναι σημαντική επειδή η προέλευση συχνά παρουσιάζεται ως μαγική σφραγίδα. Δεν είναι. Μια σύνοψη κατακερματισμού μπορεί να σας πει ότι δύο ακολουθίες byte ταιριάζουν. Δεν μπορεί να σας πει ότι το πρόγραμμα που ταιριάζει θα έπρεπε να επιτρέπεται να επεξεργάζεται ευαίσθητες εγγραφές. Μια υπογραφή μπορεί να συνδέσει μια έκδοση με ένα κλειδί. Δεν μπορεί να σας πει ότι το άτομο που ελέγχει το κλειδί ακολούθησε μια καλή διαδικασία αναθεώρησης. Ένα απόθεμα μπορεί να κατονομάσει ένα στοιχείο. Δεν μπορεί να σας πει αν το στοιχείο έχει διαμορφωθεί με ασφάλεια. Τα αποδεικτικά στοιχεία παραμένουν αποδεικτικά στοιχεία, όχι υποκατάστατο της κρίσης.

Ωστόσο, η απουσία προέλευσης φτωχαίνει την κρίση. Όταν μια ομάδα δεν μπορεί να προσδιορίσει ποια αναθεώρηση πηγής δημιούργησε ένα αναπτυγμένο πακέτο, δεν μπορεί να συνδέσει με βεβαιότητα μια διόρθωση από τον ανάντη πάροχο με τη δική της υπηρεσία. Όταν δεν μπορεί να αναγνωρίσει μια μεταβατική εξάρτηση, δεν μπορεί να αξιολογήσει μια ειδοποίηση ή συμβουλή χωρίς πρώτα να ανακατασκευάσει την αλυσίδα εφοδιασμού. Όταν η κατασκευή παράγει διαφορετικά αποτελέσματα χωρίς εξήγηση, δεν μπορεί να πει αν ένα δυαδικό αρχείο άλλαξε λόγω πηγής, περιβάλλοντος ή παρεμβολής. Αυτά είναι πρακτικά όρια, όχι τεστ καθαρότητας.

Η ευρωπαϊκή ψηφιακή κυριαρχία συχνά περιορίζεται στη θέση ενός διακομιστή. Η θέση έχει σημασία. Δεν αρκεί. Ένα σύστημα μπορεί να λειτουργεί στην Ευρώπη ενώ βασίζεται σε μια γραμμή κατασκευής, ένα μητρώο εξαρτήσεων ή ένα κανάλι ενημερώσεων που ο διαχειριστής δεν μπορεί να επιθεωρήσει, να ελέγξει ή να αντικαταστήσει. Αντίστροφα, το ανοιχτό λογισμικό μπορεί να προσφέρει μια πραγματική οδό προς τον έλεγχο και τη φορητότητα, ενώ παράλληλα αφήνει τον υιοθετούντα υπεύθυνο για την ικανότητα που απαιτείται για τη χρήση αυτής της οδού. Η κυριαρχία είναι μια ικανότητα δράσης υπό πίεση, όχι μια σημαία προσαρτημένη σε μια εικόνα κοντέινερ.

Μια χρήσιμη εγγραφή προέλευσης θα πρέπει να επιτρέπει σε έναν τεχνικά ικανό συνάδελφο να εντοπίσει μια έκδοση προς τα πίσω και προς τα εμπρός. Προς τα πίσω: ποια πηγή, εξαρτήσεις και διαδικασία κατασκευής οδήγησαν εδώ; Προς τα εμπρός: ποιες υπηρεσίες, προϊόντα και χρήστες ενδέχεται να επηρεαστούν αν αυτό το στοιχείο αλλάξει ή αποσυρθεί; Η εγγραφή μπορεί να είναι αναλογική. Ένα μικρό εσωτερικό εργαλείο δεν χρειάζεται τον μηχανισμό ενός προγράμματος αεροσκαφών. Χρειάζεται όμως αρκετή αλήθεια για να υποστηρίξει τις συνέπειες της χρήσης του.

Η Πράξη για την Ανθεκτικότητα στον Κυβερνοχώρο χαράσσει μια γραμμή χωρίς να προσποιείται ότι ο κόσμος είναι απλός

Η Πράξη για την Ανθεκτικότητα στον Κυβερνοχώρο συνοψίζεται συχνά ως ένα νέο σύνολο απαιτήσεων κυβερνοασφάλειας για συνδεδεμένα προϊόντα. Αυτό είναι αληθές αλλά ελλιπές. Η πιο χρήσιμη συμβολή της σε αυτή τη συζήτηση είναι η διάκριση που κάνει μεταξύ ρόλων. Ένας διαχειριστής ελεύθερου και ανοιχτού λογισμικού μπορεί να είναι μια οντότητα που παρέχει διαρκή υποστήριξη για την ανάπτυξη προϊόντων με ψηφιακά στοιχεία που χαρακτηρίζονται ως ελεύθερο και ανοιχτό λογισμικό και που έχει σχεδιαστεί για να διασφαλίζει τη βιωσιμότητα αυτών των προϊόντων. Ο κανονισμός θέτει προϋποθέσεις γύρω από αυτόν τον ρόλο. Δεν αντιμετωπίζει κάθε συντελεστή ως φέροντα τις ίδιες υποχρεώσεις με έναν κατασκευαστή.

Αυτή η διάκριση αναγνωρίζει πώς λειτουργεί στην πραγματικότητα το ανοιχτό λογισμικό. Ένα έργο μπορεί να έχει μεμονωμένους συνεισφέροντες, έναν σύλλογο, ένα ίδρυμα, μια εταιρεία που προσφέρει υποστήριξη, μια διανομή που συσκευάζει το λογισμικό, έναν ενοποιητή και έναν κατασκευαστή που το ενσωματώνει σε ένα προϊόν. Οι ευθύνες τους σχετίζονται μεταξύ τους αλλά δεν είναι εναλλάξιμες. Ένας συνεισφέρων μπορεί να διορθώσει ένα σφάλμα. Ένας διαχειριστής μπορεί να συντονίζει το έργο. Ένας διανομέας μπορεί να το συσκευάσει. Ένας κατασκευαστής μπορεί να διαθέσει ένα προϊόν στην αγορά. Ένας αναπτυχτής μπορεί να αποφασίσει πώς θα διαχειριστεί αυτό το προϊόν πραγματικά δεδομένα και πραγματικούς ανθρώπους. Το δημόσιο αποθετήριο είναι ένας χώρος συνάντησης μεταξύ αυτών των ρόλων, όχι ένας νομικός αναμικτήρας.

Για τους οργανισμούς, η ασφαλέστερη προσέγγιση δεν είναι να μετατρέψουν τον κανονισμό σε λαϊκή παράδοση πριν αυτός εφαρμοστεί. Η Πράξη έχει σταδιακές ημερομηνίες εφαρμογής και διατάξεις ανά ρόλο. Η νομική ερμηνεία πρέπει να προέρχεται από το εφαρμοστέο κείμενο και από αρμόδιες συμβουλές, ιδίως όταν εμπλέκεται ένα προϊόν, μια εμπορική δραστηριότητα ή η διάθεση στην αγορά. Η επιχειρησιακή προετοιμασία, ωστόσο, δεν χρειάζεται να περιμένει ένα σεμινάριο με κρύο καφέ και μια διαφάνεια με τίτλο «επισκόπηση». Καταγράψτε τα στοιχεία. Προσδιορίστε ποιος είναι υπεύθυνος για τις ενημερώσεις. Διατηρήστε τα αποδεικτικά έκδοσης. Ορίστε μια διαδρομή αναφοράς περιστατικών ασφαλείας. Αποφασίστε τι σημαίνει υποστηριζόμενο. Αυτές οι ενέργειες είναι χρήσιμες είτε μια συγκεκριμένη διάταξη εφαρμόζεται σήμερα, είτε του χρόνου, είτε καθόλου.

Η Πράξη επίσης αντιστέκεται σε ένα ψευδές δίλημμα. Δεν λέει ότι το ανοιχτό λογισμικό είναι επισφαλές. Ούτε λέει ότι η δημοσίευση απαλλάσσει ένα εμπορικό προϊόν από την εργασία ασφαλείας. Αναγνωρίζει ότι η ασφάλεια του λογισμικού που χρησιμοποιείται σε προϊόντα έχει δημόσιες συνέπειες και ότι η αλυσίδα των φορέων χρειάζεται σαφέστερες ευθύνες. Οι ακριβείς υποχρεώσεις αξίζουν προσεκτική νομική ανάγνωση. Η αρχή είναι απλή: το λογισμικό που φτάνει στους ανθρώπους μέσω ενός προϊόντος χρειάζεται κάποιον ικανό να αναλάβει υπεύθυνη δράση όταν ο κίνδυνος γίνει γνωστός.

Αυτή η αρχή είναι ήδη γνωστή σε άλλους τομείς. Μια δημοσιευμένη συνταγή δεν απαλλάσσει ένα εστιατόριο από την ασφάλεια των τροφίμων. Ένα δημοσιευμένο πρότυπο κτιρίου δεν απαλλάσσει έναν εργολάβο από το καθήκον να το χρησιμοποιεί με ικανότητα. Η σύγκριση έχει όρια: οι άδειες λογισμικού, τα κανάλια ενημερώσεων και οι κοινότητες ανάπτυξης έχουν τις δικές τους δομές. Αλλά το βασικό σημείο μεταφέρεται. Η γνώση που δημοσιοποιείται μπορεί να καταστήσει δυνατό τον ανεξάρτητο έλεγχο. Δεν αφαιρεί την ευθύνη του μέρους που σερβίρει το γεύμα ή ανοίγει την πόρτα.

Τι οφείλουν στον εαυτό τους οι υιοθετούντες

Η πιο χρήσιμη πολιτική ανοιχτού λογισμικού είναι συχνά μια επιχειρησιακή πολιτική μεταμφιεσμένη σε λογική λίστα ελέγχου. Θα πρέπει να απαντά ποιος μπορεί να εισάγει μια εξάρτηση, ποιες πληροφορίες πρέπει να καταγράφονται, πώς εξετάζονται οι άδειες, πώς αξιολογούνται οι ενημερώσεις, πώς δρομολογούνται οι αναφορές ασφαλείας και ποιος μπορεί να εγκρίνει μια εξαίρεση. Θα πρέπει επίσης να απαντά τι συμβαίνει όταν τελειώνει η υποστήριξη. Μια πολιτική που εξηγεί την επιλογή αλλά δεν λέει τίποτα για την αφαίρεση είναι μισή πολιτική.

Ξεκινήστε με τη μονάδα που πραγματικά έχει σημασία: το αναπτυγμένο τεχνούργημα ή την υπηρεσία, όχι έναν αφηρημένο κατάλογο αγαπημένων έργων. Για κάθε ουσιώδες στοιχείο, ένας οργανισμός θα πρέπει να μπορεί να εντοπίσει την έκδοση, τη διαδρομή πηγής ή μητρώου, την άδεια, τον υπεύθυνο εσωτερικό ρόλο, το σύστημα στο οποίο χρησιμοποιείται και τη διαδρομή ενημέρωσης. Το επίπεδο λεπτομέρειας θα πρέπει να ακολουθεί τις συνέπειες της αποτυχίας. Ο στόχος δεν είναι να μετατραπεί κάθε προγραμματιστής σε υπάλληλο γραφείου. Είναι να σταματήσουν σημαντικά γεγονότα να γίνονται ιδιωτική γνώση σε έναν φορητό υπολογιστή ή στη μνήμη ενός ατόμου.

Στη συνέχεια, αποφασίστε ποια αποδεικτικά στοιχεία θα αλλάξουν μια απόφαση. Μια δημοσιευμένη συμβουλή ασφαλείας μπορεί να ενεργοποιήσει μια αξιολόγηση. Μια νέα έκδοση μπορεί να ενεργοποιήσει μια δοκιμή συμβατότητας. Μια αλλαγή άδειας μπορεί να ενεργοποιήσει νομική εξέταση. Μια εγκαταλελειμμένη υποστηριζόμενη έκδοση μπορεί να ενεργοποιήσει ένα σχέδιο μετεγκατάστασης. Μια κατασκευή που δεν μπορεί πλέον να αναπαραχθεί μπορεί να ενεργοποιήσει μια έρευνα. Χωρίς αυτά τα εναύσματα, τα απογραφικά στοιχεία τείνουν να γίνονται ιστορικά έγγραφα: ακριβή την ημέρα που εξήχθησαν, ευγενικά αγνοημένα στη συνέχεια.

Ορίστε την ιδιοκτησία κοντά στη δράση. Μια κεντρική ομάδα διακυβέρνησης μπορεί να θέσει πολιτική και να παρέχει τεχνογνωσία. Δεν μπορεί να λειτουργεί κάθε υπηρεσία. Μια ομάδα προϊόντος μπορεί να γνωρίζει την αρχιτεκτονική της δικής της ανάπτυξης. Μπορεί να μην είναι εξοπλισμένη για να ερμηνεύει κάθε άδεια. Η διευθέτηση λειτουργεί όταν η παράδοση είναι ρητή: ο ιδιοκτήτης προϊόντος αξιολογεί τον αντίκτυπο, η ασφάλεια συμβουλεύει για την έκθεση και την απόκριση, η νομική ή η συμμόρφωση αξιολογεί τους όρους της άδειας όπου χρειάζεται, οι προμήθειες καταγράφουν τις εξωτερικές δεσμεύσεις και ένας κατονομαζόμενος υπεύθυνος λήψης αποφάσεων αποδέχεται ή απορρίπτει τον ουσιώδη κίνδυνο. Τα ονόματα θα διαφέρουν. Η απουσία ονομάτων είναι το επαναλαμβανόμενο πρόβλημα.

Κρατήστε μια οδό εξόδου. Το ανοιχτό λογισμικό μπορεί να μειώσει το κλείδωμα, αλλά μόνο αν ένας οργανισμός μπορεί να ανακατασκευάσει, να διακλαδώσει, να αντικαταστήσει ή να συνάψει σύμβαση υποστήριξης όταν αλλάξουν οι συνθήκες. Ένα αντίγραφο του αποθετηρίου, οδηγίες κατασκευής, μια διαδρομή αποθήκευσης εξαρτήσεων και ένα αρχείο απαιτούμενης διαμόρφωσης μπορεί να είναι βαρετή δουλειά μέχρι να μην είναι διαθέσιμη η αρχική υπηρεσία ή να λήξει η σχέση. Η βαρετή δουλειά έχει εξαιρετικό ιστορικό σε καταστάσεις έκτακτης ανάγκης.

Τέλος, να είστε ειλικρινείς για τον υπολειπόμενο κίνδυνο. Κανένα πρόγραμμα εξαρτήσεων δεν μπορεί να εγγυηθεί ότι κάθε τρωτό σημείο θα βρεθεί πρώτο, ότι κάθε έργο ανάντη θα παραμείνει ενεργό ή ότι κάθε ζήτημα άδειας θα είναι απλό. Το νόημα της διακυβέρνησης δεν είναι να υποσχεθεί το αδύνατο. Είναι να κάνει την αβεβαιότητα ορατή αρκετά νωρίς ώστε ένα υπεύθυνο άτομο να αποφασίσει τι θα κάνει με αυτήν.

Τι μπορούν εύλογα να προσφέρουν οι συντηρητές

Οι συντηρητές δεν οφείλουν στον κόσμο απεριόριστη εργασία επειδή δημοσίευσαν χρήσιμο κώδικα. Αυτή η προσδοκία είναι και άδικη και επισφαλής. Ένα έργο μπορεί να είναι γενναιόδωρο ως προς την επαναχρησιμοποίηση ενώ είναι σαφές ως προς τις δυνατότητές του. Μπορεί να αναφέρει ποιες εκδόσεις υποστηρίζονται, πού να αναφέρονται ζητήματα ασφάλειας, πώς λαμβάνονται οι αποφάσεις έκδοσης, τι είδους συνεισφορές μπορεί να εξετάσει και τι δεν θα υποσχεθεί. Τα σαφή όρια είναι καλύτερα για τους υιοθετούντες από τη θολή ασάφεια.

Ακόμη και ένα μικρό έργο μπορεί να βελτιώσει τη λειτουργική παράδοση με λίγα ανθεκτικά έγγραφα: ένα αρχείο άδειας, μια αναγνώσιμη διαδικασία έκδοσης, μια επαφή ασφάλειας ή πολιτική αποκάλυψης, πληροφορίες έκδοσης, καθοδήγηση εξαρτήσεων όπου χρειάζεται και μια σαφή δήλωση για το αν η συντήρηση είναι ενεργή, περιορισμένη ή ολοκληρωμένη. Κανένα από αυτά δεν δημιουργεί εγγύηση. Το καθένα βοηθά έναν κατάντη χρήστη να κάνει μια πιο ενημερωμένη επιλογή.

Όταν ένα έργο έχει οργανωτική υποστήριξη, η συζήτηση μπορεί να προχωρήσει περισσότερο. Ο οργανισμός μπορεί να δημοσιεύσει μια πολιτική υποστηριζόμενων εκδόσεων, να περιγράψει τη διακυβέρνησή του, να καταγράψει την πρακτική υπογραφής εκδόσεων, να διατηρήσει μια διαδρομή απόκρισης σε τρωτά σημεία και να εξηγήσει πώς μπορούν οι χρήστες να λάβουν υποστήριξη. Αυτά δεν είναι σήματα για μια σελίδα προορισμού. Είναι λειτουργικές υποσχέσεις και θα πρέπει να γράφονται μόνο όπου ο οργανισμός είναι προετοιμασμένος να τις τηρήσει.

Το πιο ειλικρινές μήνυμα συντήρησης μπορεί περιστασιακά να είναι «δεν μπορούμε να αναλάβουμε αυτό». Αυτό μπορεί να σημαίνει ότι μια λειτουργία είναι εκτός πεδίου, ότι μια πλατφόρμα δεν μπορεί να δοκιμαστεί, ότι μια αναφορά ασφάλειας χρειάζεται περισσότερες πληροφορίες, ότι ένας κλάδος δεν υποστηρίζεται πλέον ή ότι δεν μπορεί να υποσχεθεί μια ημερομηνία έκδοσης. Η σαφής άρνηση δίνει στους υιοθετούντες κάτι γύρω από το οποίο μπορούν να προγραμματίσουν. Η σιωπή τους δίνει μια ιστορία να πουν στον εαυτό τους, η οποία είναι γενικά μια πιο δαπανηρή είσοδος.

Υπάρχει επίσης μια ευθύνη για τους χρήστες που εξαρτώνται από ένα έργο. Αναφέρετε τα ελαττώματα με αρκετή λεπτομέρεια για να αναπαραχθούν. Ακολουθήστε τη διαδρομή ασφάλειας αν υπάρχει. Συνεισφέρετε δοκιμές, τεκμηρίωση, χρηματοδότηση ή αναθεώρηση όπου είναι δυνατόν. Μην απαιτείτε σχέση υπηρεσιών από ένα εθελοντικό έργο ενώ αρνείστε να αναγνωρίσετε ότι μια σχέση υπηρεσιών κοστίζει χρήματα. Η αμοιβαιότητα δεν καταργεί τους διαφορετικούς ρόλους, αλλά μπορεί να κάνει την αλυσίδα λιγότερο εύθραυστη.

Το ανοιχτό λογισμικό μπορεί να ενισχύσει τη λογοδοσία

Υπάρχει ο πειρασμός, αφού καταγράψει κανείς όλα αυτά τα καθήκοντα, να καταλήξει στο συμπέρασμα ότι το ανοιχτό λογισμικό δημιουργεί υπερβολικά πολλή δουλειά. Δεν ισχύει κάτι τέτοιο. Η δουλειά υπάρχει είτε ο πηγαίος κώδικας είναι ορατός είτε όχι. Οι κλειστές εξαρτήσεις χρειάζονται επίσης καταγραφή, επίγνωση των αδειών χρήσης, αντιμετώπιση ευπαθειών, τεκμηρίωση προέλευσης και σχέδιο εξόδου. Απλώς καθιστούν ορισμένα στοιχεία δυσκολότερο να ελεγχθούν και ορισμένες εναλλακτικές δυσκολότερες να εφαρμοστούν.

Το ανοιχτό λογισμικό μπορεί να καταστήσει δυνατή μια ισχυρότερη στάση λογοδοσίας. Ένας αγοραστής μπορεί να επιθεωρήσει την αρχιτεκτονική. Ένας διαχειριστής μπορεί να διατηρήσει αντίγραφο του πηγαίου κώδικα και των οδηγιών κατασκευής. Ένας ανεξάρτητος αξιολογητής μπορεί να ελέγξει έναν ισχυρισμό. Μια δημόσια αρχή μπορεί να αποφύγει να καταστήσει τον ιδιωτικό οδικό χάρτη ενός προμηθευτή τη μόνη διαδρομή προς μια διόρθωση. Μια κοινότητα μπορεί να εντοπίσει και να επιλύσει ένα πρόβλημα που ένας οργανισμός παρέβλεψε. Αυτά είναι ουσιαστικά πλεονεκτήματα, ιδίως σε ευρωπαϊκά περιβάλλοντα όπου η δημόσια αξία, η συνέχεια και η δυνατότητα αμφισβήτησης δεν είναι προαιρετική διακόσμηση.

Αλλά η δυνατότητα δεν είναι ολοκλήρωση. Η δυνατότητα επιθεώρησης βοηθά μόνο όποιον έχει την ικανότητα και την εξουσιοδότηση να επιθεωρήσει. Η φορητότητα βοηθά μόνο όποιον έχει διατηρήσει τα τεχνουργήματα και γνωρίζει πώς να τα μετακινήσει. Ένα fork αποτελεί στρατηγική εξόδου μόνο όταν υπάρχει ομάδα, προϋπολογισμός και νομική οδός ικανά να το υποστηρίξουν. «Ο κώδικας είναι στο GitHub» δεν αποτελεί σχέδιο συνέχειας, όπως ακριβώς «τα αρχεία είναι σε μια ντουλάπα» δεν αποτελεί στρατηγική αρχειοθέτησης.

Η δική μας εργασία ανοιχτού λογισμικού στην Dweve διατηρεί αυτό το όριο σε ορατότητα. Το Knot περιγράφεται στα δημοσιευμένα υλικά μας ως ένα υπογεγραμμένο, με εμφανή ίχνη παραποίησης αρχείο καταγραφής ελέγχου για εκτελέσεις πρακτόρων τεχνητής νοημοσύνης, με επαλήθευση εκτός σύνδεσης ενός ληφθέντος αρχείου με χρήση δημόσιου κλειδιού. Αυτό καθιστά έναν ισχυρισμό περισσότερο επιθεωρήσιμο. Δεν αποφασίζει τι πρέπει να καταγράφει ένας οργανισμός, ποιος μπορεί να έχει πρόσβαση σε ένα αρχείο, πόσο καιρό πρέπει να το διατηρεί ή ποιος διερευνά ένα απροσδόκητο αποτέλεσμα. Αυτά παραμένουν ζητήματα διακυβέρνησης γύρω από το εργαλείο. Το εργαλείο μπορεί να διατηρήσει αποδεικτικά στοιχεία. Δεν μπορεί να γίνει ο υπόλογος οργανισμός εκ μέρους κανενός.

Αυτή είναι η μετρημένη υπόσχεση που αξίζει να τηρηθεί. Το ανοιχτό λογισμικό μπορεί να δώσει στους ανθρώπους περισσότερα αποδεικτικά στοιχεία, περισσότερες επιλογές και περισσότερο χώρο για συνεισφορά. Δεν θα πρέπει να του ζητείται να παρέχει μια πλασματική απαλλαγή από τη συντήρηση, την ασφάλεια, την αδειοδότηση ή την επιχειρησιακή κρίση.

Η ευθύνη επιβιώνει του κουμπιού δημοσίευσης

Η δημοσίευση πηγαίου κώδικα είναι μια χρήσιμη πράξη. Μπορεί να προσκαλέσει έλεγχο, να μειώσει τα εμπόδια στην επαναχρησιμοποίηση και να καταστήσει μια τεχνική επιλογή ευκολότερο να αμφισβητηθεί. Σε μια υγιή τεχνολογική κουλτούρα, θα πρέπει να είναι φυσιολογικό για τους δημόσιους οργανισμούς και τις εταιρείες να εξετάζουν σοβαρά το ανοιχτό λογισμικό, να το υποστηρίζουν σωστά και να εξηγούν τις επιλογές τους χωρίς δεισιδαιμονίες.

Το κουμπί δημοσίευσης δεν είναι, ωστόσο, μια καταπακτή κάτω από την ευθύνη. Δεν αφαιρεί την ανάγκη να γνωρίζει κανείς τι περιέχει ένα προϊόν. Δεν επιδιορθώνει μια αναπτυγμένη υπηρεσία. Δεν διατηρεί μια σημείωση άδειας χρήσης, δεν ιεραρχεί μια γνωστοποίηση ασφαλείας, δεν συντηρεί μια κατασκευή ούτε αποφασίζει αν ένα σύστημα πρέπει να παραμείνει σε χρήση. Αυτά τα καθήκοντα εξακολουθούν να ανήκουν σε ανθρώπους και οργανισμούς με ρόλους, προϋπολογισμούς, εξουσία και συνέπειες.

Τα καλά νέα είναι ότι η υπεύθυνη πρακτική δεν είναι μυστήρια. Ονομάστε την εξάρτηση. Διαβάστε την άδεια χρήσης. Διατηρήστε την προέλευση. Αποφασίστε ποιος είναι υπεύθυνος για την ενημέρωση. Δώστε μια οδό στις αναφορές ασφαλείας. Διατηρήστε μια επιλογή εξόδου. Δηλώστε με σαφήνεια τι υποστηρίζεται και τι όχι. Όταν αυτές οι συνήθειες υπάρχουν, το ανοιχτό λογισμικό γίνεται κάτι περισσότερο από μια χειρονομία προς τη διαφάνεια. Γίνεται υποδομή που μπορεί να επιθεωρηθεί, να συντηρηθεί και να τύχει εμπιστοσύνης για λόγους που επιβιώνουν μια δύσκολη ημέρα.

Το ερώτημα πίσω από το ερώτημα

Όταν μια ομάδα ρωτά αν ένα στοιχείο είναι ανοιχτού κώδικα, συχνά θέτει ταυτόχρονα αρκετά πιο σιωπηλά ερωτήματα. Μπορούμε να το εμπιστευτούμε; Μπορούμε να το εγκαταλείψουμε; Μπορούμε να το αλλάξουμε; Μπορεί κάποιος άλλος να το ελέγξει; Μπορούμε να λάβουμε βοήθεια όταν κάτι χαλάσει; Η άδεια και το αποθετήριο μπορούν να συμβάλουν στην απάντηση, αλλά κανένα από τα δύο δεν μπορεί να απαντήσει μόνο του. Η εμπιστοσύνη απορρέει από αποδείξεις, ικανότητες, κίνητρα και τον τρόπο με τον οποίο διοικείται μια συγκεκριμένη ανάπτυξη. Η εγκατάλειψη εξαρτάται από διεπαφές, μορφές δεδομένων, γνώση κατασκευής και πόρους. Η αλλαγή εξαρτάται από την τεχνική ικανότητα και τους όρους υπό τους οποίους μπορεί να γίνει η αλλαγή. Η βοήθεια εξαρτάται από μια πραγματική σχέση υποστήριξης ή από τη δυνατότητα λειτουργίας χωρίς αυτήν.

Αυτές οι διακρίσεις αποτελούν άμυνα τόσο απέναντι στον κυνισμό όσο και απέναντι στην ευσεβή σκέψη. Ο κυνισμός λέει ότι ο ανοιχτός κώδικας είναι απλώς απλήρωτη εργασία. Η ευσεβής σκέψη λέει ότι είναι αυτόματα ασφαλέστερος επειδή πολλά μάτια μπορεί να μπορούν να τον επιθεωρήσουν. Καμία από τις δύο δηλώσεις δεν λέει σε έναν διαχειριστή τι να κάνει στη συνέχεια. Ο διαχειριστής πρέπει να γνωρίζει ποια μάτια επιθεώρησαν πραγματικά τη σχετική έκδοση, ποιος μπορεί να δοκιμάσει μια επιδιόρθωση, ποια εξουσία υπάρχει για να γίνει μια αλλαγή και πώς το αποτέλεσμα φτάνει στο επηρεαζόμενο σύστημα. Η ασφάλεια είναι μια αλυσίδα επαληθευμένων ενεργειών, όχι μια παροιμία για τα πλήθη.

Η ίδια συγκράτηση ισχύει και για τις προμήθειες. Το να ζητά κανείς από έναν προμηθευτή ένα στοιχείο ανοιχτού κώδικα δεν καθιστά μια σύμβαση λιγότερο σημαντική. Αλλάζει τα ερωτήματα που μπορεί να θέσει μια καλή σύμβαση: ποια ανάντη στοιχεία περιλαμβάνονται, πώς θα χειριστούν οι ειδοποιήσεις και οι υποχρεώσεις πηγαίου κώδικα, ποιες εκδόσεις υποστηρίζονται, ποια αποδεικτικά στοιχεία συνοδεύουν μια έκδοση, τι συμβαίνει με τις επιδιορθώσεις κατά τη διάρκεια της περιόδου υποστήριξης και ποιο υλικό μπορεί να διατηρήσει ο πελάτης για να διασφαλίσει τη συνέχεια. Ένας αγοραστής θα πρέπει να εκτιμά τη δυνατότητα επιθεώρησης και μετακίνησης. Θα πρέπει επίσης να κοστολογεί την ικανότητα που απαιτείται για να χρησιμοποιήσει αυτή τη δυνατότητα.

Δεν υπάρχει καμία αρετή στο να δημιουργείται μια εκτεταμένη διαδικασία για ένα μικρό βοηθητικό εργαλείο, και δεν υπάρχει καμία σύνεση στο να χρησιμοποιείται ένα μόνο διάγραμμα δραστηριότητας ως μοντέλο διακυβέρνησης για μια κρίσιμη υπηρεσία. Η αναλογικότητα είναι η πρακτική τέχνη εδώ. Όσο ευρύτερη είναι η έκθεση, όσο πιο σημαντικά τα δεδομένα, όσο δυσκολότερη η ανάκαμψη και όσο πιο κεντρικό το στοιχείο, τόσο ισχυρότερα θα πρέπει να είναι τα αρχεία και οι επιχειρησιακές ρυθμίσεις. Αυτό δεν είναι γραφειοκρατία για χάρη της γραφειοκρατίας. Είναι μια προσπάθεια να κρατηθεί η πραγματική απόφαση κοντά στην πραγματική συνέπεια.

Ο ανοιχτός κώδικας κερδίζει τη θέση του στην ευρωπαϊκή ψηφιακή υποδομή όταν βοηθά τους θεσμούς να παραμείνουν ικανοί: ικανοί να ελέγχουν, ικανοί να αλλάζουν, ικανοί να εξηγούν και ικανοί να συνεχίζουν. Η ικανότητα αποκτάται πιο αργά από τον ενθουσιασμό. Χρειάζεται χρόνο, ανθρώπους, τεκμηρίωση, δοκιμές και την περιστασιακή προθυμία να χρηματοδοτηθεί εργασία που δεν θα γίνει ποτέ βασική ομιλία σε συνέδριο. Είναι επίσης το πράγμα που παραμένει όταν ένα δημοφιλές αποθετήριο, μια σχέση με προμηθευτή ή ένα χρονοδιάγραμμα εκδόσεων αλλάζει χωρίς να ζητηθεί άδεια.

Αυτή είναι η υπευθυνότητα στη χρήσιμη, χωρίς λάμψη, πλήρως δημόσια μορφή της.

Πηγές