Parlando solo per me stesso (e avendo fatto decine di questi):
Se è closed-source, non vale il tempo della mia azienda.
Se la licenza open source causasse sopracciglia anche leggermente sollevate in Legal, non vale il tempo della mia azienda. LGPL va bene, Apache va bene, MIT va bene, GPL (qualsiasi versione) non lo è.
Se la documentazione non include i documenti dell'interfaccia completa minima, un tutorial veloce e una FAQ, non vale il tempo della mia azienda.
Se la libreria mi richiede di costruirlo prima che io possa usarlo, non vale il tempo della mia azienda.
Se la libreria non sembra avere una comunità di utenti rilevabile da google, non vale il tempo della mia azienda.
Se il rivenditore della biblioteca non pubblica una roadmap o non apre il proprio sistema di tracciamento dei problemi (anche di sola lettura), questi sono dei brutti segni, ma non dei downlink immediati a meno che tutti gli altri candidati non facciano meglio.
Questo taglia fuori il deadwood. Una volta che siamo lì, è il momento di progettare il bake-off. Un utile stufato deve avere una scala temporale fissa, un insieme fisso di criteri di valutazione e un set di caratteristiche fisse, che devono essere tutte scritte . Tutte le funzionalità del set di caratteristiche dovrebbero essere legate a un criterio di valutazione (idealmente esattamente uno dei criteri di valutazione). Per periodi di pausa più lunghi (in particolare quelli con > 2 candidati), dovrebbe esserci un checkpoint. Al checkpoint, tutti i candidati dovrebbero essere esaminati per vedere se qualcuno di loro è completamente dominato su tutti i criteri di valutazione. Qualsiasi candidato così dominato (o anche quasi completamente dominato) dovrebbe essere abbandonato a metà strada attraverso il bakeoff.
Tutto ciò sembra pignolo, ma l'alternativa sembra essere infinita criteri di valutazione che vanno nelle erbacce fino a quando la giustificazione aziendale originale per la tecnologia è obsoleta o ridotta attraverso la pura stanchezza.