Edit: Given the recent downvoting (+8/-6 at this point) it was made clear to me that Gartner's lifecycle is a biased metric from a programmer's perspective. This is something that is part of a paper I'm going to present to management, and management types are part of Gartner's audience.

Giving DVCS exposure & enthusiasm (that "could" be deemed as hype, or at least attacked as such), think about the following question when reading this one: "how could I use Gartner's hype cycle to convince management that DVCSs are ready (or ready-enough) for us, and that it is not just hype"

Just asking if DVCSs is hype wouldn't be constructive, Gartner's hype cycle is a more objective instrument than just asking that (even if this instrument is regarded as biased). If you know any other instrument please, by all means, mention it.

Edit #2: I agree that Gartner's Life Cycle is not for every technology, but I consider it may have generated enough buzz to be considered hype by some, so it maybe deserves to be at least evaluated/pondered as such by using this instrument in order to prove/disprove it to whatever degree. I'm an advocate of DVCS, BTW.

Edit #3: Thanks for your answers. Bounty goes to Caleb for answering my question with detail and practical advise. Accepted answer goes to philosodad for providing another useful instrument and answering beyond my question.

I'm doing research for a whitepaper I'm writing in favor of DVCS adoption at company and I stumbled upon the concept of social proof. I want to prove that the social proof of DVCS adoption is not necessarily cargo cult and doing further research I now stumbled upon Gartner's hype cycle which describes technology maturity in 5 phases.

enter image description here

My question is: what could be an indicator of the current location of Distributed Version Control Systems (I mean git, mercurial, bazaar, etc. in general) at a particular phase in the hype cycle?... in other (less convoluted) words, would you say that currently expectations of DVCSs are a) starting, b)inflated, c)decreasing (disillusionment), d)increasing (enlightenment) or e)stabilizing (mature) and (more importantly) why?

I know it is a hard question and there is subjectivity involved, but I'll grant the answer (and the traditional cookie) to the clearest argument/evidence for a particular phase.

  • 1
    at more than 10 years, it has to be at "Plateau of Productivity" per that artificial scale – gnat May 26 '12 at 4:46
  • @gnat: I agree 100%! Back in 2000, when I worked at Sun I used SCCS/Teamware, which got it right. I scratched my head wondering how anyone could possibly like CVS. Linus Torvalds thought the same, and stuck with BitKeeper until he made Git. It's CVS/SVN that had the unnecessary hype! – Macneil May 26 '12 at 5:03
  • @Macneil well per my recollection, CVS/SVN were capable of running on Windows and Linux, while TeamWare/SCCS has been locked in Solaris filesystem (at Linux it run more or less, if one knew how to hack over spurious "zero checksum" bugs). Not that I mean one or other is better, just adding some facts – gnat May 26 '12 at 5:09
  • 7
    The time scale on the chart doesn't seem to relate to time since original introduction. Just for example, "Wireless power" is shown toward the left side even though Tesla did it in the 1890's and even if we restrict it to high tech/computer kinds of things, passive RFID tags have been using it for quite a while too. – Jerry Coffin May 26 '12 at 6:18
  • @gnat: Time doesn't mean anything here. Any given technology may stay forever on a specific stage, and even die there. – CesarGon May 26 '12 at 12:50

The hype cycle measures the amount of news/buzz that a particular thing generates, not the actual use of the thing or it's actual productivity value. So... I would say that from that perspective, DVCS is reaching a spike in its news cycle. Enough people are actually using it and encouraging other people to use it that it is getting a lot of buzz in the tech world. Once adoption is more widespread, I expect that news/buzz to fade a bit when something new and shiny comes along, and then rise again as people start to understand the systems more completely.

One way to look at the hype cycle is to look at the number of new adopters. The number of new adopters of a technology tends to follow the same exact curve shape as the hype cycle. It makes sense that the buzz around a given new technology is going to grow rapidly as the technology gains a large number of new adopters. The early adopters spread the innovation, and the middle adopters generate the buzz.

