Les systèmes de contrôle de version FOSS fonctionnent-ils pour les entreprises? [fermé]

11

Supposons qu'une grande entreprise envisage de remplacer son système de contrôle de version existant. Disons qu'il ne prend en compte que les systèmes des principaux fournisseurs qui coûtent des centaines de milliers de dollars parce qu'ils ont un "support".

Le contrôle de version dans un environnement d'entreprise doit-il être coûteux? Votre moyenne / grande entreprise utilise-t-elle un FOSS VCS tel que SVN / Git / Mercurial? Quelle a été l'expérience?

Je dois penser que cela n'a pas besoin d'être cher car il y a tellement d'options gratuites, et il y a probablement des entreprises qui fournissent une assistance payante pour FOSS VCS si c'est la principale préoccupation.

Je n'ai pas l'intention de comparer cette question à VCS ou de décider laquelle est la meilleure, mais plutôt de comprendre les expériences avec VCS dans un environnement informatique d'entreprise.

jimueller
la source

Réponses:

29

Oui.

  
D'après mon expérience (certes limitée), les solutions non-FOSS ont tendance à être plus «d'entreprise». C'est,

  • Ils s'intègrent à tout sous le soleil.
  • Ils ont plus de contrôles intégrés pour la logique métier complexe (autorisations, contrôle d'accès, approbation, etc.).
  • Ils viennent avec des contrats de support et des lignes de support technique raisonnablement réactives.
  • Ils sont bien annoncés aux personnes non techniques qui prennent des décisions VCS à un haut niveau dans les grandes entreprises.

Ces attributs les rendent attrayants pour les grandes entreprises, en particulier pour les personnes qui n'ont pas à les utiliser. Les alternatives FOSS, en guise de contre-indications à ce qui précède:

  • Avoir de nombreux outils tiers pour les intégrer à tout sous le soleil (en raison d'être plus populaire que les alternatives propriétaires), et ont tendance à être plus faciles à développer des outils tiers pour, étant OS.
  • Voir précédent - plus facile d'obtenir des outils externes autour d'un outil simple, simple et propre.
  • En raison de leur popularité accrue, ils bénéficient d'un soutien communautaire plus large.
  • Ils n'ont pas besoin de cette publicité.

En plus de cela, mon expérience avec les VCS gratuits courants (mercurial / svn / etc) les a rendus plus rapides, plus fiables et plus faciles à utiliser.

Fishtoaster
la source
5
+1 - Je suis beaucoup plus heureux avec SVN que je ne l'ai jamais été avec SourceSafe.
Jon Hopkins
5
@Jon +1 - Je suis beaucoup plus heureux avec Mercurial que je ne l'ai jamais été avec SVN.
Tim Post
1
@Tim - Évalue actuellement de manière informelle Mercurial avant une éventuelle migration.
Jon Hopkins
8

Je suis d'accord avec @Fishtoaster en ce que le contrôle de version FOSS possède toutes les fonctionnalités (ou peut être intégré à d'autres logiciels FOSS qui fournissent les fonctionnalités) dont même les plus grandes "entreprises" ont besoin.

Malheureusement, d'après mon expérience, de nombreuses décisions dans les entreprises ne sont pas prises par des personnes techniquement compétentes pour prendre cette décision. Autrement dit, les personnes autorisées à effectuer des achats dans une entreprise sont directement ciblées par le service commercial d' autres entreprises pour acheter leurs logiciels. Les logiciels libres ne sont même pas regarder en car il n'y a personne la vente à eux.

Dans un endroit où j'ai travaillé, nous avons utilisé l'une de ces solutions de contrôle de version "entreprise". C'était lent (il a littéralement fallu plus d'une heure pour faire un "check out" complet de la dernière version du code!) Et buggy et tout le monde s'en est plaint. De nombreux développeurs feraient en fait la vérification (prenant, comme je l'ai dit, plus d'une heure ), puis mettraient en place un référentiel SVN ou Mercurial local au-dessus de cette caisse, effectuaient leur codage par rapport à ce référentiel et ne le réintégraient dans le référentiel principal que lorsque obligatoire.

