Come gestire un progetto ad alto rischio a fonte chiusa?

25

Attualmente sto progettando di sviluppare un sito Web J2EE e desidero coinvolgere 1 sviluppatore e 1 web designer per aiutarmi. Il progetto è un'app finanziaria all'interno di un mercato di nicchia.

Ho intenzione di tenere chiusa la fonte. Tuttavia, temo che i miei aspiranti dipendenti possano facilmente copiare la base di codice e utilizzarla o venderla a terzi. Lo sviluppo dell'app richiederà 4-6 mesi, forse di più, e potrei coinvolgere altri dipendenti dopo che l'app sarà pubblicata.

Ma come posso mantenere la fonte per me. Ci sono tecniche che le aziende usano per proteggere la loro fonte?

Prevedo di disabilitare le unità USB e i masterizzatori DVD sui miei computer di sviluppo, ma sarebbe comunque possibile caricare dati o allegare il codice tramite e-mail.

La mia domanda è incompleta. Ma programmatori che sono stati nella mia situazione, per favore, consiglio. Come devo procedere? Costruire una squadra, mantenere il segreto del codice, ecc.

Non vedo l'ora di firmare un contratto di segretezza con i dipendenti, se necessario. (Aggiungi tag pertinenti)

Aggiornare

Grazie per tutte le risposte Certamente non disabiliterò tutte le porte USB e i masterizzatori di DVD ora. Ma penso che dovrei registrare l'attività (come esattamente dovrei farlo?) Sono diffidente nei confronti degli scalper che si unirebbero e poi scapperebbero con il codice esistente. Non ne ho incontrato nessuno, ma mi è stato consigliato di diffidare di loro. Includerei una clausola di segretezza, ma dato che si tratta di una startup con quasi nessun finanziamento e in una nicchia di affari altamente competitiva con attori più grandi nel settore, dubito che sarei in grado di rilevare o perseguire eventuali scalper.

Come posso assumere persone di cui mi fido, quando non le conosco personalmente. Il loro curriculum sarà utile, ma per il resto la fiducia si svilupperà solo con il tempo.

Ma alla fine anche se scappano con il codice, è il servizio che conta dopo la vendita. Quindi non sono davvero preoccupato per il lungo termine.

version-control

— abel
fonte

28

So che io (e nessun altro sviluppatore sano e competente) prenderei in considerazione l'idea di lavorare alle condizioni in cui hai accennato (pendrive disabili, scrittori di dvd ...).

— Jonathan Sterling,

5

Semplicemente velenoso.

— Jonathan Sterling,

53

Ad essere sincero, quando incontro qualcuno che rifiuta di estendere qualsiasi fiducia, penso sempre che dica di più sulla loro affidabilità rispetto alla mia - vale a dire, se pensi che non posso fidarmi, è perché sai che puoi ' fidati.

— James McLeod,

8

@abel: In sintesi alcune delle tue precedenti osservazioni, non hai alcuna esperienza nello sviluppo di software professionale. Ma stai cercando di entrare in una "nicchia di affari altamente competitiva" e avere successo contro "attori più grandi" quando non hai "quasi nessun finanziamento". Hai pesci molto più grandi da friggere che preoccuparti che i programmatori scappino con il tuo codice. Se fossi in te, scriverei un business plan e lo farei rivedere da uomini d'affari che hanno già avuto successo nella tua area target, e poi penserei se hai davvero le risorse per avere successo.

— Bob Murphy,

37

@abel: dopo l'aggiornamento, la tua domanda è così. Non hai molti soldi e non hai mai nemmeno lavorato in un ristorante, figuriamoci gestirne uno. Ma sei determinato ad aprire un ristorante comunque - ea San Francisco, che ha già molti ottimi ristoranti che lottano per ottenere un profitto. Quindi vai a una convention di chef e chiedi come assumere uno chef che non avvelenerà il cibo. E quando ti dicono che i cuochi non avvelenano il cibo, ammetti che nessuno che tu abbia mai conosciuto fosse avvelenato, ma qualcuno ti ha detto che dovresti preoccupartene, quindi ti preoccuperai comunque.

