Quelles sont les méthodes pour estimer la valeur du code source?

Je travaille sur un projet sur mon temps libre depuis quelques mois. Récemment, j'ai été approché par des amis pour créer une startup, et ce code source nous serait très précieux.

En tant que co-fondateur, ce code pourrait compter pour quelque chose dans le capital de l'entreprise et être échangé contre des actions. Mais comment pouvez-vous estimer sa valeur? Vous multipliez simplement les salaires standard de l'industrie par le temps que j'y ai consacré, ou existe-t-il d'autres méthodes?

Le système COCOMO contient un modèle pour estimer le temps d'écriture d'un logiciel. Comme le temps c'est de l'argent, vous obtenez également la valeur du logiciel du point de vue de "combien cela coûterait-il à quelqu'un de l'écrire". La formulation actuelle de ce modèle est le COCOMO II qui a un outil web plutôt sympa .

Avec cet outil Web, on peut partir d'une estimation de la taille (vous n'avez pas d'estimation, vous avez des chiffres réels de la taille du code ...) et obtenir les coûts de planification, de test et de développement estimés.

En supposant 20k sloc (lignes de code source) et une valeur de 10k $ / mois pour le développeur (et toutes les autres choses étant nominales), vous obtenez un temps estimé de 79,3 personnes-mois pour le faire (rappelez-vous, c'est la planification, la construction et les tests) pour une valeur de 793k $.

Cette valeur doit être considérée comme le minimum de la valeur du code. La valeur réelle serait plus élevée car elle génère des revenus et est la propriété intellectuelle de base de l'entreprise potentielle.

Ne confondez pas votre temps passé avec ce qu'il vaut. Vous avez également eu l'idée, conçu et risqué votre temps pour le construire. C'est bien au-delà du coût d'un programmeur engagé.

À partir de maintenant, vous devriez détenir 100% du démarrage. C'est au reste des partenaires potentiels de montrer ce qu'ils valent. Je subordonnerais ces actions à la production de quelque chose également (ventes, marketing, contacts avec l'industrie, codage supplémentaire, etc.).

Valeur initiale, valeur finale, équité de vente

Vous pouvez vous épargner du temps et du chagrin sur cette négociation si vous considérez le code par rapport à ce qui sera nécessaire pour votre MVP (produit viable minimum). Si le code est la moitié du MVP, par souci d'équité, vous avez besoin de quelque chose pour cela. Si le code représente 10%, 5% ou même 1% de l'effort, il importera beaucoup moins.

Si vous exigez de l'argent ou une plus grande équité (hmm, cela ressemble à un oxymore), assurez-vous que vous pouvez faire un bon travail en le vendant du point de vue de l'équité d'une manière qui peut supporter à travers ce qui peut être de nombreux défis sur le chemin de la vente du produit.

Considérez également les choses symétriquement. Vos partenaires vont-ils également écrire du code et peuvent-ils ou vont-ils rattraper ou dépasser votre contribution? Combien paierez-vous à vos partenaires pour leur intérêt dans le code résultant si l'entreprise se termine? Le ton et les attentes que vous définissez maintenant donneront en grande partie le ton et les attentes plus tard.

Économie du génie logiciel

Je considère le Dr Barry Boehm comme le père de l'économie du génie logiciel. Parmi ses réalisations, il a inventé COCOMO, proposé la méthode de gestion de projets Theory-W et créé un modèle de modèles de développement logiciel appelé MBASE . Ses modèles discutent des modèles de produit qui décrivent ce qui est ou a été construit (comme les diagrammes UML), des modèles de processus (comme Scrum, cascade, etc.), des modèles de propriété qui décrivent les attributs du produit ou de l'organisation (coût, calendrier, fiabilité) et des modèles de réussite .

Modèle de réussite et stratégie de sortie potentielle

Vous devriez certainement vous demander si votre succès est basé sur quelque chose de formel comme Theory-W ou quelque chose d'informel comme IKIWISI (je le saurai quand je le verrai). Le modèle de réussite peut également vous aider à définir les attentes concernant le temps et les efforts nécessaires à votre démarrage, les critères que vous utilisez pour aller / ne pas aller, le besoin de pivoter, la vente ou la fermeture de l'entreprise, et la répartition des actifs en cas d'événement de réussite ou d'échec. Mon grand-père a été présenté il y a quelques années avec des titres qui portaient le nom de "Silver Screen Limited Partnership 7" et qui finançaient essentiellement un film hollywoodien qui a commencé avant le film, puis a pris fin après que le film a été diffusé dans les salles (c'était un pré-DVD journées). Si j'étais vous, je m'assurerais que ma start-up ne soit pas un engagement à vie avant de commencer.

Un prototype n'est pas un produit

L'un des premiers articles de Boehm que j'ai lu comprenait un diagramme comparant graphiquement un prototype à un produit. Il a utilisé un carré pour le prototype et une grille de carrés de trois haut et trois de large pour le produit. Selon votre sentiment de confiance par rapport au réalisme, vous pouvez soit rejeter cette notion, soit commencer à vous souvenir de projets antérieurs où les dimensions du produit étaient 25, 81 ou 100 fois le coût et l'effort des prototypes.

Valoriser votre contribution unique

Pour valoriser votre code dans le contexte du démarrage, vous devez probablement également valoriser votre rôle et son caractère unique au démarrage. Si vous êtes le développeur et que vos partenaires sont les bailleurs de fonds ou les vendeurs, vous êtes un peu comme le porc proverbial et ce sont les poulets qui se lancent dans un restaurant qui sert le petit-déjeuner. Ils risquent peu jusqu'à ce qu'ils écrivent un chèque et peuvent peut-être travailler relativement peu jusqu'à ce qu'il y ait quelque chose à vendre. Si vous êtes tous les développeurs, potentiellement s'ils n'ont pas de code à mettre dans le pot au début, cela pourrait s'avérer être une entreprise très déséquilibrée. Dans la mesure où le film " The Social Network " dépeint les choses correctement, il y a une start-up extrêmement réussie qui avait des partenaires qui faisaient très peu et qui faisaient très peu d'efforts pendant la fabrication du produit.

Démarrage avec Start Ups

Faites très attention à la façon dont vous vous liez à vos partenaires pour démarrer. Élaborez un accord d'exploitation qui couvre autant que possible ce qui pourrait arriver pendant la durée de vie de la start-up. Envisagez de définir la portée de manière très étroite et de suivre un modèle de démarrage simplifié. Trouvez des moyens sûrs d'essayer des projets d'équipe. L'école est un excellent moyen. Certaines universités et autres sponsors ont créé des choses comme l' école Rapid Start Up . Une méthode très répandue pour avoir un avant-goût de ce à quoi pourrait ressembler une start-up est de participer à un Start Up Weekend . Il existe des incubateurs communautaires et commerciaux et des espaces de coworking. Mon expérience limitée s'est produite dans des endroits comme Gangplank (j'ai apprécié leur programme très bon marché pour Start Up Weekend) et Cohoots.

Utiliser la protection

Vous devez toujours vous protéger légalement, financièrement et physiquement. La responsabilité pénale et civile peut survenir lors d'un démarrage. Si l'entreprise emprunte de l'argent ou embauche quelqu'un qui se coupe le doigt, vous pourriez être coincé avec des factures difficiles à payer. Vous devez utiliser des procédures comptables saines et avoir besoin d'une assurance, et vous devez vous protéger ainsi que vos partenaires de se retrouver sur une pente glissante.

Quelques histoires de mise en garde

Bien que ce ne soit pas une start-up, je connaissais une organisation qui permettait à une personne sans emploi et soumise à des contraintes financières d'être son trésorier. Il a mélangé les fonds de la vente des billets pour un banquet pour environ cinq cents personnes avec son propre compte bancaire. Il ne pensait peut-être pas qu'il volait, mais il a certainement fait preuve d'un mauvais jugement. Quand il était clair que l'argent avait disparu, il y avait de vilains problèmes avec la personne poursuivie pour détournement de fonds. L'organisation avait une assurance qui permettait la tenue du banquet, mais si ce n'était pas le cas, ces 500 acheteurs de billets se seraient retrouvés avec le sac.

Un autre cas que je connais a eu une société à responsabilité limitée débutée avec désinvolture se transformer en gros tracas. Il y a eu un jugement contre l'un des partenaires et quand il a été difficile de le récupérer, les avocats ont envoyé un serveur de processus au domicile du partenaire qui avait oublié qu'ils avaient signé pour l'entreprise. Il y avait des réclamations contre le partenaire et des réponses juridiques étaient nécessaires. Après des visites au tribunal et des conseils juridiques, le partenaire s'en est occupé, mais ces maux de tête ne disparaissent souvent que lorsque de l'argent réel sort de la poche de quelqu'un.

Travailler avec diligence et faire preuve de diligence raisonnable

La constitution d'équipes et la recherche de partenaires appropriés sont extrêmement importantes. Larry Page parle de passer beaucoup de temps à chercher des partenaires pour fonder Google.

Évaluez-le de la même manière qu'un produit "réel":

Quel est le coût de remplacement?:
S'il n'y a pas de produit comparable - quel serait le coût d'embaucher quelqu'un pour le refaire à partir de zéro? Quel serait le coût de contourner certains PI / brevets contenus dans ce document?
S'il existe un produit comparable - en quoi votre produit est-il meilleur, en quoi est-il pire - quelle est la valeur de cette différence?

Le coût "irrécupérable" - le temps que vous avez déjà passé et que vous ne pouvez pas "dépenser" ne devrait pas être pertinent pour votre décision.
Même les "coûts" futurs ne sont pas très pertinents pour le prix / la valeur - les choses peuvent valoir plus que ce qu'elles coûtent à construire (par exemple, Mona Lisa vaut plus que la main-d'œuvre + la peinture + le cadre + la toile + 30% de marge)

Ohloh a un article wiki sur la façon dont ils calculent le coût des projets qu'ils suivent. Il renvoie à un article Wikipédia qui semble suffisamment détaillé.

Ohloh wiki

J'espère que ca aide.

Si ce sont des amis, pourquoi ne pas partager équitablement la valeur de l'entreprise? Statistiquement parlant, votre démarrage échouera donc cela n'aura pas d'importance. Et si vous réussissez très bien, vous aurez toujours beaucoup d'argent, donc cela n'aura pas d'importance non plus.