Ti importa che un software è "fonte disponibile" ma non "open source"

Per i progetti che avrebbero dovuto sviluppare da zero le funzionalità fornite da questo software, è decisamente utile non farlo.

Ma se un pacchetto open source comparabile sarebbe meglio dipende da altri fattori:

• sarà usato per fornire qualche servizio o raggrupparlo come parte di un altro prodotto?
• hanno le risorse per migliorare e mantenere il prodotto in modo indipendente?
• c'è un vantaggio competitivo nell'usare questo software rispetto alla versione open source (nel codice o nella gestione del progetto)?

Rispondere a no a uno di questi fattori indica che l'OSS è una scelta migliore.

La maggior parte delle volte, il codice in sé non è il fattore determinante. Uno ha bisogno di esaminare l'immagine più grande.

SIDEBAR I progetti OSS non possono legalmente promettere che manterranno aperte le versioni future o che ci saranno versioni future. Questo è uno dei motivi per cui avere una licenza aperta è così vantaggioso. Inoltre, i progetti OSS non sono tenuti ad accettare patch dai contributori (in particolare senza trasferimento di proprietà o diritti).

La domanda per questa e qualsiasi altra libreria esterna è manutenzione .

Qual è la durata della tua applicazione e qual è l'apparente durata di vita di questa libreria? Il tuo dovrebbe, si spera, essere il più breve.

Chi eseguirà correzioni di bug per questa libreria? Come sembra da qui, la tua azienda dovrebbe allocare esplicitamente risorse in futuro per la manutenzione di questo software, poiché non puoi fare affidamento su nessun altro bug di correzione per te. Non è possibile condividere l'onere di manutenzione con nessun altro poiché non è possibile condividere la fonte. Vuoi dare la caccia a un inafferrabile bug delle condizioni di gara in codice che non conosci?

Questo solo pensiero potrebbe rendere la libreria troppo costosa da usare.

Questo potrebbe essere irrilevante se la libreria è molto solida, robusta e facile da lavorare a livello sorgente, ma la mia esperienza è che la pressione tra pari di veri progetti open source rende semplicemente il codice migliore perché si tende a fare del proprio meglio poi.

Personalmente penserei molto attento se adottassi questo o qualsiasi altro codice esterno, dal momento che l'intera ragione per usare il codice di altri popoli è che non devi occupartene da solo . Pensa anche ai futuri manutentori: dovresti fare esercitazioni antincendio modificando il codice nella libreria per vedere se può essere fatto. Potrebbero esserci delle sorprese MOLTO brutte qui.

Sei libero di discutere la biblioteca in questione?

Per essere onesti, non vedo perché il team di gestione di un'azienda avrebbe problemi con l'utilizzo di una tale libreria di "fonte disponibile". Per quanto riguarda l'integrazione nel proprio prodotto, possono considerarlo semplicemente una libreria closed-source.

Per me, come programmatore, non importa se una libreria è "open source" o "fonte disponibile". Preferisco non apportare modifiche locali a una libreria esterna, poiché ciò comporta un ulteriore onere di manutenzione. Non solo quando si trovano bug nelle mie modifiche locali, ma anche sull'integrazione delle modifiche più e più volte quando esce una nuova versione della libreria.

Le uniche situazioni in cui, IMHO, "open source" batte la licenza "fonte disponibile" delineata nella domanda è quando

• la licenza del nostro prodotto richiede anche la divulgazione delle fonti delle librerie contenute
• ci occupiamo della produzione di una versione avanzata / estesa della libreria

Ecco perché la Free Software Foundation utilizza i termini "gratuito" o "non libero" per descrivere il software. Non si riferiscono al prezzo, ma alle restrizioni imposte all'uso o alla distribuzione del software.

Sembra che tu abbia colpito uno dei rari casi d'angolo in cui hai pieno accesso al codice sorgente di qualcosa, ma il software non è "Open Source" dal Definizione OSI .

Ciascun termine ha la capacità di diventare un termine improprio. Ho pagato $ 50 per la mia prima copia di emacs (su nastro QIC), ma emacs è software libero . Ho il codice sorgente di alcune applicazioni proprietarie che la mia azienda utilizza internamente, ma non sono open source.

La cosa che solleva la più grande bandiera rossa (almeno per me) non garantisce l'accesso al codice sorgente delle versioni future. Se dipendi strongmente dalla possibilità di modificare questo strumento, starei attento. Anche se hai un accordo verbale con il venditore che avrai sempre il codice, a meno che non sia in forma di contratto .. tale accordo non è mai avvenuto.

Come CTO, faccio del mio meglio per assicurarmi che non dipenda da software non libero. Sono stato in una brutta fine del blocco del venditore in diverse occasioni in passato, un errore che mi piace evitare. Mentre usiamo alcune cose proprietarie, la nostra azienda non subirebbe inutili difficoltà se all'improvviso non potremmo più utilizzarla.

Mi sembra che tu stia costruendo roba con questo software e accedendo al codice, quindi consiglierei di scrivere qualcosa che dice che hai sempre accesso. Cosa succede se il venditore è acquistato?

Questo importa un bel po '. Principali problemi con l'approccio "fonte disponibile" che hai descritto:

• Non hai il controllo del tuo destino tecnologico se non hai la libertà di modificare la fonte. Spesso l'hacking diretto della fonte può essere preferibile a una soluzione disordinata.
• Non hai alcuna garanzia che il software continui a essere mantenuto, e non hai l'opzione di fall-back di farlo tu stesso che ottieni con vero open source.
• Poiché sembra una licenza personalizzata, probabilmente hai un rischio legale maggiore rispetto all'uso di qualcosa di ben noto e provato come le licenze GPL o BSD.
• Se non è un vero open source, non avrai lo stesso livello di comunità utile attorno ad esso che è un vantaggio importante per molti progetti open source

Il mio suggerimento: cerca di convincere il creatore a rilasciare il software con una licenza open source. Questo dovrebbe essere una vittoria / vittoria per tutti: perché tu hai il software che vuoi con le licenze open source, il creatore perché rendere il progetto open source può rendere il software molto più efficace a lungo termine.