Domanda

    

Questa domanda ha già una risposta qui:

         

Oltre ad approvvigionare apertamente il tuo progetto e la tua legislazione, ci sono modi per prevenire o almeno minimizzare i danni causati da perdite di codice al di fuori della tua azienda / gruppo?

Ovviamente non possiamo bloccare l'accesso a Internet (per evitare di inviare il codice via email) perché i programmatori hanno bisogno dei loro riferimenti. Inoltre, non possiamo bloccare i dispositivi periferici (USB, Firewire, ecc.)

Il codice conta di più quando ha alcuni algoritmi proprietari e conoscenza sviluppata internamente (al contrario del normale codice di routine per disegnare GUI, connettersi a database, ecc.), ma alcune applicazioni (come software di contabilità e CRM) sono solo quello: raccolte complesse di codice di routine che sono semplici da sviluppare in linea di principio, ma che impiegheranno anni per scrivere da zero. È qui che il codice trapelato tornerà utile ai concorrenti.

A mio avviso, la prevenzione delle perdite si basa quasi interamente sul processo umano. Cosa pensi? Quali precauzioni e misure stai prendendo? E la perdita di codice ti ha colpito prima?

È stato utile?

Soluzione

Non puoi impedirgli di uscire. Quindi due soluzioni: fermare le persone che vogliono farti del male e avere precauzioni legali. Per impedire alle persone di odiare le trattate nel modo giusto (dire che probabilmente è più fuori tema per lo stack overflow).

Non sono un avvocato, ma per darti protezione legale, se ci credi, brevetti le idee, metti un avviso sul copyright nel codice e assicurati che i contratti per i tuoi programmatori specificino attentamente i diritti di proprietà intellettuale.

Ma alla fine della giornata, la risposta è più veloce della concorrenza.

Altri suggerimenti

A meno che tu non stia lavorando con qualcosa di altamente classificato e dato che non puoi bloccare la posta elettronica e i dispositivi USB, suppongo che non lo sia, non c'è davvero molto danno da avere anche se il codice sorgente perde. Il fatto è, qual è il codice o parti di esso senza la conoscenza di come funziona e l'organizzazione che lo circonda.

In generale, il valore di " source " è molto inferiore a quanto viene comunemente propagandato, in sostanza la fonte senza le persone o l'organizzazione non vale la memoria che occupa per un concorrente.

Inoltre, ti manca il vettore di attacco più probabile ed è anche quello che non puoi fermare, qualunque cosa accada. Se qualcuno vuole davvero sapere come hai fatto la tua magia, allora proveranno a ingaggiare i tuoi sviluppatori, e dal momento che non puoi impedire loro di avere informazioni all'interno del loro cranio e anche se trasformano tutte le loro proprietà in conoscenza e dominio l'esperienza sta lasciando con loro. Fondamentalmente la conservazione e la fiducia dei dipendenti è l'unico modo. Siamo spiacenti.

Non so quanto aiuto reale sarà, ma:

  1. Non spegnere i programmatori. Non metterli in una posizione in cui vogliono dare la fonte a un concorrente. La maggior parte dei luoghi sottovaluta i propri sviluppatori. Dato dove ti trovi (SO), immagino che tu abbia meno probabilità di farlo. Nulla mi ha preso di più che vedere i venditori di giochi di golf - pagati e pagati dalla compagnia - mentre dovevamo lottare per ottenere una pizza una volta al mese.

  2. Davvero, se i tuoi concorrenti diretti avessero ricevuto il tuo codice oggi , cosa farebbe? Il tuo prodotto o il tuo mercato verticale sono così stagnanti da non rilasciare versioni più recenti e migliori prima che possano reagire? Non c'è spazio per l'innovazione? La maggior parte delle aziende sopravvaluta i propri "algoritmi proprietari e le conoscenze sviluppate internamente". Certo, potrebbe ridurre il tempo libero, ma è solo il 10% circa del problema.

  3. Se avessi tutte le fonti per tutti i prodotti della concorrenza, quanto sarebbe effettivo? Immagino che ti farebbe tornare indietro di mesi. Non inoltrare Indietro.

