In quali situazioni è una cattiva idea utilizzare il codice open source per un progetto aziendale?

Il più ovvio per me sono ...

• Quando i termini della licenza sono incompatibili con il modo in cui la società intende implementare il codice, ad es. la GPL potrebbe richiedere la distribuzione di altro codice nel tuo progetto che la tua azienda potrebbe non avere il diritto di distribuire.
• Quando il codice open source si sovrappone strongmente alle competenze chiave dell'azienda. Ad esempio, se la tua competenza principale è la progettazione di motori di rendering di giochi e grafica, non ha senso usare Ogre3D. Vedi link
• Quando il codice open source è scritto male, mal documentato e / o orribilmente bacato. Se ti ci vorrà più tempo per capire come utilizzare e correggere il codice piuttosto che tirarlo da solo, qual è il vantaggio?

Potrebbe anche essere un problema se si sospetta che il progetto open source abbia una direzione diversa in futuro rispetto a quella che si richiede. Hai la possibilità di mantenere la tua forchetta, ma poi perdi la maggior parte dei benefici a lungo termine dell'open source - più la forcella si allontana dal progetto originale, meno è probabile che gli altri trovino e correggano i bug per tu e contribuisci a nuove utili funzioni.

I rischi legati all'uso di una terza parte sono gli stessi indipendentemente dal fatto che siano open source o commerciali a codice chiuso. cose da verificare quando si sceglie una terza parte:

1. Licenza: la licenza è compatibile con il prodotto che stai costruendo. per la closed source cerca royalties e diritti di ridistribuzione. per l'open source cerca l'attribuzione e le licenze virali che potrebbero costringerti ad andare alla famiglia open source (GPL).

2. Supporto e sviluppo attivi. Quanto è stabile lo sviluppo di questa applicazione (azienda o comunità) C'è una piattaforma di supporto attiva (hotline di supporto, forum o mailing list), puoi vedere attività ultimamente su di loro se sono disponibili.

3. Quanto è rischioso rimanere bloccato con la libreria. Se sei bloccato con una libreria che non è più supportata, puoi assumere il supporto? qui avere la fonte può salvarti il culo almeno temporaneamente finché non trovi una sostituzione. Alcuni prodotti a sorgente chiusa avranno a disposizione mezzi per acquisire il codice sorgente, solitamente con spese extra.

questi sono i tre punti principali che cerco in una terza parte. Ovviamente non ho alcun background legale, quindi se lavori in un prodotto / dominio molto sensibile, prima chiedi prima a persone giuridicamente competenti.

La più grande cosa che trovo con l'open source è il supporto.

Il progetto open source è attivo? Se il progetto non è stato aggiornato in un determinato periodo di tempo e non vi è alcuna attività nei forum o nella community, potresti non essere in grado di correggere un errore.

C'è un supporto pagato? Se è scritto in una lingua che non conosci o non hai una strong esperienza nel tuo team, potresti davvero aver bisogno di un supporto a pagamento per sistemare qualcosa.

A seconda della tua azienda, potrebbe essere necessaria una revisione della sicurezza e, in caso di problemi, potresti non essere in grado di risolverli.

Una cosa che non ho visto nelle altre risposte è l'auditing.

Se stai facendo qualcosa che determinerà se un missile viene lanciato, o quanto spesso qualcuno respira, è molto importante avere un controllo. Se è necessario importare 20.000 righe di codice da una libreria open source "general purpose", di solito sarà più produttivo scrivere invece 2.000 righe di codice internamente solo per l'unico scopo specifico per cui è necessaria la libreria. Questo va molto più in là dove tutto il codice deve avere prove formali.