Comment gérer un projet à haut risque en source fermée?

25

Je prévois actuellement de développer un site web J2EE et souhaite faire appel à 1 développeur et 1 web designer pour m'aider. Le projet est une application financière dans un marché de niche.

J'ai l'intention de garder la source fermée. Cependant, je crains que mes employés potentiels puissent facilement copier la base de code et l'utiliser ou la vendre à un tiers. Le développement de l'application prendra 4 à 6 mois, peut-être plus, et je pourrai faire venir des employés supplémentaires après la mise en service de l'application.

Mais comment garder la source pour moi. Existe-t-il des techniques que les entreprises utilisent pour protéger leur source?

Je prévois de désactiver les lecteurs USB et les graveurs de DVD sur mes machines de développement, mais télécharger des données ou joindre le code par e-mail serait toujours possible.

Ma question est incomplète. Mais les programmeurs qui ont été dans ma situation, veuillez me conseiller. Comment dois-je procéder? Construire une équipe, maintenir le secret du code, etc.

J'ai hâte de signer un contrat de confidentialité avec les employés si nécessaire aussi. (Veuillez ajouter des balises pertinentes)

Mise à jour

Merci pour toutes les réponses. Je ne désactiverai certainement pas tous les ports USB et les graveurs de DVD maintenant. Mais je pense que je devrais enregistrer l'activité (comment dois-je faire exactement cela?) Je me méfie des scalpeurs qui se joindraient puis s'enfuiraient avec le code existant. Je n'en ai rencontré aucun, mais on m'a conseillé de m'en méfier. J'inclurais une clause de confidentialité, mais étant donné qu'il s'agit d'une start-up avec presque aucun financement et dans un créneau commercial très compétitif avec de plus grands acteurs dans le domaine, je doute que je serais en mesure de détecter ou de poursuivre des scalpers.

Comment embaucher des personnes en qui j'ai confiance, quand je ne les connais pas personnellement. Leur CV sera utile mais sinon la confiance ne se développera qu'avec le temps.

Mais finalement, même s'ils s'enfuient avec le code, c'est le service qui compte après la vente. Je ne suis donc pas vraiment inquiet à long terme.

version-control

— Abel
source

28

Je sais que je (et aucun autre développeur sensé et compétent) envisagerais de travailler dans les conditions auxquelles vous avez fait allusion (clés USB désactivées, graveurs de DVD…).

— Jonathan Sterling,

5

Tout simplement toxique.

— Jonathan Sterling

53

Pour être honnête, lorsque je rencontre quelqu'un qui refuse de faire confiance, je pense toujours que cela en dit plus sur sa propre fiabilité que la mienne - c'est-à-dire que si vous pensez qu'on ne peut pas me faire confiance, c'est parce que vous savez que vous pouvez '' t faire confiance.

— James McLeod

8

@abel: En résumant certaines de vos remarques précédentes, vous n'avez aucune expérience dans le développement de logiciels professionnels. Mais vous essayez d'entrer dans un "créneau commercial hautement compétitif" et de réussir contre des "acteurs plus importants" lorsque vous n'avez "pratiquement pas de financement". Vous avez beaucoup plus de poisson à faire frire que de vous inquiéter des programmeurs qui fuient avec votre code. Si j'étais vous, je rédigerais un plan d'affaires et le ferais réviser par des hommes d'affaires qui ont déjà réussi dans votre domaine cible, puis je me demanderais si vous avez vraiment les ressources pour réussir.

— Bob Murphy

37

@abel: Après votre mise à jour, votre question est la suivante. Vous n'avez pas beaucoup d'argent et vous n'avez même jamais travaillé dans un restaurant, et encore moins en gérer un. Mais vous êtes déterminé à ouvrir un restaurant de toute façon - et à San Francisco, qui a déjà beaucoup de bons restaurants qui ont du mal à faire du profit. Vous allez donc à une convention de chefs et demandez comment embaucher un chef qui n'empoisonnera pas la nourriture. Et quand ils vous disent que les chefs n'empoisonnent pas la nourriture, vous admettez que personne que vous n'avez jamais connu n'a été empoisonné, mais quelqu'un vous a dit que vous devriez vous en soucier pour que vous vous inquiétiez quand même.