Se avessi un sistema pulito e poche conoscenze esterne / interne, quanto tempo impiegheresti per portare il tuo prodotto in uno stato costruibile? Quanto tempo ci vorrebbe per approfondire il codice e l'allenamento di ciò che sta succedendo? Quanto tempo e denaro sprecheresti nel tentativo di elaborare qualcosa, piuttosto che spendere tempo e denaro per fare il tuo il prodotto funziona meglio?

In realtà sono stato nella posizione di avere tutta la fonte - 1 milione di righe + di codice - sul prodotto di un concorrente. Non abbiamo fatto nulla - a parte un po 'di scherzo e poi eliminarlo, il che era più di quanto mi sentissi a mio agio - ma mi aspetterei che avremmo masticato mesi di tempo solo per arrivare a dove erano poi.

Quindi l'abbiamo ammazzato, schiaffeggiato l'id10t che l'ha ottenuto (sì, uno sviluppatore / PM che è venuto dall'altra società) e abbiamo pensato a come fare il nostro prodotto a calciare così tanto culo che non importava cosa facessero. Uso del tempo molto migliore. Ha funzionato bene anche. Avevamo i differenziatori, non solo il re-hashing delle stesse caratteristiche nello stesso modo in cui le hanno fatte.

Siamo spiacenti, ma esiste un no in cui puoi impedire alle persone di ottenere roba e di poter comunque effettivamente lavorare. Puoi impedirgli di voler farlo, o farlo in modo che non ci sia valore per loro averlo.

Eravamo preoccupati anche per le persone che decompilavano il nostro codice. Abbiamo smesso di preoccuparci quando ci siamo resi conto che avevamo abbastanza problemi a capire cosa stava succedendo all'interno di 500K + righe di codice C #, C ++ e HTML che parlavano con MAPI / Exchange. Se qualcuno può decompilarlo e risolverlo, allora vogliamo assumerlo ......

A proposito, per chiarezza e dato per chi lavoro ora, dovrei sottolineare che non è non il mio attuale datore di lavoro. Questo è successo un po 'di tempo fa.

Il codice non perde su se stesso. Ci vuole gente per prenderlo. Esistono ovviamente alcune misure di sicurezza che potresti utilizzare come l'analisi del traffico e il blocco dei repository in modo che solo gli sviluppatori autorizzati possano connettersi ad esso.

Ma alla fine della giornata la migliore opzione è quella di assicurarsi che nessuno VUOLE rubare da te. La tua squadra deve essere felice, devono essere orgogliosi di lavorare per te, devono essere fedeli all'azienda e agli altri. Se hai una squadra del genere è una semplice questione di spiegare a tutti che il codice deve essere protetto dagli estranei. Non fermerà una talpa dedicata ma previene gli incidenti.

P.S. E sì, anche le clausole appropriate nei contratti non danneggerebbero, almeno si assicureranno che gli sviluppatori siano ATTENTI che prendere il codice all'esterno sia moralmente sbagliato.

Segui queste linee guida e non dovrebbe importare se i contenuti dell'intero repository del codice sorgente sono pubblicati su tutto lo stackoverflow:

http://geocities.com/mdetting/unmaintainable.html

Oh, e mostra ai tuoi sviluppatori che non ti fidi di loro bloccando l'accesso a parti del codice sorgente, scansionando e-mail in uscita / in entrata ecc. Questo è un modo infallibile per farli desiderare di stare in giro ... .. .nulla migliora il morale come un po 'di sfiducia sul posto di lavoro.

Un altro modo interessante è dire a metà che sono "squadra a" e nominare l'altra metà come la "squadra b" inaffidabile. Quindi invertilo e dì la stessa cosa al "team b". membri. Incoraggiali a tenere d'occhio i "cattivi" " nell'altra squadra e per segnalare qualsiasi segno di lealtà nei tuoi confronti. Cospargi alcuni "induttori di conflitto" (ad es. dì " Joe " ;: ' sai cosa dice Ed di te alle tue spalle? ') ecc. Funziona a meraviglia se imposti gli sviluppatori l'uno contro l'altro e ne crei alcuni [inventati- by-you] conflitti qua e là ...

