La saggezza dell'uso del codice open source in un prodotto software commerciale

È una scelta che dovrai fare in base alle circostanze specifiche. Puoi mitigare i rischi:

• testare accuratamente il framework, evitando la probabilità di brutte sorprese che ti mordono in un ambiente di produzione, e
• utilizzando l'accoppiamento libero per ridurre al minimo la quantità di codice che dipende direttamente dal framework, in modo da poter passare alla propria implementazione se è necessario senza riscrivere l'intero prodotto.

In definitiva, con un progetto open source molto utilizzato è probabile che tu dedichi molto più tempo a scrivere il tuo che a correggere i pochi problemi in cui ti imbatti.

Arriverò a dire che se la tua reazione iniziale è scrivere qualcosa tu stesso invece di vedere se qualcun altro l'ha scritto, sei destinato a fallire. Non prendere alla leggera tutte le ore uomo e il bug fixing che è entrato nei progetti open source mainstream.

Una volta iniziato a entrare nel tuo dominio aziendale, ti sarà più difficile trovare OSS che soddisfi le tue esigenze. Ma non è necessario reimplementare ancora un altro prodotto ORM. Se dapper è abbastanza complesso da non essere in grado di eseguire il debug e correggere il loro codice, come giustifichere di spendere tutte le ore uomo a scriverlo da zero? Inoltre, potresti (dovresti?) Guardare sempre fuori dagli schemi delle soluzioni NoSQL mentre ci sei.

Anche Linus ha ammesso di aver tentato di trovare una soluzione SCM che soddisfacesse tutti i suoi criteri prima di sviluppare Git. Almeno era in grado di spiegare perché nessuna delle soluzioni esistenti fosse abbastanza buona.

Ad un certo punto della mia vita ho smesso di voler riscrivere tutto da solo e volevo concentrarmi sulla risoluzione dei problemi del mondo reale. La maggior parte dei problemi che devono essere risolti in un'azienda sono specifici del dominio. Trova modi per scrivere meno codice non di più.

Nota: Non sono un dipendente Microsoft. L'opinione è completamente personale. Molti pensieri risalgono agli ultimi 5-7 anni di utilizzo sia di open source che di grandi venditori come sviluppatori.

La monocoltura è buona: La mia regola personale per ASP.NET è di dare la preferenza a Microsoft e non scegliere il codice di terze parti (open source o meno) a meno che non ci sia altra scelta. La monocultura è gratificante, perché sei trasportato da un grande venditore e la quantità di utenti che ripete la stessa esperienza è in qualsiasi momento abbastanza grande da ricevere aiuto e trovare soluzioni alternative.

Città fantasma: Il problema con l'open source nel 2012 è che non è più il 2000 o il 2005. La quantità di progetti continua a crescere, quando la quantità di utenti, le adozioni, i contributori è più o meno la stessa di anni fa. Il pubblico è magro. Molti progetti interessanti sono diventati obsoleti, abbandonati. Non esiste un budget di progetto open source. Quindi, quando l'interesse finisce, non c'è nessuno che possa annunciare onestamente che il supporto è finito e spegnere le luci. I progetti non muoiono mai per lasciare l'attenzione pubblica a qualcosa di meglio e di nuovo. Quindi l'open source continuerà sempre a crescere e frammentarsi. Senza feedback in forma di ricompensa monetaria o morte finanziaria, sono entità immortali, esistenti per amore della gloria eterna.

20 gradi di separazione: Ogni tua adozione di una nuova biblioteca ti separa dal mainstream, ti porta a una minoranza di casi limite. Dopo aver eseguito 20 passaggi, come scegliere la configurazione di sicurezza, utilizzando una particolare versione, framework, plug-in, ecc. La soluzione diventa un'unica combinazione di dettagli globalmente unica. Googling aiuterà solo a dimostrare quanto sia raro o unico il problema. È sempre un problema autonomo, puramente tecnico. Mai nemmeno rilevante per gli affari reali.

La qualità viene dall'obiettivo, il denaro è irrilevante: Non ci sono sostegni di software commerciale vs open source. Tutta la comunità di sviluppatori è solo una comunità come sempre. I grandi venditori hanno semplicemente il vantaggio di invecchiare più a lungo il codice, in condizioni migliori, con un pubblico più ampio rispetto ai gruppi open source.

Consenso: stai chiedendo se c'è consenso. Forse no. Sfortunatamente una grande quantità di utenti open source è troppo politicizzata. Dopotutto l'open source è un movimento sociale. L'open source è immune alla critica, perché molto spesso l'opinione negativa viene percepita come un attacco anti-tecnologico e personale. Il mio consenso personale: attenersi a Microsoft.