The buzz during rapid adoption of an innovation is neccessarily poorly informed. If there are a lot of people who know of something but don't know about it, they are going to have different and possibly greater expectations than experienced users. So that's where the hype comes from.

The buzz after the rate of adoption has peaked is going to fall off... partly because earlier, unrealistic expectations have not paid off (DVCS will make you more productive, perhaps, but it won't fix all your problems) and partly because something else is going through a rapid adoption period and is taking up all the mindshare. Hype is fickle.

But at some point, you start getting a fairly constant rate of new adopters, the innovation has become the norm, and the new adopters want to know how to use this thing that they've already decided they need to use. Then the buzz around the innovation is all about what people actually are doing with it now that they are using it, rather than what they could do with it if they were using it.

So if you took the hype curve and put it next to the S-Curve of adoption rates (See Everett Rogers "Diffusion of Innovations") you would expect the hype to peak where the S-curve is steepest, trough as the S curve changes direction, and rise again as the innovation reaches its full market saturation.

DVCS is in a period of rapid adoption, so we're probably somewhere around the peak of the hype cycle.

  • So, essentially you are saying that DVCSs could be at the peak because people are still preaching about it?, or rising again because it is getting understood better? – dukeofgaming May 28 '12 at 19:22
  • I would say that the potential pool of adopters is still large, so there's a lot of curiosity and new, excited users. If you look at the S-Curve in Rogers "Diffusion of Innovations", DVCS is, I think, on the steep part--it's rapidly being adopted. This rapid adoption generates hype in news/buzz. As adoption saturates, hype decreases. The thing is now old news. Then, when adoption becomes the norm, news and buzz become more about what people are actually doing, rather than what they could do. – philosodad May 29 '12 at 16:51
  • 1
    philosodad, could you ellaborate on this as part of the answer? – dukeofgaming May 29 '12 at 17:04
  • @dukeofgaming I've modified my answer to elaborate on that point. – philosodad May 29 '12 at 17:12

I don't claim to be an expert on the subject of hype cycles, but I'll offer a few observations:

  1. The hype cycle seems to be more a product of expectations and media coverage than a characteristic of technology itself. My dictionary says that hype is "extravagant or intensive publicity or promotion." It defines publicity as "the notice or attention given to someone or something by the media." Media is a collective term for the various channels of mass communication.

  2. If you accept the previous point, it follows that the hype cycle applies only when the media covers a given technology.

  3. It's not at all clear that the hype cycle applies to all technologies. Scientific journals are filled with reports of advances which are never noticed by the mainstream media. Without media coverage, expectations are less likely to be inflated and the trough of disillusionment can be avoided.

  4. Distributed version control systems aren't so much a new idea as a refinement of an old one. It's a stretch to call them an "emerging technology" of the sort that the hype cycle is supposed to predict.

Before you start to build a case for where DVCS's fit on a hype cycle graph, you need to build a case that distributed version control is subject to the hype cycle at all. Does distributed version control as a "technology" get media coverage? Are there now, or have there ever been, inflated expectations for distributed version control? Is it likely that DVCS users will become disillusioned when DVCS products don't live up to expectations?

It seems more likely to me that distributed version control is just an improvement on an existing category of products, just as SVN was an improvement on CVS. If you were to chart the adoption rate of SVN, I don't think you'd get a plot that looks like the hype cycle; instead, you'd get a plot that increases steadily up to the plateau of market dominance, followed by a long slow decline as distributed systems like 'git' gain popularity.

If you really need a hype-cycle answer, I'd suggest that DVCS joined the game at the bottom of a period of disillusionment/frustration with non-distributed version control systems and has been climbing the slope of enlightenment as the adoption rate increases.

Instead of relying on the hype cycle for your argument, I'd suggest focusing on the adoption rate of distributed version control and the reasons for it. There's plenty of anecdotal evidence that people are switching to DVCS because it works; on the other hand, I haven't heard of anyone switching back to a non-distributed system because they were disappointed. To get some hard data, you might try talking to a hosting company such as Beanstalk. Also, pay attention to interoperability between centralized systems and distributed systems. I hear that 'git' plays very nicely with SVN. Centralized systems continue to work pretty well in the corporate realm, so emphasizing the "plays nicely with" aspect could make a DVCS less risky and therefore more attractive to decision makers.

Update in response to OP's edit:

how could I use Gartner's hype cycle to convince management that DVCSs are ready (or ready-enough)[?]

I think that there are a few approaches that could help here, and all rely on hard data:

Google Trends. Google obviously collects a ton of data about what's on the net and what people search for. A few days ago, I looked for (but couldn't find) evidence of the hype cycle w.r.t. distributed version control. http://trends.google.com/ says that there's not enough data for the terms dvcs or distributed version control when I limit the region to the US (and the dvcs results for the world don't seem very relevant or helpful). Searching for more specific terms was somewhat better, but complicated by the fact that product names like git and mercurial have other meanings (who knew?). The result for git shows a trend that might be due in part to the version control system:

