~bzr-pqm/bzr/bzr.dev

****************

Driving adoption

****************

 

Getting adoption means persuading people that it's a good choice.

 

 

I think the key is to have something that key project leaders see as

worth using.  Imagine what it would take to get tridge, havoc, or akpm

to switch.  Or not even to switch, but to even just try it out.

 

* Simple operations must be simple.

 

* The project and the implementation must not have bad smells.

 

* Given their current understanding of the problem, there must be at

  one feature that's clearly better than what they're currently

  using.

 

 

What holds it back now?

 

* Too complex on initial impression

 

* Bad smell from having so many forks/wrappers/kooky opinions

 

* Some of the more exotic features can only be appreciated on

  familiarity

 

* It doesn't actually achieve by default a lot of the advantages that

  it ought to: for example it still blocks on the network

 

 

Good features at the moment

 

* Archive storage is clean; probably makes a favorable impression on

  people who look at it

 

* Relatively few dependencies (if you don't look too closely at

  hackerlab, etc)

 

 

From `Ben Collins-Sussman`__

 

__ http://www.red-bean.com/sussman/svn-anti-fud.html

 

   If you're learning about Subversion and thinking of using it in

   your group or company, please approach it the way you'd approach

   any new product: with caution. This isn't to say that Subversion is

   unreliable... but that doesn't mean you shouldn't use some common

   sense either. Don't blindly jump into the deep end without a

   test-drive. No user wants a new product forced upon them, and if

   you're going to be responsible for administering the system, you

   better have some familiarity with it before rolling it out to

   everyone. Find a smallish project, and set it up as a "pilot" for

   Subversion. Ask for enthusiastic volunteers to test-drive the

   experiment. In the end, if Subversion turns out to be a good fit,

   you'll have much happier developers (who have been part of the

   process from the start) and you'll be ready to support a larger

   installation as well. [...]

 

   When Subversion hit "alpha" it was already being used by dozens of private developers and shops for real work. Any other project probably would have called the product "1.0" at that point, but we deliberately decided to delay that label as long as possible. Because we're talking managing people's irreplaceable data, the project was extremely conservative about labeling something 1.0. We were aware that many people were waiting for that label before using Subversion, and had very specific expectations about the meaning of that label. So we stuck to that standard. All it takes is one high-profile case of data loss to destroy an SCM's reputation.

 

 

`John S. Yates, Jr.`__:

 

__ http://lists.gnu.org/archive/html/gnu-arch-users/2004-10/msg00370.html

 

  First let me say that I have nothing but increasing respect for

  Tom's skills and accomplishments.

  

  That said I see Gnu Arch as really just emerging from a period

  of prototype development.  If the project really wants to take

  over the world, and especially supplant projects with momentum

  and commercial customers (e.g. Subversion, BitKeeper, etc) then

  I would warn against two mistakes I have experienced repeatedly

  in my career:

  

  1) Deferring to a tiny installed base instead of focusing on

     eliminating barriers to adoption

  

  2) Believing that great technology will be irresistible no matter

     how it is presented

  

  Appearances matter.  Expectations matter.  Standards (official

  or de facto) matter.

 

There is also a `reply from Tom`__.

 

__ http://lists.gnu.org/archive/html/gnu-arch-users/2004-10/msg00430.html

 

Clear wins

----------

 

To convince people to use Baz, there has to be some feature they can

clearly understand which will be much better under Baz.  It must be

something they do today.

 

* Offline support

 

* Almost no network delays

 

* Atomic changes (svn already has this)

 

* Correct repeated merges

 

* Read-only mirroring archives (not really important) 

 

My model is that people will consider changing if 

 

1. it's at least as good as cvs/svn

2. AND there are no big concerns about implementation/safety

3. AND there is at least one feature which is easy to use and a big win

 

This gets you to some people at least trying it.  Will people migrate

big projects to it?  Maybe, if it looks safe, it fixes there problem,

and it doesn't look like something substantially better is on the

horizon.