— Bob Murphy

77

Vous devez faire confiance à vos développeurs.

Pratiquement tous les développeurs professionnels ne voleront pas votre source. Il est entendu que si vous travaillez pour quelqu'un d'autre, c'est l'employeur qui possède le code que vous écrivez. Les développeurs peuvent copier du code à des fins de référence, mais il est très peu probable qu'ils le proposent à la vente à quelqu'un d'autre. S'ils l'ont proposé à la vente à un nouvel employeur, le résultat probable est qu'on leur montre la porte et peut-être même qu'ils soient arrêtés (comme le souligne Bob Murphy dans son commentaire ). Se faire prendre ne vaut pas le risque.

Plus important encore, la méfiance engendre la méfiance. La désactivation des ports USB et des graveurs de DVD engendrera un sentiment de méfiance qui, paradoxalement, augmentera la probabilité que les développeurs copient le code.

Ajoutez certainement une clause de confidentialité à votre contrat, mais il est probablement inutile de la mettre en évidence comme la partie la plus importante du contrat.

— ChrisF
source

2

Une brève clause de confidentialité est parfaitement normale dans les contrats de développement et les accords de travail - mais comme l'a dit ChrisF, ne vous en faites pas trop. Pour tous ceux qui ont fait plus qu'une poignée de projets de développement de contrats, un long accord secret avec des menaces terribles dit simplement que vous êtes un amateur sans aucune idée. Il existe des clauses standard que vous pouvez trouver en ligne et qui vont de 6 à 20 lignes de texte. C'est beaucoup si vous êtes prêt à faire appel à un avocat en cas de violation - et si vous ne le faites pas, tout accord de confidentialité est inutile.

— Bob Murphy

46

De plus, dans le monde réel, les tiers ne veulent pas de code volé. Le risque est trop grand. À l'époque où Informix et Oracle se disputaient le marché des bases de données relationnelles d'entreprise au milieu des années 90, l'un des développeurs d'Informix a quitté pour rejoindre Oracle (ce qui était assez courant) et a pris un disque dur plein de sources Informix avec lui (ce qui n'était pas 't). Il a dit à son nouveau patron chez Oracle, s'attendant à un accueil chaleureux, mais à la place, il a obtenu une équipe de sécurité et une arrestation. Ensuite, la sécurité Oracle a appelé la sécurité Informix, et le disque dur est retourné à Informix sans que personne d'Oracle ne l'ait examiné.

— Bob Murphy

1

@Bob Murphy J'espère que tout le monde est si sincère même au bas de la chaîne alimentaire.

— abel

1

J'étais sur le point de taper cette réponse exacte. La confiance est en effet essentielle à la réussite du projet. Comme l'a déclaré ChrisF, la désactivation des composants des ordinateurs des développeurs ne fera qu'aggraver la relation et informera ces développeurs qu'ils ne sont pas fiables. La seule façon de vraiment protéger votre code serait de contrôler où les développeurs dorment, où ils mangent, à qui ils parlent, etc. Assurez-vous simplement d'avoir un contrat bien écrit pour vous donner les munitions légales dont vous avez besoin pour punir les contrevenants.

— TheBuzzSaw

2

