Sagesse de l'utilisation du code open source dans un logiciel commercial

Je cherche à utiliser du code open source dans mon application Web ASP.NET (en particulier Dapper ). Le management n'est pas fan, car l'open source est vu comme un risque qui nous a déjà mordu. Apparemment, les développeurs précédents ont dû réécrire des choses après l'échec des composants open source.

Les pros semblent être:

• Cela fait beaucoup de choses pour moi qui impliqueraient autrement beaucoup de code standard ou la solution recommandée mais plus lente de Microsoft (Entity Framework).

Les inconvénients:

• Il est suffisamment complexe pour que s'il échoue soudainement en production, j'aurais du mal à le réparer. Cependant, il est utilisé sur un site beaucoup plus fréquenté que le mien, donc je ne pense pas que cela finira par être une partie à haut risque du projet.

Quel est le consensus ici? Est-il imprudent d'utiliser du code open source dans mon projet que je ne connais pas / ne comprends pas aussi bien que je fais mon propre code?

C'est un choix que vous devrez faire en fonction des circonstances spécifiques. Vous pouvez atténuer vos risques en:

• tester le framework à fond, en évitant le risque de mauvaises surprises vous mordant dans un environnement de production, et
• en utilisant un couplage lâche pour minimiser la quantité de code qui dépend directement du framework, vous pouvez donc passer à votre propre implémentation si vous le devez sans réécrire l'intégralité de votre produit.

En fin de compte, avec un projet open source très utilisé, vous passerez probablement beaucoup plus de temps à écrire le vôtre qu'à résoudre les quelques problèmes que vous rencontrez.

J'irai jusqu'à dire que si votre réaction initiale est d'écrire quelque chose vous-même au lieu de voir si quelqu'un d'autre l'a écrit, vous êtes voué à l'échec. Ne prenez pas à la légère toutes les heures de travail et la correction de bogues qui sont allés dans les projets open source traditionnels.

Une fois que vous commencez à entrer dans votre domaine d'activité, vous aurez plus de mal à trouver des logiciels libres qui répondent à vos besoins. Mais il n'est pas nécessaire de réimplémenter encore un autre produit ORM. Si Dapper est suffisamment complexe pour que vous ne puissiez pas déboguer et corriger leur code, comment justifieriez-vous de passer toutes les heures de travail à l'écrire à partir de zéro? En outre, vous pourriez (devriez?) Toujours regarder en dehors des sentiers battus les solutions NoSQL pendant que vous y êtes.

Même Linus a admis avoir tenté de trouver une solution SCM répondant à tous ses critères avant de développer Git. Au moins, il a pu expliquer pourquoi aucune des solutions existantes n'était assez bonne.

À un moment donné de ma vie, j'ai cessé de vouloir tout réécrire moi-même et j'ai voulu me concentrer sur la résolution de problèmes du monde réel. La plupart des problèmes qui doivent être résolus dans une entreprise sont spécifiques à un domaine. Trouvez des façons d'écrire moins de code, pas plus.

Remarque: je ne suis pas un employé de Microsoft. L'opinion est tout à fait personnelle. Beaucoup de réflexions viennent des 5 à 7 dernières années d'utilisation à la fois de l'open source et de grands fournisseurs en tant que développeur.

La monoculture est bonne: Ma règle personnelle pour ASP.NET est de donner la préférence à Microsoft et de ne pas choisir de code tiers (open source ou non) sauf s'il n'y a pas d'autre choix. La monoculture est enrichissante, car vous êtes porté par un grand fournisseur, et la quantité d'utilisateurs répétant la même expérience est à tout moment suffisante pour obtenir de l'aide et trouver une solution.

Villes fantômes: le problème avec l'open source en 2012, c'est que ce n'est plus 2000 ou 2005. La quantité de projets ne cesse d'augmenter, alors que la quantité d'utilisateurs, d'adoptions, de contributeurs est à peu près la même qu'il y a des années. Le public est mince. De nombreux projets intéressants sont devenus obsolètes, abandonnés. Le budget d'un projet open source n'existe pas. Ainsi, lorsque l'intérêt cesse, il n'y a personne pour annoncer honnêtement que le soutien est terminé et éteindre les lumières. Les projets ne meurent jamais pour laisser l'attention du public se concentrer sur quelque chose de mieux et de nouveau. L'open source continuera donc de croître et de se fragmenter. N'ayant aucune rétroaction sous forme de récompense monétaire ou de mort financière, ce sont des entités immortelles, existant pour la gloire éternelle.

20 degrés de séparation: chaque fois que vous adoptez une nouvelle bibliothèque, vous vous séparez du courant dominant, vous vous déplacez vers une minorité de cas marginaux. Après avoir suivi 20 étapes telles que le choix de la configuration de la sécurité, l'utilisation d'une version, d'un framework, d'un plugin, etc. particuliers, votre solution devient une combinaison unique et globale de détails. La recherche sur Google n'aidera qu'à prouver la rareté ou l'unicité du problème. C'est toujours un problème égoïste, purement technique. Jamais même pertinent pour une entreprise réelle.

