Quali sono i casi in cui mantenere segreto il codice sorgente è giustificato?

8

Quando lavoravo come libero professionista, ho incontrato molti casi in cui i clienti proteggevano le loro idee e il codice sorgente dei loro progetti (come le applicazioni web) il più possibile, indipendentemente da quanto poco importanti, poco interessanti e poco originali fossero i progetti e i concetti dietro.

Ho già postato una domanda su come mantenere segrete le idee e ho ricevuto molte ottime risposte. Ora, la mia preoccupazione riguarda maggiormente il segreto del codice sorgente.

Secondo le mie osservazioni su:

  • I codebase su cui ho dovuto lavorare durante la mia carriera
  • La mia stessa disponibilità a mantenere alcuni dei miei codici sorgente segreti e:
  • Alcuni articoli come, ad esempio, risposta aperta a Simon Stuart dal famoso collaboratore di Programmers.SE Mason Wheeler ,

Concludo che il codice sorgente è tenuto segreto soprattutto per questi motivi:

  1. Perché l'autore si vergogna del codice di una tale pessima qualità, o la società teme di perdere la reputazione se qualcuno vede una tale base di codice errata, o che data la bassa qualità della base di codice, non porterà nulla di utile a chiunque l'abbia open source: anche se qualcuno fosse interessato, difficilmente sarebbe in grado di eseguire la soluzione (o, spesso, anche compilare).

  2. Poiché parti del codice vengono rubate (principalmente da progetti open source coperti da una licenza che ne limita l'utilizzo in una determinata situazione),

  3. Poiché il codice si basa sulla sicurezza per oscurità e all'autore non interessa il principio di Kerckhoffs .

  4. Poiché il prodotto è così fragile che la visualizzazione del codice causerebbe troppi danni: se un'app closed-source con tutte quelle fughe di sicurezza resistesse a un hacker principiante, la stessa app open source avrebbe possibilità molto minori, perché anche il l'hacker principiante dovrebbe solo studiare il codice per scoprire tutti i buchi.

    Se non è chiaro di cosa sto parlando, ecco un esempio:

    if (credentials.password === 'masterPassword12345')
    {
        isLoggedIn = true
        currentUser = credentials.userName
    }
    else
    {
        authenticate(credentials)
    }
    
  5. Poiché l'autore ha sovrastimato il codice sorgente (e le sue capacità e competenze). Esempio: credere che un algoritmo basato sulla crittografia fatta in casa (che non è mai stato rivisto da nessuno) è migliore di qualsiasi altro ben noto.

  6. Perché l'autore ritiene che l'idea alla base del codice sia ottima e che venga rubata.

  7. A causa della sindrome "Non è abbastanza perfetto". In altre parole, lo sviluppatore è disposto a rendere pubblico il codice sorgente quando il codice è "abbastanza buono", ma giorno dopo giorno ci sono ancora cose da migliorare, quindi il codice non verrebbe mai rilasciato.

Tutti questi motivi danno un'immagine negativa delle persone che sono contrarie alla pubblicazione del codice sorgente.

Ci sono casi validi per non rilasciare al pubblico il codice di alta qualità che segue il principio di Kerckhoffs?

    
posta Arseni Mourzenko 03.09.2013 - 00:03
fonte

6 risposte

25

Alcune persone e molte aziende hanno una strana percezione del valore del codice.

"Abbiamo speso $ 100.000 per questo progetto, quindi il codice deve valere" e sentirsi in dovere di proteggerlo.

In realtà la maggior parte del codice è più simile alla pittura. Spendi $ 100 su vernice e $ 200 dollari per applicarlo alle tue pareti. Ma ora la vernice non vale niente, non puoi venderla, nessuno la vuole, e anche se lo facessero non puoi prenderla dal muro e metterla sul muro di qualcun altro.

Può migliorare il valore dell'edificio ma non puoi realizzarlo senza vendere l'edificio.

Potresti "rubare" codice base Amazons (la maggior parte di esso è liberamente disponibile da vari progetti open source) e creare un sito web di Ammasson ma non ti occuperai di gran parte delle attività di Amazons.

Il codice è una parte necessaria di qualsiasi infrastruttura aziendale moderna, ma ha valore solo come parte di un processo e cultura, di per sé non vale niente.

Aggiungo che ci sono alcune situazioni in cui il codice è vitale per il business e sarebbe abbastanza prezioso per qualsiasi concorrente che dovrebbe essere tenuto segreto:

  • Per impedire la manipolazione dannosa delle tue strutture - un buon esempio potrebbe essere il sistema di "page rank" di Google che viene costantemente "giocato" per dare ai siti web un posizionamento ingiustificatamente alto.
  • Algoritmi di trading automatizzati - un concorrente senza scrupoli potrebbe studiare l'algoritmo e ingannare il tuo sistema in vendite troppo basse e acquistare troppo alto.
  • Un algoritmo "più veloce / migliore" - se il punto di vendita unico del tuo software è un algoritmo più veloce per ordinare / comprimere / qualsiasi altra cosa, allora probabilmente è meglio mantenere questo segreto commerciale il più a lungo possibile.
risposta data 03.09.2013 - 03:27
fonte
6

Perché è stato difficile scrivere e testare . E il design. E specificare. E debug. E ISO 9000. E documento. E il controllo della versione. E ottenere il capo dai capelli a punta di mezzo. E qualunque cosa renda utile il lavoro di un ingegnere del software.

E non vuoi che i tuoi concorrenti copino e incollino il codice sorgente invece di dedicare tutto il tempo e i soldi che hai nel loro prodotto.

    
risposta data 03.09.2013 - 09:12
fonte
4

La risposta più ovvia di tutto, penso, è che il software è, per molte aziende, una parte sostanziale del valore che l'entità aziendale porta ai clienti. Quindi, se qualcuno potesse semplicemente modificare e ricompilare il codice, o riutilizzarne parti di valore, allora potrebbero offrire lo stesso servizio o valore. Ciò danneggerebbe gli interessi competitivi dell'entità aziendale e probabilmente li porterebbe a perdere denaro.

    
risposta data 03.09.2013 - 01:55
fonte
2

Il denaro è stato speso per risolvere un problema o una serie specifica di problemi. Se la competizione ottiene la risposta a questi problemi per "libero", ciò pone l'azienda che ha risolto il problema in uno svantaggio finanziario - soprattutto se sarebbe possibile per una società più grande "arrivare sul mercato" prima della società di creazione perché hanno infrastruttura in atto, o se un concorrente spende i soldi che hanno speso per lo sviluppo sul marketing.

Inoltre, a volte è possibile farsi un'idea delle politiche e dei processi di un'azienda osservando queste cose. Di nuovo, questa informazione può essere usata come vantaggio stratigrafico. Questo è spesso il problema più grande ... il codice rivela i meccanismi interni della società.

    
risposta data 03.09.2013 - 14:35
fonte
1

Hai ragione, la maggior parte delle aziende non ha bisogno di fare di tutto per mantenere il loro codice segreto, perché non serve a nessun altro. Molte soluzioni interne sono strettamente collegate ad altre applicazioni e sistemi come una sorta di soluzione ERP personalizzata.

Per alcune aziende, il valore del software è una parte del valore della loro azienda. Una base di codice scadente che funziona per i loro scopi ha un valore e non sarà una preoccupazione per un acquirente non tecnico. Nessuno vuole comprare un'azienda con stringhe allegate. L'acquirente vuole una risposta secca a chi possiede il codice e sono liberi di fare ciò che preferiscono? Chi lo sa, la nuova società potrebbe voler prendere un'applicazione interna e venderla ad altri nel settore e sfruttare il loro acquisto. Questo gruppo non valuterà una base di codice errata alta come un'applicazione solida. La conoscenza del codice è stata tenuta segreta (anche se potrebbe essere un'illusione) e non ci sono licenze open source per aggirare il valore aggiunto alla vendita del business.

    
risposta data 03.09.2013 - 15:28
fonte
0

Non distribuisci il codice sorgente perché quando il tuo cliente ha bisogno di modifiche a un software che hai creato, dovrà portarlo con te e potrai ricaricare il premio.

    
risposta data 03.09.2013 - 14:19
fonte

Leggi altre domande sui tag