(Eh, e no, in realtà non consiglio nessuna delle precedenti. Sto solo scherzando. Ma ho visto le persone usare tutte le tattiche sopra. E non ha funzionato.)

Okay, sarò un po 'pratico qui.

  • Essere gentili con tutti e sperare che non ti facciano del male non funziona.

Ogni programmatore sa dal giorno in cui si unisce a una società che non rimarrà lì per sempre. Cambierà quando avrà imparato abbastanza per avere un'opportunità migliore.

I programmatori che scrivono il codice credono di possederlo anche se l'hanno scritto nel momento in cui l'hanno affittato a qualcun altro. Quindi molti di loro cercheranno di mettere le mani sul codice sorgente anche se non hanno intenzione di ferire nessuno.

Una volta che lasciano l'azienda e hanno portato con sé il codice sorgente e hanno perso il contatto con i loro colleghi, la coscienza si sistema e va in vacanza e dopo un po 'parti del codice iniziano a comparire ovunque.

È quello che CONOSCO accade perché l'ho visto accadere alla mia azienda.

Quindi cosa si fa?

  • Firma un accordo di non divulgazione che menziona specificamente che il programmatore NON ne prenderà copie.
  • Distribuisci il tuo prodotto tra i programmatori e, se possibile, ottieni moduli codificati individualmente e integrati da un capo la cui responsabilità è che tutti i programmatori non ottengono tutto il codice.
  • Al momento della risoluzione ottenere dai programmatori l'impegno scritto di non possedere alcun IP dell'azienda e di comprendere le sanzioni per violazione.
  • Se qualcuno viola il tuo IP, fai causa all'uomo! Nessuna eccezione. Funzionerà come esempio per l'attuale squadra.

Sembro estremo?

Ricordo che stava succedendo a Valve quando stavano sviluppando HL-2. Link interessante qui: http://www.shacknews.com/onearticle.x/28619

Ho lavorato da qualche parte dove c'era una vera cultura della segretezza su questo genere di cose (storicamente ci sono state diverse volte in cui la società era piccola in cui "i clienti" avevano, diciamo, abusato del loro accesso a nostro prodotto).

Mentre in cima la gestione era molto protettiva, la vedo in modo leggermente diverso. Penso che il nostro codice, sebbene non del tutto irrilevante, non sia la chiave come ci si aspetterebbe da una società di software.

Il motivo per cui abbiamo successo è:

1) Il codice è essenzialmente la soluzione a una serie di problemi. Se ottieni il nostro codice ottieni quelle soluzioni ma abbiamo ancora le persone intelligenti che hanno risolto quei problemi. Comprendono questi problemi meglio di te e sono in grado di risolvere meglio il prossimo insieme di problemi.

2) Perché comprendono davvero i problemi (e le soluzioni), possiamo fare le cose più velocemente dei nostri concorrenti, il che si traduce in più economico (o più redditizio).

3) Anche a causa di quelle persone e dell'atteggiamento all'interno dell'azienda abbiamo consegnato bene ai nostri clienti e fornito un buon supporto.

4) E per questo motivo abbiamo una buona reputazione e clienti di riferimento.

Un piccolo numero di aziende ha un codice che vale davvero la pena mantenere segreto - algoritmi proprietari e quel genere di cose - ma per la stragrande maggioranza di noi i nostri prodotti sono replicabili molto facilmente da persone intelligenti.

Quello che sto dicendo è fare le basi - scriverlo nei contratti delle persone che non possono accettarlo, tenerlo al sicuro e così via - ma non ossessionarlo. A meno che non ti trovi in ??un mercato molto specifico, è improbabile che sia ciò che realmente farà sì che la tua azienda abbia successo o meno.