Nous avons eu la chance de pouvoir installer tous les logiciels dont nous avions besoin. Mais le fait que les gens aient renversé le "processus" comme celui-ci me dit qu'il y avait quelque chose de grave dans le processus ...

Dean Harding
la source
1
C'est exactement ce que j'ai fait, configurer mon propre SVN local car le VCS fourni est si terrible.
jimueller
4

La principale différence entre les logiciels libres et commerciaux est que le premier est basé sur la fierté tandis que le second est basé sur le revenu.

Demandez-vous: dans quelle mesure les gens qui ont écrit le logiciel XYZ sont-ils heureux?

Si c'est FOSS, ils étaient probablement très heureux car sinon, pourquoi se donneraient-ils la peine de perdre leur temps dessus?

S'il s'agit d'un logiciel commercial, vous ne pouvez pas vraiment le savoir. Les chances sont que les gens ont été payés pour écrire quelque chose qu'ils n'aiment pas vraiment.

Le logiciel FOSS gagne donc en amour. Cela ne signifie pas nécessairement que c'est mieux mais si c'est un projet FOSS réussi, vous pouvez être sûr qu'il est meilleur que tout ce que vous pouvez acheter ("L'argent ne peut pas acheter le bonheur", vous vous souvenez?).

Comment pouvez-vous dire que c'est réussi? Consultez le site Web. Si le site Web est à jour et a l'air bien, il est suffisamment efficace pour perdre du temps sur le site Web (les développeurs FOSS sont un noyau dur; ils ne veulent pas perdre de temps sur tout ce qui ne gratte pas les démangeaisons).

Cela laisse le point le plus important: le soutien. Les entreprises n'achètent pas de logiciels pour les utiliser légalement mais pour obtenir de l'aide en cas de problème (en pensant: si 100 personnes ne peuvent pas travailler et que je reçois un correctif en une journée, cela vaut 100 000 $). Heureusement, vous pouvez acheter une assistance pour le logiciel FOSS (il suffit de consulter le site Web pour des pointeurs ou de demander sur la liste de diffusion).

Alors oui, si vous faites une évaluation et que les logiciels libres répondent à vos besoins, il n'y a plus aucune raison de préférer les logiciels commerciaux.

Aaron Digulla
la source
2

J'ai personnellement vu SVN travailler avec succès dans une grande entreprise et j'ai entendu des récits d'autres réussites. Je pense que l'un des éléments clés qui fait peur aux entreprises à propos de l'open source est le manque de support. Ils ont l'impression d'être sur une corde raide sans filet de sécurité. Mais souvent, vous pouvez trouver des entreprises qui fourniront des contrats de support pour les logiciels open source. Pour SVN, il y a CollabNet et d'autres.

RationalGeek
la source
1
Mais SVN ne fait vraiment pas très bien les branchements, il est fondamentalement nul. Alors, comment pouvez-vous utiliser SVN sur un projet où vous êtes, disons, plus de 10 personnes travaillant sur la même base.
Bjarke Freund-Hansen
@bjarkef: Je fais de temps en temps des branchements et des fusions avec subversion. Je pense que c'est une légende, que SVN est nul. Bien sûr, Git et Mercurial sont basés sur un système complètement différent, qui est basé sur des branches. Mais il est en conflit pas moins souvent que Subversion. La fusion n'est donc pas le problème, seules certaines personnes préfèrent le style que les dépôts et les branches sont organisés avec DVCS.
Mnementh
3
Ouais. Vraiment, de mon point de vue, SVN se branche très bien . Probablement parce que notre contrôle de source avant c'était Visual Source Safe, qui était épouvantable à la ramification (et TOUT AUTRE).
John Christensen
@John - Mon problème était que passer d'un DVCS à un CVCS était vraiment difficile. Ma progression VCS a été RCS> VSS> Mercurial> SVN. Les deux premières transitions ont été faciles et ont rendu beaucoup de choses plus simples, plus faciles et plus rapides. Le dernier a été un cauchemar - même l'utilisation de git-svn ne peut pas annuler l'inflexibilité inhérente à l'histoire linéaire désuète de SVN. J'ai hâte de passer à git, même si j'aurais préféré la simplicité de mercurial.
Mark Booth