How to leverage social proof?
How can one use social proof as an argument without sounding like "just because everybody is doing it so should you"?. My problem is trying to demonstrate with social proof that trendy tools/techniques are not necessarily cargo cult
I'm writing a whitepaper regarding best-practices and new tools in the industry of software engineering. There are certain controversial topics like DVCS (Distributed Version Control) and TDD (Test-Driven Development) that do work, but require changing mindsets and extra effort at the beginning to reap the rewards. Something along the lines of this:
More and more developers are being converted into DVCSs because of its success in overcoming classical frustrations in CVCSs, such as avoiding merging hell and commit races. Adoption involves evolving the centralized mindset as DVCSs change the paradigm of version control, after developers accept the new paradigm and embrace it —which generally involves trying to go back to the centralized mindset— they will start reaping the benefits and become increasingly aware of how scalable this paradigm is in terms of collaboration.
Even if the previous paragraph sounds credible, I don't think people resistant to change will see another thing from "oh, it's cargo-cult". I think social proof is relevant to this case (as adoption is important to the enterprise due to support professional support markets & well-tested environments), but cannot help to think that this could get on the bad side of rhetoric (too much pathos?).
Since those kinds of things are being increasingly adopted and preached, how could one turn this situation as a good convincing argument?. I was reading Joel's entry on demonstrating software and social proof but it seems like a double-edged sword.
Additional context: VCS or Version Control Systems are (in a nutshell) programs that let you store incremental differences (or changes/deltas) to text files so that then you can rebuild them at a particular point later; these systems are mostly use for writing software.
There are currently two models: a) the centralized one (CVCS) where each user to be hooked up to a server to use these systems, making them slower and bottlenecking collaboration, as everyone needs to stand in line to store the changes to this sole "code bucket", and b) the distributed model (DVCS) where each programmer has their own "bucket", so there is no need for a server, everyone puts their work on their own "bucket".
The important thing in DVCSs and collaboration happens after, until they have finished and refined work to share and be proud about instead of stepping on each other's toes with incomplete work (and still being able to rely on version control to aid their own work). In a DVCS each peer can check each other's buckets and they can add their bucket's contents to others' too.
P.S.: Sorry for the wall of text