Wo könnten sich Distributed Version Control Systems derzeit im Hype-Zyklus von Gartner befinden? [geschlossen]

Bearbeiten : Angesichts der jüngsten Abstimmungen (+ 8 / -6 zu diesem Zeitpunkt) wurde mir klar gemacht, dass der Lebenszyklus von Gartner aus Sicht eines Programmierers eine voreingenommene Metrik ist. Dies ist Teil eines Beitrags, den ich dem Management vorstelle , und Managementtypen gehören zu Gartners Publikum.

Wenn Sie DVCS bekannt und begeistert machen (was "als Hype" oder zumindest als solcher angegriffen werden könnte ), denken Sie beim Lesen an die folgende Frage: "Wie kann ich den Hype-Zyklus von Gartner nutzen, um das Management davon zu überzeugen, dass DVCS bereit sind (oder bereit genug) für uns, und dass es nicht nur ein Hype ist "

Nur zu fragen, ob DVCSs ein Hype sind, wäre nicht konstruktiv. Der Hype-Zyklus von Gartner ist ein objektiveres Instrument, als nur danach zu fragen (selbst wenn dieses Instrument als voreingenommen angesehen wird). Wenn Sie ein anderes Instrument kennen, erwähnen Sie es bitte unbedingt.

Bearbeiten # 2 : Ich stimme zu, dass Gartners Lebenszyklus nicht für jede Technologie gilt, aber ich bin der Meinung, dass er genug Aufsehen erregt hat, um von einigen als Hype angesehen zu werden, sodass es möglicherweise verdient ist, zumindest als solches bewertet / erwogen zu werden, indem dieses Instrument in verwendet wird um es zu beweisen / zu widerlegen, in welchem ​​Maße auch immer. Ich bin ein Befürworter von DVCS, BTW.

Edit # 3 : Danke für deine Antworten. Bounty geht an Caleb, um meine Frage mit ausführlichen und praktischen Ratschlägen zu beantworten. Die akzeptierte Antwort geht an philosodad, um ein weiteres nützliches Instrument bereitzustellen und über meine Frage hinaus zu antworten.

Ich recherchiere für ein Whitepaper, das ich für die Einführung von DVCS in Unternehmen schreibe, und bin auf das Konzept des sozialen Beweises gestoßen . Ich möchte beweisen, dass der soziale Beweis für die Einführung von DVCS nicht unbedingt ein Frachtkult ist, und bei weiteren Recherchen bin ich nun auf Gartners Hype-Zyklus gestoßen, der die Technologie-Reife in fünf Phasen beschreibt.

Meine Frage ist: Was könnte ein Indikator für die aktuelle Position verteilter Versionskontrollsysteme (ich meine Git, Quecksilber, Basar usw. im Allgemeinen) in einer bestimmten Phase des Hype-Zyklus sein? ... in anderen (weniger verworrenen) Mit anderen Worten, würden Sie sagen, dass die Erwartungen an DVCS derzeit a) beginnen, b) sich erhöhen, c) abnehmen (Desillusionierung), d) zunehmen (Erleuchtung) oder e) sich stabilisieren (Reife) und (was noch wichtiger ist) warum ?

Ich weiß, dass es eine schwierige Frage ist und dass es um Subjektivität geht, aber ich werde die Antwort (und das traditionelle Cookie) auf die klarsten Argumente / Beweise für eine bestimmte Phase geben.

Der Hype-Zyklus misst die Menge an Nachrichten / Buzz, die eine bestimmte Sache erzeugt, nicht die tatsächliche Verwendung der Sache oder ihren tatsächlichen Produktivitätswert. Also ... ich würde sagen, dass DVCS aus dieser Perspektive einen Höhepunkt in seinem Nachrichtenzyklus erreicht. Genug Leute benutzen es tatsächlich und ermutigen andere Leute, es zu benutzen, da es in der Technologiewelt viel Aufsehen erregt. Sobald die Akzeptanz weiter verbreitet ist, gehe ich davon aus, dass Nachrichten / Buzz etwas nachlassen, wenn etwas Neues und Glänzendes auftaucht, und dann wieder auftauchen, wenn die Leute anfangen, die Systeme vollständiger zu verstehen.