— Bob Murphy,

77

Devi fidarti dei tuoi sviluppatori.

Praticamente tutti gli sviluppatori professionisti non ruberanno la tua fonte. Resta inteso che se lavori per qualcun altro, è il datore di lavoro che possiede il codice che scrivi. Gli sviluppatori potrebbero copiare il codice a scopo di riferimento, ma è altamente improbabile che lo offrano in vendita a chiunque altro. Se l'hanno offerto in vendita a un nuovo datore di lavoro, il risultato probabile è che gli viene mostrata la porta e forse anche arrestati (come sottolinea Bob Murphy nel suo commento ). Essere scoperti non vale il rischio.

Ancora più importante, la sfiducia genera sfiducia. La disabilitazione delle porte USB e dei masterizzatori di DVD genererà una sensazione di sfiducia che, paradossalmente, renderà più probabile che gli sviluppatori copino il codice.

Sicuramente aggiungi una clausola di segretezza al tuo contratto, ma probabilmente non è necessario evidenziarlo come la parte più importante del contratto.

— ChrisF
fonte

2

Una breve clausola di segretezza è perfettamente normale nei contratti di sviluppo e nei contratti di lavoro, ma come ha detto ChrisF, non esagerare. Per chiunque abbia fatto più di una manciata di progetti di sviluppo del contratto, un lungo accordo di segretezza con minacce terribili dice solo che sei un dilettante senza sensi. Ci sono clausole standard che puoi trovare online che vanno da 6 a 20 righe di testo. Questo è abbastanza se sei disposto ad avvocato in caso di violazione - e se non lo sei, qualsiasi accordo di segretezza è inutile.

— Bob Murphy,

46

Inoltre, nel mondo reale, le terze parti non vogliono codice rubato. Il rischio è troppo grande. All'epoca in cui Informix e Oracle si stavano dando da fare per il mercato dei database relazionali aziendali a metà degli anni '90, uno degli sviluppatori di Informix smise di unirsi a Oracle (che era abbastanza comune) e prese con sé un disco rigido pieno di sorgente Informix (che non era 't). Ha detto al suo nuovo capo alla Oracle, aspettandosi un caloroso benvenuto, ma invece ha ottenuto una squadra di sicurezza e un arresto. Quindi la sicurezza Oracle ha chiamato la sicurezza Informix e il disco rigido è tornato a Informix senza che nessuno di Oracle lo avesse esaminato.

— Bob Murphy,

1

@Bob Murphy Spero che tutti siano così sinceri anche in fondo alla catena alimentare.

— abel

1

Stavo per scrivere questa risposta esatta. La fiducia è in realtà fondamentale per il successo del progetto. Come affermato da ChrisF, la disabilitazione dei componenti dei computer degli sviluppatori peggiorerà la relazione e informerà gli sviluppatori di non fidarsi. L'unico modo per proteggere veramente il tuo codice sarebbe controllare dove dormono gli sviluppatori, dove mangiano, con chi parlano, ecc. Assicurati di avere un contratto ben scritto per fornirti le munizioni legali necessarie per punire i trasgressori.

— TheBuzzSaw

2

Due parole: Edward Snowden ( en.wikipedia.org/wiki/Edward_Snowden ). Anche le divisioni più segrete all'interno del governo federale degli Stati Uniti non hanno una buona soluzione a questo problema. Cosa ti fa (l'OP) pensare di poter fare di meglio? Costruisci la tua soluzione sulla fiducia e sul contenimento ragionevole, non su restrizioni tecnologiche superficiali!

— Rinogo,

74

Se questi programmatori possono scrivere il software in primo luogo, quindi ...

NON HANNO BISOGNO DI STALARLO.

Possono semplicemente riscriverlo in una frazione del tempo impiegato per svilupparlo in origine. Sì, è vero, gli sviluppatori non sono completi idioti ... una volta che hanno capito come fare qualcosa, spesso possono ricordare come hanno fatto.

