Not invented here
# Not invented here

Soprattutto nell'ambito della cultura anglosassone, con not invented here (lett. "non è stato inventato qui"), indicato anche con NIH o con sindrome NIH, ci si riferisce a quell'atteggiamento culturale sociale, aziendale o istituzionale che spinge ad evitare di utilizzare ricerche, normative, prodotti o conoscenze già esistenti a causa delle loro origini esterne e dei loro costi. Il termine è normalmente usato in senso peggiorativo.

Le ragioni per non voler utilizzare il lavoro degli altri sono molteplici e possono includere il timore di violazione di brevetti, la mancata comprensione o la mancanza di volontà nel riconoscere il valore del lavoro degli altri, la gelosia, o la semplice guerra per il dominio sul territorio. Come fenomeno sociale, questa filosofia si manifesta come una mancanza di volontà di adottare un'idea o un prodotto perché proviene da un'altra cultura, dando vita ad una forma di tribalismo.

## In informatica

Nell'ambito della programmazione ci si riferisce generalmente alla sindrome NIH come la tendenza a reinventare la ruota (cioè a reimplementare qualcosa che è già disponibile) basandosi sulla convinzione che lo sviluppo autonomo sia intrinsecamente più idoneo, più sicuro, più controllato, più veloce e meno costoso che utilizzare implementazioni già esistenti.

In alcuni casi viene reimplementato un software con le stesse funzionalità di uno già esistente (magari utilizzando semplicemente processi di reverse engineering) solamente per consentirne l'utilizzo con una diversa licenza software.

Le ragioni in favore dell'approccio NIH comprendono:

* I componenti o i servizi di terze parti a volte non sono all'altezza delle aspettative quando è necessaria alta qualità.
* Un'entità esterna al proprio controllo è un vendor lock-in e una minaccia costante per le imprese, proporzionale alle ripercussioni causate dalla perdita del supporto per le correzioni e i futuri aggiornamenti.
* Le soluzioni chiuse possono essere percepite come ostacoli ad una eventuale futura flessibilità del prodotto finale.

Alcuni approcci specifici in grado di attenuare queste problematiche:

* Una soluzione esterna può essere presa come base per la propria implementazione, anziché essere utilizzata direttamente (as-is).
* Il controllo di una soluzione esterna può essere assicurato in caso di problemi con gli sviluppatori originali, ad esempio cercando di ottenere il suo codice sorgente