Eine Möglichkeit, den Hype-Zyklus zu betrachten, besteht darin, die Anzahl der neuen Anwender zu ermitteln. Die Anzahl der neuen Anwender einer Technologie folgt in der Regel genau der Kurvenform des Hype-Zyklus. Es ist sinnvoll, dass die Begeisterung für eine bestimmte neue Technologie schnell zunehmen wird, wenn die Technologie eine große Anzahl neuer Anwender gewinnt. Die Early Adopters verbreiten die Innovation und die Middle Adopters sorgen für Begeisterung.

Das Summen bei der schnellen Übernahme einer Innovation ist notwendigerweise schlecht informiert. Wenn es eine Menge Leute gibt, die etwas wissen, aber nichts davon wissen, werden sie andere und möglicherweise höhere Erwartungen haben als erfahrene Benutzer. Daher kommt der Hype.

Die Begeisterung nach dem Höhepunkt der Adoptionsrate wird nachlassen ... teilweise, weil sich frühere, unrealistische Erwartungen nicht ausgezahlt haben (DVCS wird Sie vielleicht produktiver machen, aber es wird nicht alle Ihre Probleme beheben) und teilweise, weil Etwas anderes befindet sich in einer raschen Adoptionsphase und übernimmt die gesamte Mindshare. Der Hype ist launisch.

Aber irgendwann wird die Zahl der Neueinsteiger ziemlich konstant, die Innovation ist zur Norm geworden, und die Neueinsteiger möchten wissen, wie sie dieses Ding verwenden können, für das sie sich bereits entschieden haben, es zu verwenden. Dann dreht sich alles um die Innovation, was die Leute jetzt damit machen, wenn sie es verwenden, und nicht darum, was sie damit machen könnten, wenn sie es verwenden.

Wenn Sie also die Hype-Kurve neben die S-Kurve der Akzeptanzraten setzen (siehe Everett Rogers "Diffusion of Innovations"), würden Sie erwarten, dass der Hype dort seinen Höhepunkt erreicht, wo die S-Kurve am steilsten ist, wenn sich die S-Kurve ändert Richtung, und wieder steigen, wenn die Innovation ihre volle Marktsättigung erreicht.

DVCS befindet sich in einer Phase rascher Akzeptanz, sodass wir uns wahrscheinlich auf dem Höhepunkt des Hype-Zyklus befinden.

Ich behaupte nicht, ein Experte für das Thema Hype-Zyklen zu sein, aber ich werde ein paar Beobachtungen machen:

1. Der Hype-Zyklus scheint eher ein Produkt der Erwartungen und der Berichterstattung der Medien als ein Merkmal der Technologie selbst zu sein. Mein Wörterbuch besagt, dass Hype "extravagante oder intensive Werbung oder Promotion" ist. Es definiert Werbung als "die Mitteilung oder Aufmerksamkeit, die die Medien jemandem oder etwas schenken". Medien sind ein Sammelbegriff für die verschiedenen Kanäle der Massenkommunikation.

2. Wenn Sie den vorherigen Punkt akzeptieren, gilt der Hype-Zyklus nur, wenn das Medium eine bestimmte Technologie abdeckt.

3. Es ist überhaupt nicht klar, dass der Hype-Zyklus für alle Technologien gilt. Wissenschaftliche Zeitschriften sind mit Berichten über Fortschritte gefüllt, die von den Massenmedien nie bemerkt werden. Ohne Medienberichterstattung ist es weniger wahrscheinlich, dass die Erwartungen überhöht werden, und die Talsohle der Desillusionierung kann vermieden werden.

4. Verteilte Versionskontrollsysteme sind weniger eine neue Idee als eine Weiterentwicklung einer alten. Es ist eine Strecke, sie eine "aufstrebende Technologie" zu nennen, wie sie der Hype-Zyklus vorhersagen soll.

Bevor Sie beginnen, einen Fall zu erstellen, bei dem DVCS in ein Hype-Zyklus-Diagramm passt, müssen Sie einen Fall erstellen, bei dem die verteilte Versionskontrolle überhaupt dem Hype-Zyklus unterliegt. Bekommt die verteilte Versionskontrolle als "Technologie" Medienberichterstattung? Gibt es jetzt oder gab es jemals überhöhte Erwartungen an die verteilte Versionskontrolle? Ist es wahrscheinlich, dass DVCS-Benutzer desillusioniert werden, wenn DVCS-Produkte die Erwartungen nicht erfüllen?