Quindi, suppongo che dovrai fidarti di loro o scrivere tu stesso il software .

— GrandmasterB
fonte

3

È un argomento per una clausola di non concorrenza? ;)

— Tim

8

Anzi: i tuoi programmatori hanno già copiato il tuo codice, in virtù di avere quella conoscenza nelle loro teste.

— Frank Shearar,

Lo capisco. Non voglio il codice di scalping degli sviluppatori appena uniti.

— abel

3

@abel, il codice rubato non è utile come sembra che lo sia. Un'app può essere "clonata", anche senza il codice sorgente. algoritmi proprietari , questo è quello che vuoi tenere al sicuro. Gli sviluppatori non devono "rubare" il codice per apprenderli, basta leggerlo e poi ricrearlo. Cavolo, basta usare il programma potrebbe essere sufficiente per dedurre un algoritmo. Quindi, come altri hanno già detto, una semplice clausola di non concorrenza farà il trucco ed è tutto ciò che puoi fare. Proteggere fisicamente il codice è solo una perdita di tempo perché qualsiasi sviluppatore degno di nota può facilmente aggirarlo.

— GrandmasterB,

11

+1 per la verità ... e per avermi fatto cadere dalla sedia ridendo. Le mucche non hanno bisogno di rubare il latte. 8D

— TheBuzzSaw

22

Ho sentito dire che nessuna idea da sola vale più di $ 20 (e sono dollari canadesi!) L'idea ha valore solo se viene eseguita bene. Anche se si tratta di rubare il codice e provare a provarlo da soli, è probabile che tu abbia un'idea migliore di quali sono i prossimi passi e più contatti con i potenziali acquirenti del software.

Dovresti assolutamente assumere solo persone di cui ti fidi, ma anche se rubano il tuo codice e provano a venderlo, è improbabile che arrivino molto lontano.

— James McLeod
fonte

9

Questo è assolutamente vero. Dimentica di mantenere segreta la tua idea unica e concentrati sull'esecuzione meglio di chiunque altro. La maggior parte delle idee sono un prodotto del loro tempo e si presentano a più persone in modo indipendente. (Henri Poincaré stava lavorando anche alla relatività nei primi anni del 1900, ma Einstein lo ha battuto per la pubblicazione.) È probabile che ci siano altri otto equipaggi che trotterellano la tua idea sui VC di Sand Hill Road questo mese; sono quelli con piani aziendali credibili e team di professionisti che otterranno finanziamenti.

— Bob Murphy,

1

Correlati: sivers.org/multiply . Le cattive idee non varrebbero nemmeno 2 pence, ma le buone idee possono valere oltre $ 20.

— Pacerier,

6

La dura verità è che nessuno vuole il tuo codice. Potresti pensare di sviluppare una soluzione che tutti vogliono sapere come funziona. Ma il più delle volte no.

Cosa faresti se acquisissi il codice sorgente dei tuoi concorrenti? Non puoi distribuirlo. Non puoi copiarne alcuna parte nel tuo progetto (anche se non è stato così difficile integrare il codice di terze parti nella tua base di codice). Cosa puoi fare? Puoi studiarlo. Ma spesso è più difficile leggere il codice che scriverlo in primo luogo.

Guarda il software open source. È un'analogia più vicina a un codice sorgente rubato. Esiste una grande quantità di codice non colorato. Una grande parte ha una licenza che non soddisfa i tuoi bisogni. Altri hanno un linguaggio di programmazione incompatibile o devono essere trasferiti sulla tua piattaforma. Il codice più adatto alle tue esigenze richiederà molto tempo per essere letto.

Ci sono molti progetti open source con una mentalità chiusa. Cioè non accettano patch. Presto la tua versione del codice si discosterà così tanto che sarebbe impossibile unire le nuove versioni.

Dovresti capire che la cosa più preziosa è la tua squadra che mantiene il tuo codice, lo fa avanzare. Non il codice stesso.

— Vanuan
fonte

