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


13

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?


15
ASP.NET et sa pile sont open source.
Andrew T Finnell

11
"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?" Par opposition aux bibliothèques fermées qui sont des boîtes noires?
user16764

5
@AndrewFinnell: Pas selon la propre définition du mouvement FLOSS.
tdammers

6
par rapport au projet de système d'exploitation auquel vous pensez, il peut être intéressant que Dapper soit utilisé par StackExchange ...
Marjan Venema

4
Ce n'est pas une question technique, ce n'est pas la meilleure solution. Lequel ira mal. MFC est mort, XP sera mort dans moins de 2 ans, etc. Un projet gratuit et open source ne mourra pas s'il est bon, car vous ou quelqu'un d'autre pouvez les reprendre. Il s'agit de savoir qui sera blâmé. Si vous choisissez Microsoft, ce sera imprévu, ou faute Microsofts. Si vous optez pour Free / opensource, ce sera votre faute.
ctrl-alt-delor

Réponses:


20

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.


16

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.


2
+1 Je suis d'accord avec tout cela sauf là où vous dites qu'il "(devrait)" regarder NoSQL; chaque solution de stockage de données NoSQL - il y en a beaucoup - a un ensemble particulier de compromis par rapport à une base de données relationnelle SQL «standard», il est donc difficile de dire «devrait» sans beaucoup d'informations. Parfois, ce sont de bons compromis, et parfois non, mais vous ne pouvez pas faire de déclarations générales à ce sujet. «NoSQL» ne fait que marquer les ordures autour d'un tas de technologies avec peu de choses en commun, à part le fait qu'il ne s'agit pas du système de stockage de données le plus courant.
Donal Fellows

Mais tout ce que vous écrivez, je suis définitivement d'accord. Un bon OSS prend beaucoup d'efforts sur les épaules du développeur de travail ordinaire (et qui voudrait utiliser un mauvais OSS?)
Donal Fellows

Dapper est complexe car il est généralisé. Si je devais écrire ma propre solution, je ferais beaucoup de code de conversion d'ensemble de données passe-partout (c'est-à-dire MyClass.Property = set.Tables[0].Rows[i]["Property"].ToString()).
M. Jefferson

Une fois que vous commencez à entrer dans votre domaine d'activité, vous aurez plus de mal à trouver --OSS - tout ce qui répond à vos besoins. À moins que l'entreprise de Microsoft ne soit votre entreprise. (mais j'aime le reste de ce que vous avez dit.)
ctrl-alt-delor

@richard Certaines de mes réponses peuvent ne pas être claires. Votre déclaration est ce que je dis également. Pourquoi se concentrer sur les pièces qui ont été résolues à maintes reprises comme ORM. Concentrez-vous sur le domaine des affaires. ORM n'est pas un domaine commercial sauf si vous vendez un produit ORM.
Andrew T Finnell

15

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.


3
+1: Je ne peux pas dire que je suis entièrement d'accord, mais c'est trop bien argumenté pour ne pas .....
mattnz

14
"Le budget d'un projet open source n'existe pas." est faux. Google a un budget pour les projets open source et Red Hat Inc., par exemple, ne peut pas gérer son entreprise s'il ne met pas suffisamment de codeurs sur son logiciel. Et qu'en est-il? microsoft.com/opensource/directory.aspx
ONOZ

14
Je ne suis pas d'accord avec un seul mot que vous avez dit.
Avio

11
Tous ces points s'appliquent également aux projets de sources fermées. L'ajout de bibliothèques / cadres de niche à source fermée ajoute de la diversité. Les anciennes technologies propriétaires sont abandonnées si elles ne leur rapportent pas d'argent. Vous pouvez toujours configurer IIS pour qu'il soit son propre papillon unique. Le commentaire de qualité ignore que le projet open source peut être plus grand que (certains) fournisseurs. Et le monde des affaires est très politisé, notamment avec Microsoft.
Philip

3
J'ai eu l'expérience inverse. Nous avons porté SQLite sur un appareil et avons pu obtenir de l'aide directement du gars qui en a écrit la plupart. Il n'y a aucun moyen que nous aurions obtenu ce niveau de service de la part d'une entreprise de source fermée. Certains projets open source sont absolument plus robustes et ont un meilleur support que certains projets open source. Je pourrais raconter une histoire sur l'utilisation du compilateur Microsoft C ++ «standard de l'industrie» pour OS / 2 et comment le support pour cela s'est passé lorsque Microsoft a décidé de se mettre sous OS / 2.
Gort le robot

7

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.)


7

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.


6

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,


1
+1 pour les problèmes de licence. Vérifiez soigneusement que l'utilisation d'un composant open-source ne vous forcera pas à open-source votre propre code aussi. Je ne pense pas que ce sera le cas pour la plupart des logiciels open source, et si vous ne l'utilisez que pour produire ou héberger votre code, il y en aura plus disponible, mais cela vaut néanmoins la peine d'être vérifié.
Lunivore

Même si les performances sont moins préoccupantes, l'EF me donne moins de contrôle. Introduire la mise en cache est un peu plus difficile si cela devient nécessaire en cours de route; Dapper serait plus facile à intégrer dans une solution plus personnalisée, en plus de pousser la nécessité de la mise en cache plus loin en premier lieu.
M. Jefferson

D'un autre côté, vouloir une solution personnalisée sur l'EF ressemble un peu à NIHS. Mon schéma de données est assez complexe avec beaucoup de relations (clés étrangères), et arriver au point où ma solution personnalisée gère ces relations ainsi que l'EF hors de la boîte prendrait certainement un certain temps.
M. Jefferson

@ Mr.Jefferson: sérieusement, je ne peux pas vous donner de bons conseils quelle est la meilleure solution dans votre cas, c'est quelque chose que vous devez trouver par vous-même. J'essayais juste de vous donner quelques conseils à prendre en considération.
Doc Brown

+1. Vous avez soulevé d'excellents points avec ce post. @ Mr.Jefferson: J'utilise Entity Framework depuis un certain temps maintenant et j'ai réussi à gérer les performances via une mise en cache ad hoc sur des référentiels spécifiques après avoir trouvé où se trouvent les goulots d'étranglement. De plus, notre produit est assez complexe, mais je n'ai toujours pas eu à recourir à l'écriture d'une seule requête SQL. Je pense que EF m'a donné beaucoup de contrôle.
StriplingWarrior

2

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.


1

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.


Je ne sais pas grand chose de ce qui s'est passé. C'était avant mon arrivée.
M. Jefferson

0

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.


0

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.


-1

Ê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"


5
Ironique alors qu'IBM est probablement le plus grand vendeur au monde de logiciels basés sur l'Open Source. Serveur http Apache, Eclipse etc. etc.
James Anderson

7
La vente d'OSS n'est pas illégale. Pourquoi serait-ce?
tdammers

1
IBMS httpServer est un apache pur, il vient juste avec un contrat de support.
James Anderson

2
Les choses changent. Maintenant, la direction commence à penser que si vous faites payer à l'entreprise un composant que d'autres entreprises avaient gratuitement, vous êtes un imbécile.
Avio

2
Les "autres colonnes" sont rarement vides pour l'open-source. Vous pouvez toujours obtenir le soutien de consultants ou de distributeurs ou de quelqu'un d'autre et vous pouvez également vous soutenir. Plus de colonnes sont souvent vides pour les logiciels commerciaux, car vous ne connaissez pas la qualité de leur support à l'avance et c'est rarement aussi utile que vous en auriez besoin.
Jan Hudec
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.