Зашто се 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.
Обратите пажњу шта ради средња колона. Сваки ред тражи документ који или постоји или не, што мишљење претвара у резултат који неко може дати или одбити.
Одвојите клијента од услуге
Уговор о подршци за клијентску апликацију није обавеза у вези са сервером до којег стиже ваш саобраћај. Пре него што представите доказе, означите који делови пута су у надлежности партнера, а које ви управљате у његово име. Мешање обоје ствара пакет докумената који изгледа темељно и ни на шта не одговара.
Ако је распоређивање ваше, партнеру можда треба да верује само идентитету и правилу приступа, што је много мањи захтев од поверења у цео ваш ланац снабдевања софтвером. Ако је распоређивање његово, клијент који преферирате може бити неважан и конфигурација капије постаје тема. Утврђивање у ком сте случају пре другог састанка штеди један циклус прегледа.
Затим проверите оперативна питања на којима прегледи заиста падају: ко уклања налог, колико брзо и какви докази постоје после. Лепо документована процена без поступка уклањања и даље је отворен налаз.
Завршите одлуком, а не расправом
Завршите размену писаним резултатом: прихваћена верзија, контроле повезане с њом, именовани оператери, докази који још недостају и датум до којег треба да буду достављени. Све нерешено треба забележити као услов, уместо да се упије у општу изјаву о одобрењу.
Ако политика именује конкретан одобрени производ, користите пут изузетка уместо да градите паралелни аранжман који нико није овластио. Убедљив технички аргумент не даје дозволу, а незванично распоређивање је налаз који чека да буде откривен.
Ако се захтев заиста не може испунити, пређите на одобрену алтернативу и реците зашто. Циљ вежбе је да се утврди на шта организација може да се ослони, а јасно „не“ је бољи резултат од одобрења које касније нико не може да одбрани.