La qualité vient de la concentration, l'argent n'a pas d'importance: il n'y a aucun compromis entre les logiciels commerciaux et l'open source. Toute la communauté des devellopers n'est qu'une communauté comme elle l'a toujours été. Les grands fournisseurs ont simplement l'avantage de vieillir le code plus longtemps, dans de meilleures conditions, avec un public plus large que les groupes open source.

Consensus: vous demandez s'il y a consensus. Peut-être pas. Malheureusement, un grand nombre d'utilisateurs open source sont trop politisés. Après tout, l'open source est un mouvement social. L'open source est insensible à la critique, car très souvent les opinions négatives seront perçues comme une attaque personnelle anti-technologique. Mon consensus personnel: s'en tenir à Microsoft.

J'ai travaillé sur un certain nombre de projets réussis pour une grande entreprise qui utilisait des morceaux de logiciels open source substantiels. En particulier, j'ai utilisé Curl, SQLite et Webkit tous pour une très grande entreprise sur des projets réussis livrés aux utilisateurs finaux. Comme d'autres l'ont dit, il suffit de faire attention aux licences et, idéalement, de les examiner.

Il existe des centaines de licences open source, mais généralement elles se répartissent en deux catégories, le style BSD et le style GPL. Les licences de style BSD ne vous obligent pas à ouvrir votre propre code et ont généralement une sorte de clause d'attribution. Les licences de style GPL vous obligent à ouvrir votre propre code. La plupart des entreprises (y compris la mienne) regardent généralement cela de travers, vous voudrez donc éviter le style GPL. Dapper semble utiliser la licence Apache, qui est de style BSD. Déterminez toujours les conditions générales de licence avant de commencer à coder.

Il y a aussi la LGPL, qui est un cas de frontière intéressant dans la mesure où vous pouvez les utiliser sans ouvrir votre propre code si vous restreignez l'accès à une frontière binaire. (C'est-à-dire accéder à la bibliothèque uniquement en tant que bibliothèque dynamique.) L'utilisation de la bibliothèque LGPL est très faisable, il vous suffit d'être plus prudent.

D'après mon expérience, le code open source n'est pas plus susceptible de se révéler bogué ou d'échouer que les solutions payantes, ou, du reste, les solutions roll-your-own. Si vous regardez certains des outils open source les plus importants, la qualité est très élevée.

Vous voulez probablement éviter les projets de petite taille ou incomplets. Il peut être tentant de saisir quelque chose qui semble répondre à vos besoins, mais s'il s'agissait de quelque chose mis en place par quelques personnes, jamais achevé et non pris en charge, cela ne vaut probablement pas la peine. (À moins que vous ne souhaitiez travailler directement sur le code.)

Vous n'avez jamais vu de composants propriétaires tomber en panne auparavant? J'ai rencontré de nombreux bugs dans les logiciels des grandes et petites entreprises. Ce problème n'est pas un problème avec l'open source en soi, il s'agit plutôt de la maturité du projet.

Il semble que vous souhaitiez utiliser des projets matures qui offrent un soutien. Certains projets open source offrent un support payant, ou ont une communauté suffisamment grande pour que vous puissiez obtenir des réponses dans un forum public. Vous devriez peut-être faire de la maturité et des critères de support des priorités lors du choix d'une bibliothèque, qu'elle soit fermée ou open source.

Vous devez reconnaître que vous prenez plus de risques si vous décidez d'utiliser un projet immature ou avec un soutien limité. En tant que tel, vous devez déterminer quel est votre plan d'atténuation des risques. Par exemple, vous pouvez effectuer plus de tests sur le logiciel tiers.

En supposant que les problèmes de licence ne posent aucun problème ici: en jetant un coup d'œil à Dapper, j'ai remarqué qu'il ne contenait que 2255 lignes de code bien documenté et lisible . C'est

• suffisamment grand pour que vous puissiez investir plusieurs jours ou semaines pour produire un code de qualité comparable faisant de même
• suffisamment petit pour que vous puissiez comprendre ce qu'il fait et corriger les bogues de ce code s'ils apparaissent en production

Si vous allez écrire quelque chose comme ça par vous-même et "réinventer la roue", vous avez un risque beaucoup plus élevé que votre propre code affiche des bogues en production, et vous aurez vraiment du mal à les corriger.

Ce que vous devez faire ici, cependant, si vous introduisez un tel élément open source dans votre projet, vous devez assumer l'entière responsabilité de ce code, tout comme si vous l'aviez écrit par vous-même. Assurez-vous que le code est dans un état vous pouvez le maintenir, si nécessaire. Ne blâmez pas "les auteurs" de ce code si quelque chose ne fonctionne pas comme prévu.

Dans l'un de nos projets, nous avons également introduit certains composants open source, de petites tailles comme Dapper aux bibliothèques qui avaient environ 20K à 30K lignes de code. Nous devions toujours apporter des modifications, corriger des bugs, réduire quelque chose, etc., mais c'était correct, car nous nous y attendions. Même le temps pour le débogage inclus, l'utilisation de l'open source nous a fait économiser beaucoup de travail.