Mir scheint es wahrscheinlicher, dass die verteilte Versionskontrolle nur eine Verbesserung einer vorhandenen Produktkategorie darstellt, genau wie SVN eine Verbesserung von CVS darstellt. Wenn Sie die Adoptionsrate von SVN grafisch darstellen würden, würden Sie meiner Meinung nach keinen Plot erhalten, der dem Hype-Zyklus ähnelt. Stattdessen erhalten Sie einen Plot, der bis zum Plateau der Marktbeherrschung stetig ansteigt, gefolgt von einem langen, langsamen Rückgang, wenn verteilte Systeme wie "Git" an Popularität gewinnen.

Wenn Sie wirklich eine Hype-Cycle-Antwort brauchen, würde ich vorschlagen, dass DVCS nach einer Phase der Enttäuschung / Frustration mit nicht verteilten Versionskontrollsystemen dem Spiel beitritt und mit zunehmender Adoptionsrate den Aufklärungsgrad steigert.

Anstatt sich für Ihre Argumentation auf den Hype-Zyklus zu verlassen, würde ich vorschlagen, sich auf die Akzeptanzrate der verteilten Versionskontrolle und die Gründe dafür zu konzentrieren. Es gibt viele Anekdoten dafür, dass die Leute auf DVCS umsteigen, weil es funktioniert. Andererseits habe ich nicht gehört, dass jemand auf ein nicht verteiltes System zurückgeschaltet hat, weil er enttäuscht war. Um einige harte Daten zu erhalten, können Sie versuchen, mit einem Hosting-Unternehmen wie Beanstalk zu sprechen . Achten Sie auch auf die Interoperabilität zwischen zentralisierten Systemen und verteilten Systemen. Ich höre, dass "git" sehr gut mit SVN spielt. Zentralisierte Systeme funktionieren im Unternehmensbereich weiterhin recht gut, daher wird das "spielt gut mit" hervorgehoben.

Aktualisierung als Antwort auf die OP-Bearbeitung:

Wie könnte ich den Hype-Zyklus von Gartner nutzen, um das Management davon zu überzeugen, dass DVCSs bereit (oder bereit genug) sind [?]

Ich denke, dass es ein paar Ansätze gibt, die hier Abhilfe schaffen könnten, und alle stützen sich auf harte Daten:

Google Trends. Google sammelt offensichtlich eine Menge Daten darüber, was im Internet ist und wonach gesucht wird. Vor ein paar Tagen suchte ich nach Beweisen für den Hype-Zyklus der verteilten Versionskontrolle (konnte sie aber nicht finden). http://trends.google.com/ gibt an, dass nicht genügend Daten für die Begriffe " dvcs" oder " Distributed Version Control" vorhanden sind, wenn ich die Region auf die USA beschränke (und die weltweiten dvcs- Ergebnisse scheinen nicht sehr relevant oder hilfreich zu sein). Die Suche nach genaueren Begriffen war etwas besser, wurde jedoch durch die Tatsache erschwert, dass Produktnamen wie git und mercurial eine andere Bedeutung haben (wer wusste?). Das Ergebnis für git zeigt einen Trend, der teilweise auf das Versionskontrollsystem zurückzuführen sein könnte:

Bei dem Versuch, dies spezifischer für die Versionskontrolle zu machen, habe ich git repository ausprobiert :

Noch eines ... da ich herausgefunden habe, dass es einen zunehmenden Trend bei der Suche nach Hilfe bei Git-Befehlen geben sollte, wenn Leute Git einführen , habe ich Git Pull (blau), Git Commit (rot) und Git Rebase (gold) ausprobiert :

Diese letzte Grafik scheint den besten Beweis dafür zu liefern, dass Leute git übernehmen und benutzen.

Google-Suche.

Suchen Sie einfach nach Begriffen wie " Distributed Version Control" und notieren Sie sich die Daten der 25 wichtigsten Artikel, die Sie finden. Zeichnen Sie die Ergebnisse. Die meisten Top-Hits, die ich gefunden habe, hatten Daten im Bereich 2007-2009. Wenn der Hype-Zyklus zutrifft und Sie nachweisen können, dass der Großteil der Berichterstattung in den Medien vor 3-5 Jahren stattgefunden hat, scheint dies ein ziemlich guter Beweis dafür zu sein, dass wir über den Höchststand der überhöhten Erwartungen hinausgegangen sind.

Sammeln Sie Beispiele für Projekte, die DVCS verwenden.