git trend

Trying to make that more specific to version control, I tried git repository:

git repository trend

One more... figuring that if people are adopting git there ought to be an increasing trend in searching for help with git commands, I tried git pull (blue), git commit (red), and git rebase (gold):

git pull/commit/rebase trend

That last graph seems to provide the best evidence that people are adopting and using git.

Google search.

Try simply searching for terms like distributed version control and note the dates on, say, the top 25 articles you find. Plot the results. Most of top hits I found had dates in the 2007-2009 range. If the hype cycle applies, and if you can show that most of the media coverage happened 3-5 years ago, that seems like pretty good evidence that we've moved beyond the peak of inflated expectations.

Collect examples of projects that use DVCS.

There are plenty of examples in the open source world, including some big ones like Linux. (Linus Torvalds created git to help manage Linux development.) More useful to you will be examples of corporations that use a DVCS. (If there's anything managers hate more than adopting a technology too early, it's being behind the times.) Hype is just that -- buzz about a technology or product. If you can find evidence of corporate adoption of DVCS, that'll help counter the "it's just a lot of hype" argument perhaps better than anything else.

Last tips:

  • Be specific. Your company isn't going to adopt an entire technology -- you'll adopt a specific product. Some products are always going to be less mature than others. Pick two or three well-known DVCS products and show how each would fit into your development process. Managers like concrete ideas better than vague promises, so analyzing the tech in specific terms will make them feel more comfortable.

  • It's not all-or-nothing. Any real project using a DVCS is still going to have a central repository, so fears about losing control of the crown jewels can be easily assuaged.

  • No need to give up your current system. Some tools, like git, can play well with existing version control systems, like svn. So you can easily add DVCS to your development process without giving anything up.

  • Start small. Unless you're at a small company that has just one project, it ought to be easy to incorporate DVCS into the process for just one or two of your projects. You don't have to jump in head first -- just dip a toe.

In short, identify the points of resistance and address them as clearly as you can.

  • 1
    The hype cycle applies in all but a few degenerate cases, even where not reported by the media. The cases where it doesn't are where there is never initial adoption (stillborn tech) and where the trough of disillusionment hits zero (often due to the tech being superseded by something wholly better). – Donal Fellows May 26 '12 at 14:15
  • 2
    When was the "trough of disillusionment" for the web browser? – Gort the Robot May 29 '12 at 0:20
  • 1
    @StevenBurnap Was the browser hyped at any moment? (genuine question) – dukeofgaming May 29 '12 at 1:47
  • 1
    On the other hand, does the hype cycle apply to ANYTHING? Is there any actual research that supports this? As far as I can tell, the hype cycle is almost entirely about fitting the news pattern to something after the fact. It doesn't tell you anything about the future, the current state of a innovation, its curve of future change, or even if you should adopt it or not. – philosodad May 29 '12 at 23:55
  • 1
    @WilliamPayne I'll grant that it's possible that some community could suddenly discover an existing technology, and that the media within that community might generate hype/buzz following the hype cycle pattern. I'd point out, though, that the chart in the OP's question is labelled "Hype Cycle for Emerging Technologies." Also, it's not enough to posit that such a thing could happen -- you really need to point to examples where that has happened. As philosodad points out, whether the hype cycle is real or just perceived is an open question. – Caleb May 30 '12 at 22:30

