Saggezza nell'uso del codice open source in un prodotto software commerciale

Sto cercando di utilizzare un codice open source nella mia app Web ASP.NET (in particolare dapper ). Il management non è un fan, perché l'open source è visto come un rischio che ci ha morso prima. Apparentemente gli sviluppatori precedenti hanno dovuto riscrivere le cose dopo aver fallito i componenti open source.

I professionisti sembrano essere:

• Fa un sacco di cose per me che altrimenti implicherebbero un sacco di codice boilerplate o la soluzione raccomandata ma più lenta di Microsoft (Entity Framework).

Contro:

• È abbastanza complesso che se fallissi improvvisamente nella produzione, mi farebbe fatica a risolverlo. Tuttavia, è in uso su un sito a traffico molto più alto del mio, quindi non credo che finirà per essere una parte ad alto rischio del progetto.

Qual è il consenso qui? Non è saggio utilizzare il codice open source nel mio progetto che non conosco / capisco così come faccio il mio codice?

È una scelta che dovrai fare in base alle circostanze specifiche. Puoi mitigare i tuoi 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, quindi è possibile passare alla propria implementazione se è necessario senza riscrivere l'intero prodotto.

In definitiva, con un progetto open source molto utilizzato probabilmente passerai molto più tempo a scrivere il tuo che a risolvere i pochi problemi che incontri.

Arriverò al punto di dire che se la tua reazione iniziale è quella di 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 la correzione di errori che sono andati nei progetti open source tradizionali.

Una volta che inizi a entrare nel tuo dominio aziendale, avrai più difficoltà a trovare l'OSS che soddisfa le tue esigenze. Ma non è necessario implementare nuovamente un altro prodotto ORM. Se dapper è abbastanza complesso da non essere in grado di eseguire il debug e correggere il loro codice, come giustificherebbe passare tutte le ore uomo a scriverlo da zero? Inoltre, potresti (dovresti?) Guardare sempre fuori dagli schemi le 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 è stato in grado di spiegare perché nessuna delle soluzioni esistenti era 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 sono degli ultimi 5-7 anni di utilizzo di entrambi open source in combinazione con grandi fornitori come sviluppatori.

La monocultura è buona: la mia regola personale per ASP.NET è quella di dare la preferenza a Microsoft e non scegliere 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 è sempre abbastanza grande da ottenere 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, adozioni, contributori è più o meno la stessa di anni fa. Il pubblico è magro. Molti progetti interessanti sono diventati stantii, abbandonati. Non esiste un budget di progetto open source. Quindi, quando l'interesse termina, non c'è nessuno che annunci onestamente che il supporto è finito e spegne le luci. I progetti non muoiono mai per focalizzare l'attenzione del pubblico su qualcosa di meglio e di nuovo. Quindi l'open source continuerà sempre a crescere e frammentarsi. Non avendo feedback in forma di ricompensa monetaria o morte finanziaria, sono entità immortali, esistenti per il bene della gloria eterna.

20 gradi di separazione: ogni tua adozione di una nuova libreria ti separa dal mainstream, ti sposta alla minoranza dei casi limite. Dopo aver fatto 20 passaggi come scegliere la configurazione della sicurezza, usare una versione, un framework, un plug-in, ecc. Particolari, la tua soluzione diventa un'unica combinazione globale di dettagli. Googling aiuterà solo a dimostrare quanto sia raro o unico il problema. È sempre un problema egoistico, puramente tecnico. Mai nemmeno rilevante per il vero business.

La qualità viene dalla concentrazione, il denaro è irrilevante: non c'è distacco tra software commerciale e open source. Tutta la comunità di devellopers è solo una comunità come sempre. I grandi fornitori hanno semplicemente il vantaggio di invecchiare il codice più a lungo, in condizioni migliori, con un pubblico più ampio rispetto ai gruppi open source.

Consenso: stai chiedendo se c'è consenso. Forse no. Purtroppo un gran numero di utenti open source è troppo politicizzato. Dopo tutto l'open source è un movimento sociale. L'open source è immune alla critica, perché molto spesso l'opinione negativa verrà percepita come un attacco personale anti-tecnologico. Il mio consenso personale: attenersi a Microsoft.

Ho lavorato a numerosi progetti di successo per una grande azienda che utilizzava notevoli quantità di software open source. In particolare, ho usato Curl, SQLite e Webkit tutti per un'azienda molto grande su progetti di successo che venivano spediti agli utenti finali. Come altri hanno già detto, si tratta solo di stare attenti alle licenze e idealmente di farle controllare da un avvocato.

Esistono centinaia di licenze open source, ma generalmente rientrano in due categorie, stile BSD e stile GPL. Le licenze in stile BSD non richiedono l'apertura di un codice personale e generalmente dispongono di una sorta di clausola di attribuzione. Le licenze in stile GPL richiedono che tu abbia open source il tuo codice. La maggior parte delle aziende (inclusa la mia) in genere lo chiedono, quindi ti consigliamo di evitare lo stile GPL. Dapper sembra usare la licenza Apache, che è in stile BSD. Capire sempre quali sono le condizioni generali di licenza prima di iniziare a scrivere codice.

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

Nella mia esperienza, il codice open source non ha maggiori probabilità di rivelarsi difettoso o fallire rispetto alle soluzioni a pagamento o, al contrario, alle soluzioni roll-your-own. Se osservi alcuni dei più importanti strumenti open source, la qualità è molto alta.

Probabilmente vuoi evitare progetti piccoli o non completi. Può essere allettante prendere qualcosa che sembra soddisfare le tue esigenze, ma se fossero state messe insieme da un paio di persone, mai completate e non supportate, probabilmente non vale la pena. (A meno che tu non sia disposto a lavorare direttamente sul codice.)