5

Se si tratta di una sorta di avvio, la prima cosa che devi fare è creare un prodotto. Hai bisogno di buoni sviluppatori che lavoreranno sodo e si dedicheranno al progetto.

Un modo davvero semplice per sbarazzarsi di loro, o almeno per fiaccare il loro morale e dedizione, è mostrare loro in anticipo che non ti fidi di loro. In effetti, probabilmente inizieranno a pensare a come possono ottenere il codice (anche se quasi sicuramente non lo seguiranno) e se riescono a trovare un modo penseranno che non solo sei paranoico ma stupido. (Esistono organizzazioni in cui questo livello di cautela è giustificato e l'avvio di un sito Web finanziario non sarà considerato uno di questi.)

Alcune clausole nel contratto su come il software è di tua proprietà andranno bene. Se qualcuno lo violerà, violerà qualsiasi linguaggio più severo che tu abbia, e probabilmente si sentiranno più giustificati. Le clausole di non concorrenza che non sono limitate e limitate nel tempo inseguiranno solo le persone che desideri e in realtà potrebbero non essere legali nella tua giurisdizione (consulta un avvocato locale per scoprirlo).

Se assumi brave persone, possono riscrivere il software in un secondo momento. Se assumi principianti, non sapranno come sviluppare ulteriormente ciò con cui escono, e chiunque si basi su di esso correrà seri rischi legali per arrivare in ritardo con una versione inferiore di ciò che hai.

In breve, questo dovrebbe essere molto basso sulle cose di cui ti preoccupi. Se assumi persone cattive, sei affondato, non importa quale. Concentrati sull'assunzione di brave persone e lascia che questa diapositiva.

— David Thornley
fonte

4

Perché i tuoi potenziali clienti dovrebbero fidarsi di te con le loro finanze?

Dopo tutto puoi scappare con i soldi.

Aziende come Microsoft, Google e IBM danno lavoro a migliaia di persone per scrivere risme di software a codice chiuso e non sono eccessivamente preoccupate per il personale che se ne va con il codice. La protezione del copyright e una chiara clausola "qualsiasi codice appartiene al tuo datore di lavoro" nel contratto di lavoro sembra coprirla e, i casi giudiziari contro ex dipendenti per aver rubato il codice sono estremamente rari.

Inoltre, una volta rilasciato il software in tutto il mondo, a meno che il core non coinvolga alcuni matematici davvero avanzati, qualsiasi team competente di programmatori potrebbe riprodurre la tua applicazione senza mai vedere il codice sorgente.

— James Anderson
fonte

3

Come altri hanno già detto, questo sembra essere principalmente una preoccupazione della gente.

Tuttavia, ci sono alcuni dei principali vendor di sicurezza che commercializzano soluzioni software per la perdita di dati:

Non posso commentare la loro efficacia o adeguatezza poiché ho un'esperienza limitata con queste soluzioni, ma ho solo pensato che potrebbe essere utile segnalarlo.

— Scogliera
fonte

3

Come l'idea, l'unica preoccupazione è che questi prodotti sono pieni di linguaggio aziendale e non spiegano cosa stanno realmente facendo :)

— Mars Robertson,

2

Onestamente, come hanno detto tutti gli altri, devi solo fidarti dei tuoi programmatori.

Tuttavia, aggiungerò a ciò dicendo che dovresti davvero considerare che l'approvvigionamento aperto del tuo progetto nell'ambiente di oggi ha maggiori probabilità di aiutarti che di farti del male, ad eccezione di alcuni mercati specifici. Il solo fatto di essere più aperti all'idea ti renderà meno preoccupato che il tuo codice sorgente cresca le gambe e scappi, anche se non lo fai da solo. Raccogli tutta la buona volontà che puoi, e secondo me è più probabile che tu guadagni denaro. Anche se l'Impero offrisse la migliore app al mondo, non credo che Luke Skywalker l'avrebbe scaricata, perché gli ideali dell'Impero erano nel posto sbagliato.

— coder543
fonte