Γιατί ένα VPN ανοιχτού κώδικα απορρίπτεται στις προμήθειες
Ένας αξιολογητής που αντιτίθεται στο ανοιχτό λογισμικό συνήθως προστατεύει μια απαίτηση, όχι μια προτίμηση άδειας. Ρωτήστε ποια, και μετά προσκομίστε το τεκμήριο που την απαντά.
Οι απορρίψεις που επικαλούνται το ανοιχτό λογισμικό σπάνια αφορούν την άδεια. Ο αξιολογητής συνήθως προστατεύει μια απαίτηση: ότι κάποιος συντηρεί την έκδοση που έχει αναπτυχθεί, ότι η εγκατεστημένη έκδοση μπορεί να ταυτοποιηθεί, ότι μια αξιολόγηση καλύπτει αυτό που συνδέεται ή ότι η σύνδεση μπορεί να ανακληθεί. Η συζήτηση που ακολουθεί συνήθως απαντά σε ένα ερώτημα που δεν έθεσε κανείς.
Ρωτήστε ποια απαίτηση ισχύει πριν υπερασπιστείτε μια άδεια. Η απάντηση καθορίζει ποιο έγγραφο χρειάζεστε.
Η ετικέτα δεν είναι η απαίτηση
Ο αναγνώσιμος πηγαίος κώδικας σημαίνει ότι η δημοσιευμένη υλοποίηση μπορεί να επιθεωρηθεί. Δεν σημαίνει ότι κάποιος την επέβλεψε, ότι η έκδοση στην πύλη ταιριάζει με τη δημοσιευμένη ή ότι ένας συντηρητής οφείλει διόρθωση στην ανάπτυξή σας. Καθένα από αυτά είναι ξεχωριστός ισχυρισμός με ξεχωριστό ιδιοκτήτη, και ένας αξιολογητής που χρειάζεται έναν από αυτούς δεν θα ικανοποιηθεί από τους άλλους. Το να ονομάσετε τον ισχυρισμό φωναχτά αρκεί συνήθως για να αλλάξει η συζήτηση.
Το αντίστροφο λάθος είναι εξίσου συχνό. Μια εμπορική άδεια δεν αποδεικνύει ότι η υποστήριξη καλύπτει τη λειτουργία στην οποία βασίζεστε, ότι μια αξιολόγηση εξέτασε το στοιχείο που αναπτύσσετε ή ότι ο προμηθευτής θα στείλει διόρθωση εντός του παραθύρου συντήρησής σας. Η αδειοδότηση περιγράφει όρους διανομής, ενώ οι αποφάσεις προμήθειας αφορούν την εξάρτηση. Και στις δύο περιπτώσεις, η άδεια είναι το λιγότερο κατατοπιστικό μέρος της απάντησης.
Κρατήστε τον πελάτη και την υπηρεσία χωριστά. Ένας έλεγχος ενός πελάτη υπολογιστή δεν λέει τίποτα για τη διαμόρφωση της πύλης του συνεργάτη, τον πάροχο ταυτότητας ή τον τρόπο με τον οποίο οι χειριστές του χειρίζονται τη διαγραφή λογαριασμών. Όποια στοιχεία συγκεντρώσετε πρέπει να αντιστοιχούν στο όριο που καλείται να εμπιστευτεί ο συνεργάτης.
Μετατρέψτε την ανησυχία σε τεκμήριο
Ζητήστε από τον εγκρίνοντα να διατυπώσει την απαίτηση σε μία πρόταση και μετά ονομάστε το τεκμήριο που θα την ικανοποιούσε. Η αόριστη καθησύχαση είναι αυτή που μετατρέπει αυτές τις συζητήσεις σε διαμάχη για την ιδεολογία.
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework είναι χρήσιμο εδώ για έναν στενό λόγο: πλαισιώνει τις συζητήσεις προμήθειας γύρω από ένα κοινό λεξιλόγιο πρακτικών και επικοινωνίας με προμηθευτές. Αυτό στηρίζει το αίτημα για ορισμένα στοιχεία αντί για διαμάχη γύρω από μια ετικέτα, και δεν είναι πιστοποίηση που περνά κάποιο συγκεκριμένο VPN.
Προσέξτε τι κάνει η μεσαία στήλη. Κάθε γραμμή ζητά ένα έγγραφο που είτε υπάρχει είτε όχι, κάτι που μετατρέπει μια γνώμη σε παραδοτέο που κάποιος μπορεί να παράγει ή να αρνηθεί.
Διαχωρίστε τον πελάτη από την υπηρεσία
Μια σύμβαση υποστήριξης για μια εφαρμογή πελάτη δεν είναι δέσμευση για τον διακομιστή στον οποίο φτάνει η κίνησή σας. Πριν παρουσιάσετε στοιχεία, σημειώστε ποια μέρη της διαδρομής διαχειρίζεται ο συνεργάτης και ποια διαχειρίζεστε εσείς για λογαριασμό του. Η ανάμειξη των δύο παράγει ένα πακέτο εγγράφων που φαίνεται ενδελεχές και δεν απαντά σε τίποτα.
Αν η ανάπτυξη είναι δική σας, ο συνεργάτης μπορεί να χρειάζεται να εμπιστευτεί μόνο μια ταυτότητα και έναν κανόνα πρόσβασης, που είναι πολύ μικρότερο αίτημα από το να εμπιστευτεί ολόκληρη την αλυσίδα προμήθειας λογισμικού σας. Αν η ανάπτυξη είναι δική του, ο πελάτης που προτιμάτε μπορεί να είναι άσχετος και η διαμόρφωση της πύλης γίνεται το θέμα. Το να ξεκαθαρίσετε ποια περίπτωση ισχύει πριν από τη δεύτερη συνάντηση εξοικονομεί έναν κύκλο αξιολόγησης.
Στη συνέχεια ελέγξτε τα επιχειρησιακά ερωτήματα στα οποία πραγματικά αποτυγχάνουν οι αξιολογήσεις: ποιος αφαιρεί έναν λογαριασμό, πόσο γρήγορα και ποια στοιχεία υπάρχουν μετά. Μια όμορφα τεκμηριωμένη αξιολόγηση χωρίς διαδικασία αφαίρεσης παραμένει ανοιχτό εύρημα.
Κλείστε με απόφαση, όχι με αντιπαράθεση
Ολοκληρώστε την ανταλλαγή με ένα γραπτό αποτέλεσμα: την έκδοση που έγινε δεκτή, τα μέτρα ελέγχου που συνδέονται με αυτήν, τους ονομαζόμενους χειριστές, τα στοιχεία που εκκρεμούν και την ημερομηνία κατά την οποία οφείλονται. Κάθε άλυτο ζήτημα πρέπει να καταγράφεται ως προϋπόθεση αντί να απορροφάται σε μια γενική δήλωση έγκρισης.
Αν η πολιτική ονομάζει συγκεκριμένο εγκεκριμένο προϊόν, χρησιμοποιήστε την οδό εξαίρεσης αντί να χτίσετε μια παράλληλη ρύθμιση που κανείς δεν εξουσιοδότησε. Ένα πειστικό τεχνικό επιχείρημα δεν παρέχει άδεια, και μια ανεπίσημη ανάπτυξη είναι εύρημα που περιμένει να ανακαλυφθεί.
Αν μια απαίτηση πραγματικά δεν μπορεί να ικανοποιηθεί, προχωρήστε στην εγκεκριμένη εναλλακτική και πείτε γιατί. Ο σκοπός της άσκησης είναι να καθοριστεί σε τι μπορεί να βασιστεί ο οργανισμός, και ένα σαφές όχι είναι καλύτερο αποτέλεσμα από μια έγκριση που κανείς δεν μπορεί να υπερασπιστεί αργότερα.