My Answer:

I think that the answer lies somewhere between "Internet TV" and "Cloud Computing" on the rising shoulder of the "Peak of Inflated Expectations" (Although I think that both of these have moved on somewhat rapidly in the past couple of years).

Nature of the Hype Cycle:

As I understand it, progression through the hype cycle is characterized by an evolving awareness about the pros and cons of a particular technology, rather than by any objective measure of "maturity" (whatever that means).

Before we have accumulated a sufficiently diverse set of experiences to build balanced (and independent) opinions, crowd dynamics (naturally) hold sway, with highly correlated opinions with little diversity, subtlety or depth of analysis.

This is as true in the "Trough of Disillusionment" as it is in the "Peak of Inflated Expectations"

If the community were to produce a wide and diverse range of different opinions, with in depth analysis about where and when it is appropriate to deploy DVCS and where and when it is not, then we can infer we are in the "Plateau of Productivity" (Or at least some way up the "Slope of Enlightenment").

If, on the other hand, the discourse is focussed on the superiority (or otherwise) of a technology without regard to the dips and folds of the competitive landscape upon which it stands, then we might infer that we are either on the "Peak of Inflated Expectations" or the "Trough of Disillusionment". We could even be in both phases at the same time, if the community is divided into camps by a flame war.


Evaluation of DVCS according to these criteria:

From the relatively shallow analysis that I have seen in the discourse so far, and the relative absence of negative commentary, I would estimate that we are currently climbing the "Peak of Inflated Expectations", with questions (such as this one) indicating that there are some who are preparing the slope down on the other side.

I think a strong indicator of the maturity of DVCS technology (from a corporate standpoint) will be when the debate shifts from asking simply "Why DVCS?" to "How can we best structure our workflow and processes around DVCS to maximise benefit to the organisation?".

From what I have seen, we are not all there yet. (Although some of our more sophisticated compatriots are leading the way)

The role of the Hype Cycle in decision making:

The "Hype Cycle" model is a model of behavioral bias, and it helps us understand our own mental state. If we can determine that a technology is hyped by others, then that may affect our own mental stance, and (at the risk of some double-think) we may need to compensate accordingly and force ourselves to behave rationally in choosing our selection criteria.

Selection Criteria:

Needless to say, selection criteria choices are extremely context dependent.

Personally I would do (as a sort of brainstorming exercise) a short (15 minute) SWOT analysis of each option that you are considering, together with (seriously) a PEST analysis of the situation to ensure that you bring broader (non-technological) factors in your analysis.

SWOT for Distributed VCS


  • Flexibility - more freedom to choose different workflows.
  • Better performance over low-bandwidth/high-latency network connections - better for distributed teams & off-site workers.
  • More sophisticated merge functionality, allowing you to branch more often. (I am not sure that this is a good thing).
  • Source code is "backed up" on each developers machine. (pretty bogus, this one, as it might interfere with proper disaster recovery planning)


  • Flexibility - Because we have more freedom to choose different workflows, we need to do additional work to define which workflow we are using, and to enforce it.
  • Complexity & Conceptual Difficulty (especially for non-software-developer team members).


  • Perhaps the flexibility can be utilized to engineer a workflow that is better suited to business needs?


  • Perhaps we will spend so long re-engineering our workflow we will loose focus on our core product?
  • It can be difficult to get some people to use even simple tools, especially if they do not believe that they are necessary or are otherwise not motivated.

SWOT for Centralized VCS


  • Provides an in-band implicit communications channel for business organisation & process.
  • Restricts possible workflows to a (in many cases reasonable) subset.
  • Makes it easier to set up CI & other development automation tools.
  • (SVN specific) Supports huge repositories.
  • (SVN specific) Very stable, used by lots of big, conservative organisations.
  • Politically more acceptable in a top-down command & control organization?


  • Inflexible.
  • Poor performance over low-bandwidth / high-latency connections, making it harder to use for distributed teams and off-site workers (especially if the repository gets big)


  • Perhaps we can use the monolithic nature of the repository to help developers navigate the product and reuse each other's code more?


  • If the project suddenly becomes hyper-important and we need to bring in additional developers working on other sites, can they effectively work with a SVN repository hosted (for them) off-site?
  • If the set of developers grows so large that coordinating them becomes difficult, will the single centralized repository become a bottleneck? (Can we get around this any other way?)