Non hai mai avuto guasti ai componenti proprietari prima? Ho riscontrato molti bug nel software di aziende grandi e piccole. Questo problema non è un problema con l'open source in sé, ma riguarda piuttosto la maturità del progetto.

Sembra che tu voglia utilizzare progetti maturi che offrono supporto. Alcuni progetti open source offrono supporto a pagamento o hanno una comunità abbastanza grande da poter ottenere risposte in un forum pubblico. Forse dovresti dare priorità ai criteri di maturità e supporto quando scegli una libreria, sia essa chiusa o open source.

È necessario riconoscere che si sta assumendo più rischi se si decide di utilizzare un progetto immaturo o uno con un supporto limitato. Pertanto, è necessario determinare qual è il piano di mitigazione del rischio. Ad esempio, è possibile eseguire ulteriori test sul software di terze parti.

Supponendo che i problemi di licenza non siano un problema qui: dando una rapida occhiata a Dapper, ho notato che aveva solo 2255 righe 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 hai intenzione di scrivere qualcosa del genere da solo e "reinventare la ruota", hai un rischio molto più alto che il tuo codice mostri i bug nella produzione, e sarai anche davvero "molto impegnato a risolverli".

Quello che devi fare qui, tuttavia, se introduci un tale pezzo di open source nel tuo progetto, allora devi assumerti la piena responsabilità di 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 righe di codice. Abbiamo sempre dovuto apportare alcune modifiche, correggere alcuni bug, ridimensionare qualcosa ecc., Ma andava bene, dal momento che ci aspettavamo che. Anche il tempo per il debug incluso, l'uso dell'open source ci ha permesso di risparmiare molto lavoro.

Una cosa a cui pensare qui: nel tuo caso dici che esiste un'alternativa ampiamente accettata da un grande fornitore disponibile (MS Entity Framework, per il quale non devi pagare costi di licenza extra!). Non vuoi usarlo a causa di considerazioni sulle prestazioni. Consiglio vivamente di non lasciare che le prestazioni siano l'unico o principale punto da considerare. Le domande che dovresti porre qui: Dapper ha tutte le funzionalità di cui hai bisogno ora e per la durata prevista del tuo software? Oppure puoi prevedere che raggiungerai rapidamente i limiti di Dapper e dovrai aggiungere molte funzionalità mancanti, cosa che probabilmente non dovresti fare se avessi deciso di utilizzare EF in primo luogo? In quest'ultimo caso, consiglierei di non usare Dapper. Chiediti anche: EF non è davvero abbastanza veloce per la tua applicazione,

A mio avviso, è un atto di bilanciamento.

Se ti fai dipendere da un fornitore, è quasi certo che il supporto scomparirà presto

• Perché hanno programmatori da pagare, quindi devono continuare a creare nuove versioni e assicurarsi che quelle vecchie siano impossibili da ottenere e non funzionino più (su piattaforme più recenti), quindi quelle nuove avranno un mercato.

• Se non riescono a vendere abbastanza per giustificare un modello di business, lo passano dalla società A alla società da B a C, ognuna delle quali lo cambia di nuovo in modo sufficiente, non è possibile utilizzare quello nuovo senza riprogrammare, e si può ' Prendi quello vecchio che funziona.

• Decidono solo che non lo sosterranno più perché sono troppi problemi e non ci sono soldi. Tutti i soldi sono in nuove app.

Quindi, se vuoi costruire qualcosa che non debba essere continuamente riscritto ogni pochi anni, l'open source può essere tuo amico.

Penso che sia saggio se viene fatta una adeguata due diligence 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 ridurre al minimo il rischio. È difficile comprendere completamente tutte le dipendenze nel tuo codice, ma almeno in questo caso sarai in grado di eseguire il debug completo e visualizzare il codice se necessario.

Chiedere alla direzione perché non aveva funzionato in precedenza, è stata effettuata una due diligence sufficiente?

jquery ha la possibilità di utilizzare la licenza MIT, quindi anche molti siti web commerciali e governativi usano jquery. Anche il sito Web di Microsoft usa jquery! Quindi la preoccupazione è la licenza. Evitare l'uso di GPL / LGPL è sufficiente.

"Per quanto tempo ottenere una correzione per un difetto segnalato?" Dopo aver segnalato il bug, potrebbe essere risolto in pochi minuti, ore o giorni. Per situazioni urgenti, il personale può semplicemente "estrarre" per ottenere la fonte e compilarla da solo. Riferisce semplicemente la versione come "v1.2.3-101-gd62fdae" alla direzione, che è rintracciabile.

L'open source riguarda davvero la legalità, non la qualità del codice. Ci sono buoni e cattivi prodotti open source, così come ce ne sono di buoni e cattivi quelli chiusi. Credo che il tuo dilemma sia se usare un progetto sviluppato da una comunità di volontari.

Sei sicuro che il problema delle gestioni sia un problema tecnico.

Lo dico perché il mix di SO e attività commerciale è un campo minato legale e più di un manager ha ricevuto 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 è tenuti a restituire tali modifiche alla comunità. In alcuni casi, questo obbligo è legale, in altri morali. In alcune licenze del sistema operativo, tutto ciò che fai diventa OS semplicemente collegandoti ad esse.

Da un punto di vista tecnico, è davvero solo una decisione tra prodotti concorrenti - Poni alcune domande di base - Puoi ottenere il supporto di cui hai bisogno per il pacchetto che scegli ?, Quanto tempo per ottenere una correzione per un difetto segnalato, quanto costerà sviluppatore, per anno o una tantum, ecc. Il sistema operativo ha molti 0 nella colonna $, ma spesso ha degli spazi vuoti negli altri - solo tu e il tuo capo potete decidere se lo 0 è in peso o meno.

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