Ho lavorato su numerosi progetti di successo per una grande azienda che utilizzava una quantità considerevole di software open source. In particolare, ho utilizzato Curl, SQLite e Webkit tutti per una grande azienda su progetti di successo che sono stati inviati agli utenti finali. Come altri hanno già detto, è solo questione di fare attenzione alle licenze e idealmente avere un avvocato che le prenda in considerazione.

Esistono centinaia di licenze open source, ma generalmente rientrano in due categorie, lo stile BSD e lo stile GPL. Le licenze di stile BSD non richiedono l'open source del proprio codice e generalmente hanno solo una sorta di clausola di attribuzione. Le licenze in stile GPL richiedono l'apertura del codice personale. La maggior parte delle aziende (compresa la mia) in genere la guardano di traverso, quindi vorrete evitare lo stile GPL. Dapper sembra utilizzare la licenza Apache, che è in stile BSD. Scopri sempre quali sono i termini di licenza generali prima di iniziare la codifica.

C'è anche la LGPL, che è un caso di confine interessante in quanto è possibile utilizzarli senza aprire il proprio codice se si limita l'accesso a un confine binario. (Ad esempio, accedi alla libreria solo come libreria dinamica.) L'utilizzo della libreria LGPL è molto fattibile, devi solo stare più attento.

Secondo la mia esperienza, il codice open source non ha più probabilità di risultare bug o fail rispetto alle soluzioni for-pay o, per quel che riguarda, soluzioni roll-your-own. Se guardi alcuni degli strumenti open source più importanti, la qualità è molto alta.

Probabilmente vuoi evitare progetti piccoli o non completi. Può essere allettante afferrare qualcosa che sembra soddisfare i tuoi bisogni, ma se fossero qualcosa messo insieme da un paio di persone, mai completato e non supportato, probabilmente non ne vale la pena. (A meno che non siate disposti a lavorare direttamente sul codice.)

Non hai mai avuto guasti ai componenti proprietari prima? Ho incontrato molti bug nel software di aziende grandi e piccole. Questo problema non è un problema con l'open source di per sé, piuttosto è più sulla maturità del progetto.

Sembra che tu voglia usare progetti maturi che offrono supporto. Alcuni progetti open source offrono supporto a pagamento o una community abbastanza ampia da poter ottenere risposte in un forum pubblico. Forse dovresti fare la maturità e sostenere le priorità dei criteri quando scegli una biblioteca, sia che sia chiusa o open source.

Devi riconoscere che stai assumendo più rischi se decidi di utilizzare un progetto immaturo o uno con supporto limitato. In quanto tale è necessario determinare qual è il piano di mitigazione del rischio. Ad esempio, potresti eseguire più test sul software di terze parti.

Supponendo che i problemi di licenza non siano un problema qui: avendo una rapida occhiata a Dapper, ho notato che aveva appena 2255 linea di codice ben documentato e leggibile . Questo è

• abbastanza grande da poter investire diversi giorni o settimane per produrre codice di qualità comparabile facendo lo stesso
• abbastanza piccolo da poter capire cosa fa e correggere eventuali bug in quel codice se compaiono in produzione

Se vuoi scrivere qualcosa del genere da solo e "reinventare la ruota", hai un rischio molto più elevato che il tuo codice mostrerà bug in produzione, e sarai davvero "difficile da risolvere" " o.

Ciò che devi fare qui, tuttavia, se introduci un tale pezzo di open source nel tuo progetto, allora tu devi prendere la piena responsabilità per quel codice , proprio come se lo avessi scritto da solo. Assicurati che il codice sia in uno stato che puoi mantenerlo, se necessario. Non incolpare "gli autori" di quel codice se qualcosa non funziona come previsto.

In uno dei nostri progetti, anche noi abbiamo introdotto alcuni componenti open source, dalle dimensioni piccole come Dapper alle librerie che avevano circa 20K a 30K linee di codice. Abbiamo sempre per apportare alcune modifiche, correggere alcuni bug, ridimensionare qualcosa ecc., Ma era ok, dal momento che ci aspettavamo. Anche il tempo per il debug incluso, usando l'open source ci ha risparmiato un sacco di lavoro.