Which VCS to use is dependent upon individual circumstance. For many of the situations in which I have worked, a DVCS with a centralized workflow would have done just fine, but I would have had to justify the time & effort to build out mechanism to support and enforce workflow, which would have been (still is) difficult.

Ultimately, I think that the discussion should center around the question: What workflow best suits our business? The best tool to use should follow naturally from the answer to that question.

  • To answer your question in the other comment: enterprise application – dukeofgaming May 31 '12 at 5:45

argument/evidence of a particular phase

Whatever phase could that be, it has to be one that matches the fact that technology is in professional use for "more than 10 years", since distributed VCS TeamWare has been there for more than that: pdf User's Guide referred below is dated July 2001.

Per Wikipedia, TeamWare's largest deployment was inside Sun itself, where (bar a few exceptions) at one point it was the only VCS used - that makes thousands developers using the tool. TeamWare has been used to manage Sun's largest source trees, including those for the Solaris operating system and the Java system.


Wikipedia article refers to a Usenix message from Evan Adams, who was the architectural lead for TeamWare, which states in particular:

In the spring of 1991 we decided to implement the TeamWare project...

TeamWare is a set of command line and GUI tools built from several common libraries. The libraries are provided by the TeamWare group for use by the TeamWare applications; they are not provided for more general use.

TeamWare is a code management product that encourages parallel development and is built on top of SCCS. A user makes a copy (bringover) of an SCCS hierarchy thus creating a personal hierarchy. In this hierarchy the user makes and tests changes. These changes are then integrated (putback) into the original hierarchy. If the integration hierarchy contains changes which are not in the user's hierarchy, then TeamWare detects that there have been parallel changes and refuses the integration. Therefore, users must incorporate changes in the integration hierarchy into their own hierarchy before integrating. TeamWare also includes the filemerge utility, a graphical three-way differences program allowing users to merge parallel changes. TeamWare tracks both source file changes (SCCS deltas) and file renames...

If you're interested, find more details here:

Per my recollection, centralized CVS / SVN back then had an advantage of being capable to run on Windows and Linux, while TeamWare (SCCS) has been locked in Solaris filesystem (at Linux it run more or less, if one knew how to hack over spurious "zero checksum" bugs).

  • 4
    There are technologies of 10+ years before the peak of inflated expectations. I'm not sure time alone can position a particular technology at a phase. – dukeofgaming May 26 '12 at 5:26
  • @dukeofgaming well more than 10 years is an objective fact and I state just it. Whatever subjective "phase" / "hype-measure" would be stuffed over it, the fact has to be there – gnat May 26 '12 at 5:49
  • 1
    Sorry, I still don't get your point. If I understand correcty you are saying ~10 years are an objective fact, but for what phase? – dukeofgaming May 26 '12 at 6:02
  • 1
    @gnat: Well, I think that "Hype Cycle" is a big misnomer. The Hype Cycle is not about hype but technology maturity. Hype is just a consequence of a technology being much talked about but not mature enough; the cycle shows this but also other aspects, such as adoption. So, in summary, I am taking the Hype Cycle for what it portrays wrt maturity rather than hype, hype being just a minor issue. – CesarGon May 28 '12 at 13:43
  • 3
    @gnat: I don't deny DVCS' merit in that respect. But the Hype Cycle model assesses maturity plus expectations together; a technology may be quite mature, but if expectations about it are extremely high, it can still be disappointing (hence disillusionment). In my opinion, the expectations about DVCS have been way higher than what it has delivered. In addition, DVCS may have been used in Solaris and Java projects, but that does not mean that its maturity and expectations are balanced. Hence high hype. – CesarGon May 28 '12 at 18:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.