Il passo migliore inizia dalla reindirizzamento di ragazzi con un forte comportamento etico. È possibile eseguire vari altri passaggi come la scansione di tutte le comunicazioni. Ci sono luoghi in cui vengono scansionate le e-mail e tutte le informazioni in uscita. Il desktop / laptop non ha hard disk o l'accesso è limitato e tutto il lavoro è su cartelle di rete, anche quando si lavora da casa, è necessario connettersi a Internet. Il lavoro offline viene sincronizzato. L'USB e le unità sono disconnesse.

Le altre politiche sono di fornire l'accesso solo in base alle necessità. Questi rallenteranno e ostacoleranno solo in una certa misura, ma uno è molto determinato quindi troverà il modo di aggirare questo. L'altro modo è se il codice è davvero molto importante, quindi l'idea di copywrite è protetta in modo legale.

Ad essere onesti è quasi impossibile. Se volessi suggerire cosa farebbe una società che apparirà a breve sul Daily WTF:

  1. Disconnetti il ??"computer di lavoro" da Internet, a causa del fatto che hanno bisogno di un accesso a Internet come riferimento, acquista tutti un wbbook.

  2. Riempi gli slot USB degli sviluppatori con resina epossidica e richiedono che carichi / scarichino qualsiasi cosa da un server centralizzato, che scansiona tutti i dati che lo attraversano alla ricerca di codice come sintassi.

O potresti semplicemente fidarti dei tuoi dipendenti e far loro firmare un accordo di non divulgazione ...

Personalmente non ho mai testato nessun caso reale, ma suggerirei di usare la frammentazione del codice:

sostanzialmente dividi il tuo progetto in una serie di librerie, definisci interfacce e unit test per ognuna di esse, quindi separi i repository SVN in modo che ciascun gruppo abbia accesso a una parte limitata del tuo prezioso codice sorgente.

Anche questa è una buona pratica, indipendentemente da cosa e dovrebbe aiutare se si sta esternalizzando all'estero.

Le risposte precedenti sembrano tutte incentrate sulla costruzione della fiducia e sull'impiego di persone etiche.

Un'altra possibilità potrebbe essere quella di creare un linguaggio e strumenti specifici per il tuo dominio. Ciò renderà più difficile l'utilizzo di qualsiasi codice trapelato. Potrebbe essere ancora possibile rubare idee utili da esso, ma non sarebbe possibile semplicemente compilare un prodotto concorrente a meno che l'intera toolchain non sia trapelata.

Fidati dei tuoi sviluppatori. Le persone tendono a vivere all'altezza o alle aspettative. Trattali bene e ricorda che la lealtà va in entrambe le direzioni. Dopotutto, se non riesci a tagliare le chiavette USB, non puoi impedire a nessuno di perdere codice, non importa quanto non ti fidi di loro.

Detto questo, trovati un avvocato con esperienza di segreto commerciale, probabilmente esperienza in altre parti della legge sulla PI e chiedi come tutelare legalmente le cose. Vuoi assicurarti che, se un concorrente ottiene le tue cose, non è legale per il concorrente trarne vantaggio.

La maggior parte delle risposte si basa su valori morali ed etici. Mi chiedo se Google, Facebook ecc. Facciano affidamento sulla buona volontà dei loro dipendenti. Dammi una pausa, è totalmente utopico. Non essere sciocco. Sii realistico.

SÌ, è possibile evitare perdite di codice:

Utilizzando un server virtuale che ospita macchine virtuali, i programmatori possono accedere solo localmente a queste macchine virtuali (intranet) tramite Desktop remoto. Il repository è gestito localmente. le chiavi private sono necessarie per accedere al repository. Copia / incolla dalla macchina virtuale al client è disabilitato. è consentito solo copiare / incollare dal client al virtuale.

Le aziende come Facebook lo fanno.

L'unico modo per fermare il codice è scattare foto al codice reale, il che non è assolutamente pratico e fattibile, e poiché ci sono telecamere di sorveglianza ovunque, dovrai andare in bagno per scattare quelle foto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top