Una cosa a cui pensare qui: nel tuo caso menzioni che esiste un'alternativa ampiamente accettata da un grande fornitore disponibile (MS Entity Framework, per il quale non devi pagare nessun costo aggiuntivo di licenza!). Non si vuole usarlo a causa di considerazioni sulle prestazioni. Raccomando seriamente di non lasciare che le prestazioni siano l'unico o il punto principale da considerare. Le domande che dovresti porre qui: ha Dapper tutte le funzionalità di cui hai bisogno ora e per la durata prevista del tuo software? Oppure puoi prevedere che raggiungerai i limiti di Dapper rapidamente e dovrai aggiungere molte funzionalità mancanti attorno a ciò che probabilmente non avresti se avessi deciso di utilizzare EF in primo luogo? Se è il caso, raccomando di non usare Dapper. Inoltre, chiediti: EF non è abbastanza veloce per la tua applicazione, mentre Dapper è?

Come la vedo io, è un atto di bilanciamento.

Se ti rendi dipendente da un venditore, è quasi certo che il supporto sparirà presto

• Perché hanno i programmatori da pagare, quindi hanno bisogno di continuare a creare nuove versioni e assicurarsi che i vecchi siano impossibili da ottenere e non funzionino più (su piattaforme più nuove) così i nuovi avranno un mercato.

• Se non riescono a vendere a sufficienza per giustificare un modello di business, lo trasferiscono dalla società A alla società da B a C, ognuno dei quali lo modifica abbastanza di nuovo, non è possibile utilizzare il nuovo senza riprogrammazione e non è possibile ottenere quello vecchio che funziona.

• Decidono solo che non lo sosterranno più perché è troppo disturbo e non ci sono soldi in esso. Tutti i soldi sono nelle nuove app.

Quindi, se vuoi creare qualcosa che non debba essere continuamente riscritto ogni qualche anno, l'open source può essere tuo amico.

Penso che sia saggio se viene eseguita una due diligence sufficiente e sembra che tu abbia già fatto alcuni compiti per quanto riguarda la storia e l'attività di un particolare progetto. La possibilità di estendere / aggiungere funzionalità nel codice sorgente è anche un grande vantaggio. Con test sufficienti è possibile minimizzare il rischio da parte dell'utente. È difficile comprendere completamente tutte le dipendenze del codice, ma almeno in quel caso sarai in grado di eseguire il debug e visualizzare il codice se necessario.

Chiedi alla direzione perché aveva fallito prima, era sufficiente la dovuta diligenza?

jquery ha la possibilità di usare la licenza MIT, così molti siti commerciali e governativi usano anche jquery. Anche il sito Web di Microsoft utilizza jQuery! Quindi la preoccupazione è la concessione di licenze. Evitare l'uso di GPL / LGPL è sufficiente.

"Quanto tempo ci vuole per correggere un difetto segnalato?" Dopo aver segnalato il bug, potrebbe essere risolto in pochi minuti, ore o giorni. Per situazioni urgenti, il personale può semplicemente "tirare a calci" per ottenere la fonte e compilare lui stesso. Segnala semplicemente la versione come "v1.2.3-101-gd62fdae" alla gestione, che è tracciabile.

L'open source riguarda davvero la legalità, non la qualità del codice. Esistono buoni e cattivi prodotti open source, così come ci sono quelli buoni e cattivi a codice chiuso. Credo che il tuo dilemma sia se utilizzare un progetto sviluppato da una comunità di volontari.

Sei sicuro che i problemi di gestione sono problemi tecnici.

Dico questo come un mix di sistema operativo e attività commerciale è un campo minato legale, e più di un manager ha avuto un "Please Explain" dal team legale / CEO o peggio, da un'altra organizzazione. La maggior parte dei manager che conosco, anche quelli che abbracciano attivamente il software del sistema operativo, sono (giustamente) molto cauti nel comprendere appieno le situazioni legali a cui stanno esponendo l'origine. Se si adotta il software del sistema operativo e si apportano modifiche, si è obbligati a restituire tali modifiche alla comunità. In alcuni casi, questo obbligo è legale, in altri morale. In alcune licenze OS, tutto ciò che fai diventa OS semplicemente collegandoti a loro.

Da un punto di vista tecnico, è davvero solo una decisione tra prodotti concorrenti - Fai alcune domande di base - Puoi ottenere il supporto di cui hai bisogno per il pacchetto che scegli ?, Quanto tempo per ottenere una correzione a un difetto segnalato, quanto sarà ha un costo per sviluppatore, per anno o uno spento ecc. Il sistema operativo ha molti 0 nella colonna $, ma spesso ha spazi vuoti negli altri - solo tu e il tuo capo potete decidere che gli 0 fuori pesano gli spazi vuoti o meno.

E un altro punto da ricordare - "Nessuno è mai stato licenziato comprando IBM". (ad esempio, la direzione parla per "Se spendi molti soldi, deve essere un prodotto migliore di uno gratuito"