Deux mots: Edward Snowden ( en.wikipedia.org/wiki/Edward_Snowden ). Même les divisions les plus secrètes du gouvernement fédéral américain n'ont pas de bonne solution à ce problème. Qu'est-ce qui vous fait (l'OP) penser que vous pouvez faire mieux? Construisez votre solution sur la confiance et un confinement raisonnable, pas sur des restrictions technologiques superficielles!

— rinogo

74

Si ces programmeurs peuvent écrire le logiciel en premier lieu, alors ...

ILS N'ONT PAS BESOIN DE LE VOLER.

Ils peuvent simplement le réécrire en une fraction du temps qu'il a fallu pour le développer à l'origine. Oui, c'est vrai, les développeurs ne sont pas des idiots complets ... une fois qu'ils ont compris comment faire quelque chose, ils peuvent souvent se rappeler comment ils l'ont fait.

Donc, je suppose que vous devrez simplement leur faire confiance ou écrire le logiciel vous-même .

— GrandmasterB
source

3

Est-ce un argument en faveur d'une clause de non-concurrence? ;)

— Tim

8

En effet: vos programmeurs ont déjà copié votre code, du fait d'avoir cette connaissance en tête.

— Frank Shearar

Je comprends que. Je ne veux pas que les développeurs nouvellement joints scalpent le code.

— abel

3

@abel, le code volé n'est pas aussi utile que vous le pensez. Une application peut être «clonée», même sans le code source. des algorithmes propriétaires , c'est maintenant ce que vous voulez garder en sécurité. Les développeurs n'ont pas besoin de «voler» du code pour les apprendre, il suffit de le lire puis de le recréer. Heck, juste utiliser le programme pourrait être suffisant pour déduire un algorithme. Ainsi, comme d'autres l'ont dit, une simple clause de non-concurrence fera l'affaire et est à peu près tout ce que vous pouvez faire. Sécuriser physiquement le code n'est qu'une perte de temps car tout développeur digne de ce nom peut facilement contourner cela.

— GrandmasterB

11

+1 pour la vérité ... et pour m'avoir fait tomber de ma chaise en riant. Les vaches n'ont pas besoin de voler du lait. 8D

— TheBuzzSaw

22

J'ai entendu dire qu'aucune idée à elle seule ne valait plus de 20 $ (et c'est en dollars canadiens!) L'idée n'a de valeur que si elle est bien exécutée. Même s'il s'agit de voler le code et d'essayer de le faire eux-mêmes, il y a de fortes chances que vous ayez une meilleure idée des prochaines étapes et plus de contacts avec les acheteurs potentiels du logiciel.

Vous ne devez certainement engager que des personnes en qui vous avez confiance, mais même si elles volent votre code et tentent de le vendre, il est peu probable qu'elles arrivent très loin.

— James McLeod
source

9

C’est absolument vrai. Oubliez de garder votre idée unique super secrète et concentrez-vous sur son exécution mieux que quiconque. La plupart des idées sont le produit de leur temps et se produisent pour plusieurs personnes indépendamment. (Henri Poincaré travaillait également sur la relativité au début des années 1900, mais Einstein l'a battu à la publication.) Il y a de fortes chances qu'il y ait huit autres équipes qui trottent votre idée vers les VCs sur Sand Hill Road ce mois-ci; ce sont ceux qui ont des plans d'affaires crédibles et des équipes professionnelles qui obtiendront du financement.

— Bob Murphy

1

Connexes: sivers.org/multiply . Les mauvaises idées ne valent même pas 2 pence, mais les bonnes idées peuvent bien valoir plus de 20 $.

— Pacerier

6

La dure vérité est que personne ne veut de votre code. Vous pouvez penser que vous développez une solution que tout le monde veut savoir comment cela fonctionne. Mais le plus souvent, vous ne le faites pas.

Que feriez-vous si vous repreniez le code source de vos concurrents? Vous ne pouvez pas le distribuer. Vous ne pouvez pas en copier des parties dans votre projet (même si ce n'était pas si difficile d'intégrer du code tiers dans votre base de code). Ce que tu peux faire? Vous pouvez l'étudier. Mais il est souvent plus difficile de lire le code que de l'écrire en premier lieu.

Regardez le logiciel open source. C'est une analogie la plus proche avec un code source volé. Il existe une grande quantité de code non entretenu. Une grande partie possède une licence qui ne correspond pas à vos besoins. D'autres ont un langage de programmation incompatible ou doivent être portés sur votre plate-forme. Le code qui répond à vos besoins prendra beaucoup de temps à lire.

Il existe de nombreux projets open source avec une mentalité de source fermée. C'est-à-dire qu'ils n'acceptent pas les correctifs. Bientôt, votre version de code va tellement dévier qu'il serait impossible de fusionner de nouvelles versions.

Vous devez comprendre que ce qui est le plus précieux, c'est votre équipe qui maintient votre code, le fait avancer. Pas le code lui-même.

— Vanuan
source

5

S'il s'agit d'une sorte de démarrage, la première chose que vous devez faire est de construire un produit. Vous avez besoin de bons développeurs qui travailleront dur et se consacreront au projet.

Un moyen très simple de s'en débarrasser, ou du moins de saper leur moral et leur dévouement, est de leur montrer d'emblée que vous ne leur faites pas confiance. En fait, ils sont susceptibles de commencer à réfléchir à des moyens de faire sortir le code (bien qu'ils ne le feront presque certainement pas), et s'ils peuvent trouver un moyen, ils vous penseront non seulement paranoïaque mais stupide. (Il existe des organisations où ce niveau de prudence est justifié, et une startup de site Web financier ne sera pas considérée comme l'une d'entre elles.)

Quelques clauses dans le contrat sur la façon dont le logiciel est votre propriété conviendront. Si quelqu'un viole cela, il violera tout langage plus sévère que vous avez et se sentira probablement plus justifié. Les clauses de non-concurrence qui ne sont pas étroites et limitées dans le temps ne feront que chasser les personnes que vous souhaitez, et peuvent en fait ne pas être légales dans votre juridiction (consultez un avocat local pour le savoir).

Si vous embauchez de bonnes personnes, elles peuvent réécrire le logiciel plus tard. Si vous embauchez des débutants, ils ne sauront pas développer davantage ce avec quoi ils partent, et quiconque s'appuyant dessus courra de graves risques juridiques pour arriver tard avec une version inférieure de ce que vous avez.

En bref, cela devrait être très bas sur les choses qui vous inquiètent. Si vous embauchez de mauvaises personnes, vous êtes coulé quoi qu'il arrive. Concentrez-vous sur l'embauche de bonnes personnes et laissez cette diapositive.

— David Thornley
source

4

Pourquoi vos clients potentiels devraient-ils vous faire confiance avec leurs finances?

Après tout, vous pouvez vous enfuir avec l'argent.

Des entreprises comme Microsoft, Google, IBM emploient des milliers de personnes pour écrire des rames de logiciels à code source fermé et ne sont pas trop inquiètes de voir leur personnel partir avec le code. La protection du droit d'auteur et une clause claire «tout code appartient à votre employeur» dans le contrat de travail semble le couvrir, et les poursuites judiciaires contre d'anciens employés pour vol de code sont extrêmement rares.

De plus, une fois que vous avez publié votre logiciel dans le monde entier, à moins que le cœur n'implique des mathématiques vraiment avancées, toute équipe de programmeurs compétente pourrait reproduire votre application sans jamais voir le code source.

— James Anderson
source

3

Comme d'autres l'ont mentionné, cela semble être principalement une préoccupation des gens.

Cependant, il existe un certain nombre de fournisseurs de sécurité majeurs qui commercialisent des solutions logicielles contre les fuites de données:

Je ne peux pas commenter leur efficacité ou leur pertinence car j'ai une expérience limitée de ces solutions, mais je pensais simplement qu'il pourrait être utile de le souligner.

— Falaise
source

3

Comme l'idée, le seul souci est que ces produits sont pleins de langage corporatif et n'expliquent pas ce qu'ils font réellement :)

— Mars Robertson

2

Honnêtement, comme tout le monde l'a dit, il vous suffit de faire confiance à vos programmeurs.

Cependant, j'ajouterai à cela en disant que vous devriez vraiment considérer que l'open source votre projet dans l'environnement actuel est plus susceptible de vous aider que de vous blesser, à l'exception de quelques marchés spécifiques. Le fait d'être plus ouvert à l'idée vous rendra moins inquiet de voir votre code source se développer et s'échapper, même si vous ne le faites pas vous-même. Gagner toute la bonne volonté que vous pouvez, et vous êtes plus susceptible de gagner de l'argent, à mon avis. Même si l'Empire offrait la meilleure application du monde, je ne pense pas que Luke Skywalker l'aurait téléchargée, car les idéaux de l'Empire étaient au mauvais endroit.

— coder543
source