Es gibt viele Beispiele in der Open Source-Welt, darunter einige große wie Linux. (Linus Torvalds hat git erstellt, um die Linux-Entwicklung zu verwalten.) Nützlicher für Sie sind Beispiele für Unternehmen, die ein DVCS verwenden. (Wenn Manager mehr hassen, als eine Technologie zu früh einzuführen, dann ist dies eine Zeitverschiebung.) Ein Hype ist nur das - ein Summen über eine Technologie oder ein Produkt. Wenn Sie Hinweise auf die Akzeptanz von DVCS in Unternehmen finden, hilft dies dabei, dem Argument "Es ist nur eine Menge Hype" besser als alles andere entgegenzuwirken.

Letzte Tipps:

• Sei präzise. Ihr Unternehmen wird nicht die gesamte Technologie übernehmen, sondern nur ein bestimmtes Produkt. Einige Produkte werden immer weniger ausgereift sein als andere. Wählen Sie zwei oder drei bekannte DVCS-Produkte aus und zeigen Sie, wie jedes in Ihren Entwicklungsprozess passt. Manager mögen konkrete Ideen besser als vage Versprechungen. Wenn sie die Technologie also spezifisch analysieren, fühlen sie sich wohler.

• Es ist nicht alles oder nichts. Jedes echte DVCS-Projekt wird weiterhin über ein zentrales Repository verfügen, sodass die Befürchtung, die Kontrolle über die Kronjuwelen zu verlieren, leicht überwunden werden kann.

• Sie müssen Ihr aktuelles System nicht aufgeben. Einige Tools wie git können gut mit vorhandenen Versionskontrollsystemen wie svn zusammenarbeiten. So können Sie DVCS ganz einfach zu Ihrem Entwicklungsprozess hinzufügen, ohne auf etwas verzichten zu müssen.

• Fangen Sie klein an. Wenn Sie nicht in einem kleinen Unternehmen mit nur einem Projekt arbeiten, sollte es einfach sein, DVCS für nur ein oder zwei Ihrer Projekte in den Prozess einzubinden. Sie müssen nicht mit dem Kopf voran springen, sondern nur einen Zeh eintauchen.

Kurz gesagt, identifizieren Sie die Widerstandspunkte und sprechen Sie sie so klar wie möglich an.

Argument / Beweis einer bestimmten Phase

Welche Phase auch immer das sein mag, es muss eine sein, die mit der Tatsache übereinstimmt, dass die Technologie " seit mehr als 10 Jahren" im professionellen Einsatz ist , da das vertriebene VCS TeamWare bereits seit mehr als 10 Jahren zur Verfügung steht: Das unten genannte pdf-Benutzerhandbuch ist vom Juli 2001 .

Laut Wikipedia befand sich die größte Bereitstellung von TeamWare in Sun selbst, wo (abgesehen von einigen Ausnahmen) nur VCS verwendet wurde - das Tausende Entwickler dazu bringt, das Tool zu verwenden. Mit TeamWare wurden die größten Quellbäume von Sun verwaltet, einschließlich derer für das Solaris-Betriebssystem und das Java- System.

Der Wikipedia-Artikel bezieht sich auf eine Usenix-Nachricht von Evan Adams, dem Architekturleiter von TeamWare.

Im Frühjahr 1991 beschlossen wir, das TeamWare-Projekt umzusetzen ...

TeamWare besteht aus einer Reihe von Befehlszeilen- und GUI-Tools, die aus mehreren gemeinsamen Bibliotheken erstellt wurden. Die Bibliotheken werden von der TeamWare-Gruppe zur Verwendung durch die TeamWare-Anwendungen bereitgestellt. Sie sind nicht für eine allgemeinere Verwendung vorgesehen.

TeamWare ist ein Code-Management-Produkt, das die parallele Entwicklung fördert und auf SCCS aufbaut. Ein Benutzer erstellt eine Kopie (Übergabe) einer SCCS-Hierarchie, wodurch eine persönliche Hierarchie erstellt wird. In dieser Hierarchie nimmt der Benutzer Änderungen vor und testet sie. Diese Änderungen werden dann in die ursprüngliche Hierarchie integriert (zurückgesetzt). Wenn die Integrationshierarchie Änderungen enthält, die nicht in der Benutzerhierarchie enthalten sind, erkennt TeamWare, dass parallele Änderungen vorgenommen wurden, und lehnt die Integration ab. Daher müssen Benutzer Änderungen in der Integrationshierarchie vor der Integration in ihre eigene Hierarchie integrieren. TeamWare enthält auch das Dienstprogramm filemerge, ein grafisches Drei-Wege-Unterschiedsprogramm, mit dem Benutzer parallele Änderungen zusammenführen können. TeamWare verfolgt sowohl Änderungen an Quelldateien (SCCS-Deltas) als auch Umbenennungen von Dateien ...