Une chose à penser ici: dans votre cas, vous mentionnez qu'il existe une alternative largement acceptée d'un grand fournisseur disponible (MS Entity Framework, pour lequel vous n'avez pas à payer de frais de licence supplémentaires!). Vous ne voulez pas l'utiliser pour des raisons de performances. Je recommande sérieusement de ne pas laisser la performance être le seul ou le principal point à considérer. Les questions que vous devez poser ici: Dapper possède-t-il toutes les fonctionnalités dont vous avez besoin maintenant et pour la durée de vie prévue de votre logiciel? Ou pouvez-vous prévoir que vous atteindrez rapidement les limites de Dapper et que vous devrez ajouter beaucoup de fonctionnalités manquantes, ce que vous n'auriez probablement pas à faire si vous aviez décidé d'utiliser EF en premier lieu? Si ce dernier est le cas, je recommanderais de ne pas utiliser Dapper. Demandez-vous également: EF n'est-il pas vraiment assez rapide pour votre application,

Selon moi, c'est un équilibre.

Si vous vous rendez dépendant d'un fournisseur, il est presque certain que le support disparaîtra sous peu

• Parce qu'ils ont des programmeurs à payer, ils doivent donc continuer à créer de nouvelles versions et à s'assurer que les anciennes sont impossibles à obtenir et ne fonctionnent plus (sur les plates-formes plus récentes) afin que les nouvelles aient un marché.

• S'ils ne peuvent pas vendre suffisamment pour justifier un modèle commercial, ils le font passer de la société A à la société B en C, chacun changeant suffisamment à nouveau, vous ne pouvez pas utiliser le nouveau sans reprogrammation, et vous pouvez ' t obtenir l'ancien qui fonctionne.

• Ils décident simplement de ne plus l'appuyer parce que c'est trop difficile et qu'il n'y a pas d'argent dedans. Tout l'argent est dans de nouvelles applications.

Donc, si vous voulez construire quelque chose qui n'a pas besoin d'être réécrit en permanence toutes les quelques années, l'open source peut être votre ami.

Je pense qu'il est sage de faire preuve d'une diligence raisonnable suffisante et il semble que vous ayez déjà fait quelques devoirs concernant l'histoire et l'activité d'un projet particulier. La possibilité d'étendre / ajouter des fonctionnalités dans le code source est également un gros pro. Avec des tests suffisants, vous pouvez minimiser le risque du côté con. Il est difficile de comprendre complètement toutes les dépendances de votre code, mais au moins dans ce cas, vous pourrez déboguer complètement et afficher le code si nécessaire.

Demandez à la direction pourquoi elle a échoué auparavant.

jquery a la possibilité d'utiliser la licence MIT, de nombreux sites Web commerciaux et gouvernementaux utilisent également jquery. Le site Web de Microsoft utilise également jquery! La préoccupation est donc l'octroi de licences. Évitez d'utiliser GPL / LGPL est suffisant.

"Combien de temps faut-il pour corriger un défaut signalé?" Après avoir signalé le bogue, il peut être corrigé en quelques minutes, heures ou jours. En cas d'urgence, le personnel peut simplement "git pull" pour obtenir la source et le compiler lui-même. Il rapporte simplement la version comme "v1.2.3-101-gd62fdae" à la direction, ce qui est traçable.

L'open source est vraiment une question de légalité, pas de qualité de code. Il existe de bons et de mauvais produits open source, tout comme il existe de bons et de mauvais produits open source. Je crois que votre dilemme est de savoir s'il faut utiliser un projet développé par une communauté de bénévoles.

Êtes-vous sûr que les problèmes de gestion sont des problèmes techniques.

Je dis cela car le mélange de l'OS et de l'activité commerciale est un domaine minier légal, et plus d'un manager a eu un "Veuillez expliquer" de l'équipe juridique / PDG ou pire, d'une autre organisation. La plupart des gestionnaires que je connais, même ceux qui adoptent activement les logiciels OS, sont (à juste titre) très prudents pour bien comprendre les situations juridiques auxquelles ils exposent l'origine. Si vous adoptez un logiciel OS et apportez des modifications, vous êtes obligé de retourner ces modifications à la communauté. Dans certains cas, cette obligation est légale, dans d'autres morale. Dans certaines licences de système d'exploitation, tout ce que vous faites devient un système d'exploitation simplement en établissant un lien vers celles-ci.

D'un point de vue technique, c'est vraiment juste une décision entre des produits concurrents - Posez quelques questions de base - Pouvez-vous obtenir le support dont vous avez besoin pour le package que vous choisissez?, Combien de temps pour obtenir une correction d'un défaut signalé, combien cela coûtera-t-il par développeur, par an ou une seule fois, etc. Le système d'exploitation a beaucoup de 0 dans la colonne $, mais il y a souvent des blancs dans les autres - seuls vous et votre patron pouvez décider si le 0 est plus important que les blancs ou non.

Et un autre point à retenir - "Personne n'a jamais été licencié en achetant IBM". (c'est-à-dire que la direction parle pour "Si vous dépensez beaucoup d'argent, ce doit être un meilleur produit qu'un produit gratuit"