Bei Interesse finden Sie hier weitere Details:

• "Der alte Mann und das C" von Evan Adams
• "Sun WorkShop TeamWare-Benutzerhandbuch" auf der Oracle / Sun-Website - pdf ^{Juli 2001} , html

^{Meiner Erinnerung nach hatte das zentrale CVS / SVN damals den Vorteil, dass es unter Windows und Linux ausgeführt werden konnte, während TeamWare (SCCS) im Solaris-Dateisystem gesperrt war (unter Linux läuft es mehr oder weniger, wenn man weiß, wie man hackt falsche "Null-Prüfsummen" -Fehler).}

Meine Antwort:

Ich denke, die Antwort liegt irgendwo zwischen "Internet-TV" und "Cloud-Computing" auf der aufsteigenden Schulter des "Peak of Inflated Expectations" (obwohl ich denke, dass beide in den letzten paar Jahren ziemlich schnell vorangekommen sind).

Art des Hype-Zyklus:

Wie ich es verstehe, ist das Fortschreiten durch den Hype-Zyklus eher durch ein sich entwickelndes Bewusstsein für die Vor- und Nachteile einer bestimmten Technologie gekennzeichnet als durch ein objektives Maß für "Reife" (was auch immer das bedeutet).

Bevor wir eine ausreichend vielfältige Reihe von Erfahrungen gesammelt haben, um ausgewogene (und unabhängige ) Meinungen aufzubauen , herrscht (natürlich) eine Crowd-Dynamik mit stark korrelierten Meinungen mit geringer Vielfalt, Subtilität oder Tiefe der Analyse.

Dies gilt in der "Talsohle der Ernüchterung" ebenso wie in der "Spitze der überhöhten Erwartungen".

Wenn die Community ein breites und vielfältiges Spektrum unterschiedlicher Meinungen erstellen sollte, mit einer eingehenden Analyse, wo und wann der Einsatz von DVCS angemessen ist und wo und wann nicht, dann können wir daraus schließen, dass wir uns im "Plateau der Produktivität" befinden. (Oder zumindest ein Stück den "Hang der Aufklärung" hinauf).

Wenn andererseits der Diskurs auf die Überlegenheit (oder auf andere Weise) einer Technologie fokussiert ist, ohne Rücksicht auf die Einbrüche und Falten der Wettbewerbslandschaft, auf der sie steht, dann könnten wir schließen, dass wir uns entweder auf dem "Höhepunkt von" befinden Überhöhte Erwartungen "oder der" Tiefpunkt der Ernüchterung ". Wir könnten sogar in beiden Phasen gleichzeitig sein, wenn die Gemeinde durch einen Flammenkrieg in Lager geteilt wird.

:-)

Bewertung von DVCS nach diesen Kriterien:

Ausgehend von der relativ geringen Tiefe, die ich bisher im Diskurs gesehen habe, und der relativen Abwesenheit negativer Kommentare würde ich schätzen, dass wir derzeit den "Peak of Inflated Expectations" besteigen, wobei Fragen (wie diese) darauf hindeuten sind einige, die den Abhang auf der anderen Seite vorbereiten.

Ich denke, ein starker Indikator für die Reife der DVCS-Technologie (aus Unternehmenssicht) wird sein, wenn sich die Debatte von der Frage "Warum DVCS?" zu "Wie können wir unsere Arbeitsabläufe und Prozesse am besten nach DVCS strukturieren, um den größtmöglichen Nutzen für das Unternehmen zu erzielen?"

Nach allem, was ich gesehen habe, sind wir noch nicht alle da. (Obwohl einige unserer erfahreneren Landsleute den Weg weisen)

Die Rolle des Hype-Zyklus bei der Entscheidungsfindung:

Das "Hype Cycle" -Modell ist ein Modell der Verhaltensverzerrung und hilft uns, unseren eigenen mentalen Zustand zu verstehen. Wenn wir feststellen können, dass eine Technologie von anderen hochgespielt wird, kann dies unsere eigene mentale Haltung beeinträchtigen, und wir müssen uns (auf die Gefahr eines doppelten Denkens) gezwungen sehen, bei der Auswahl unserer Auswahlkriterien entsprechend zu kompensieren und vernünftig vorzugehen.

Auswahlkriterium:

Es ist unnötig zu erwähnen, dass Auswahlkriterien äußerst kontextabhängig sind.

Persönlich würde ich (als eine Art Brainstorming-Übung) eine kurze (15-minütige) SWOT-Analyse für jede Option durchführen, die Sie in Betracht ziehen, zusammen mit einer (ernsthaften) PEST-Analyse der Situation, um sicherzustellen, dass Sie umfassendere (nicht-technologische) Ergebnisse erzielen. Faktoren in Ihrer Analyse.

SWOT für Distributed VCS

Stärken:

• Flexibilität - mehr Freiheit bei der Auswahl verschiedener Arbeitsabläufe.
• Bessere Leistung über Netzwerkverbindungen mit geringer Bandbreite und hoher Latenz - besser für verteilte Teams und externe Mitarbeiter.
• Verbesserte Zusammenführungsfunktionen, sodass Sie häufiger verzweigen können. (Ich bin nicht sicher, ob das eine gute Sache ist).
• Der Quellcode wird auf jedem Entwicklercomputer "gesichert". (Hübscher Schwindel, dieser hier, da er die ordnungsgemäße Disaster Recovery-Planung beeinträchtigen könnte.)

Schwächen:

• Flexibilität - Da wir mehr Freiheit haben, verschiedene Workflows auszuwählen, müssen wir zusätzliche Arbeit leisten, um den von uns verwendeten Workflow zu definieren und zu erzwingen.
• Komplexität und konzeptionelle Schwierigkeiten (insbesondere für Teammitglieder, die keine Softwareentwickler sind).

Chancen:

• Vielleicht kann die Flexibilität genutzt werden, um einen Workflow zu entwickeln, der den geschäftlichen Anforderungen besser entspricht?

Bedrohungen:

• Vielleicht verbringen wir so viel Zeit mit der Überarbeitung unseres Workflows, dass wir uns nicht mehr auf unser Kernprodukt konzentrieren müssen?
• Es kann schwierig sein, einige Leute dazu zu bringen, auch nur einfache Werkzeuge zu benutzen, besonders wenn sie nicht glauben, dass sie notwendig oder auf andere Weise nicht motiviert sind.

SWOT für zentrales VCS

Stärken:

• Stellt einen impliziten In-Band-Kommunikationskanal für die Unternehmensorganisation und -prozesse bereit.
• Beschränkt mögliche Arbeitsabläufe auf eine (in vielen Fällen sinnvolle) Teilmenge.
• Erleichtert das Einrichten von CI und anderen Entwicklungsautomatisierungstools.
• (SVN-spezifisch) Unterstützt riesige Repositories.
• (SVN-spezifisch) Sehr stabil, wird von vielen großen, konservativen Organisationen verwendet.
• Politisch akzeptabler in einer Top-Down-Kommando- und Kontrollorganisation?

Schwächen:

• Unflexibel.
• Schlechte Leistung bei Verbindungen mit geringer Bandbreite und hoher Latenz, was die Verwendung für verteilte Teams und externe Mitarbeiter erschwert (insbesondere, wenn das Repository groß wird).

Chancen:

• Vielleicht können wir die monolithische Natur des Repositorys nutzen, um Entwicklern das Navigieren im Produkt und die Wiederverwendung des Codes zu erleichtern.

Bedrohungen:

• Wenn das Projekt plötzlich sehr wichtig wird und wir zusätzliche Entwickler an anderen Standorten einbeziehen müssen, können sie dann effektiv mit einem SVN-Repository zusammenarbeiten, das (für sie) außerhalb des Standorts gehostet wird?
• Wenn die Anzahl der Entwickler so groß wird, dass ihre Koordinierung schwierig wird, wird das zentrale Repository dann zu einem Engpass? (Können wir das anders umgehen?)

Fazit:

Welches VCS verwendet wird, hängt von den jeweiligen Umständen ab. In vielen Situationen, in denen ich gearbeitet habe, hätte ein DVCS mit einem zentralisierten Workflow gut funktioniert, aber ich hätte die Zeit und den Aufwand für den Aufbau eines Mechanismus zur Unterstützung und Durchsetzung des Workflows rechtfertigen müssen, was (immer noch) der Fall gewesen wäre ist schwierig.

Letztendlich denke ich, dass sich die Diskussion um die Frage drehen sollte: Welcher Workflow passt am besten zu unserem Geschäft? Das beste zu verwendende Werkzeug sollte sich natürlich aus der Antwort auf diese Frage ergeben.