~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/adoption.txt

  • Committer: Robert Collins
  • Date: 2006-06-16 15:59:24 UTC
  • mto: (1780.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 1781.
  • Revision ID: robertc@robertcollins.net-20060616155924-b8a6591d32f8ab20
New corner case from John Meinel, showing up the need to check the directory lexographically outside of a single tree's root. Fixed.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
****************
2
 
Driving adoption
3
 
****************
4
 
 
5
 
Getting adoption means persuading people that it's a good choice.
6
 
 
7
 
 
8
 
I think the key is to have something that key project leaders see as
9
 
worth using.  Imagine what it would take to get tridge, havoc, or akpm
10
 
to switch.  Or not even to switch, but to even just try it out.
11
 
 
12
 
* Simple operations must be simple.
13
 
 
14
 
* The project and the implementation must not have bad smells.
15
 
 
16
 
* Given their current understanding of the problem, there must be at
17
 
  one feature that's clearly better than what they're currently
18
 
  using.
19
 
 
20
 
 
21
 
What holds it back now?
22
 
 
23
 
* Too complex on initial impression
24
 
 
25
 
* Bad smell from having so many forks/wrappers/kooky opinions
26
 
 
27
 
* Some of the more exotic features can only be appreciated on
28
 
  familiarity
29
 
 
30
 
* It doesn't actually achieve by default a lot of the advantages that
31
 
  it ought to: for example it still blocks on the network
32
 
 
33
 
 
34
 
Good features at the moment
35
 
 
36
 
* Archive storage is clean; probably makes a favorable impression on
37
 
  people who look at it
38
 
 
39
 
* Relatively few dependencies (if you don't look too closely at
40
 
  hackerlab, etc)
41
 
 
42
 
 
43
 
From `Ben Collins-Sussman`__
44
 
 
45
 
__ http://www.red-bean.com/sussman/svn-anti-fud.html
46
 
 
47
 
   If you're learning about Subversion and thinking of using it in
48
 
   your group or company, please approach it the way you'd approach
49
 
   any new product: with caution. This isn't to say that Subversion is
50
 
   unreliable... but that doesn't mean you shouldn't use some common
51
 
   sense either. Don't blindly jump into the deep end without a
52
 
   test-drive. No user wants a new product forced upon them, and if
53
 
   you're going to be responsible for administering the system, you
54
 
   better have some familiarity with it before rolling it out to
55
 
   everyone. Find a smallish project, and set it up as a "pilot" for
56
 
   Subversion. Ask for enthusiastic volunteers to test-drive the
57
 
   experiment. In the end, if Subversion turns out to be a good fit,
58
 
   you'll have much happier developers (who have been part of the
59
 
   process from the start) and you'll be ready to support a larger
60
 
   installation as well. [...]
61
 
 
62
 
   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.
63
 
 
64
 
 
65
 
`John S. Yates, Jr.`__:
66
 
 
67
 
__ http://lists.gnu.org/archive/html/gnu-arch-users/2004-10/msg00370.html
68
 
 
69
 
  First let me say that I have nothing but increasing respect for
70
 
  Tom's skills and accomplishments.
71
 
  
72
 
  That said I see Gnu Arch as really just emerging from a period
73
 
  of prototype development.  If the project really wants to take
74
 
  over the world, and especially supplant projects with momentum
75
 
  and commercial customers (e.g. Subversion, BitKeeper, etc) then
76
 
  I would warn against two mistakes I have experienced repeatedly
77
 
  in my career:
78
 
  
79
 
  1) Deferring to a tiny installed base instead of focusing on
80
 
     eliminating barriers to adoption
81
 
  
82
 
  2) Believing that great technology will be irresistible no matter
83
 
     how it is presented
84
 
  
85
 
  Appearances matter.  Expectations matter.  Standards (official
86
 
  or de facto) matter.
87
 
 
88
 
There is also a `reply from Tom`__.
89
 
 
90
 
__ http://lists.gnu.org/archive/html/gnu-arch-users/2004-10/msg00430.html
91
 
 
92
 
Clear wins
93
 
----------
94
 
 
95
 
To convince people to use Baz, there has to be some feature they can
96
 
clearly understand which will be much better under Baz.  It must be
97
 
something they do today.
98
 
 
99
 
* Offline support
100
 
 
101
 
* Almost no network delays
102
 
 
103
 
* Atomic changes (svn already has this)
104
 
 
105
 
* Correct repeated merges
106
 
 
107
 
* Read-only mirroring archives (not really important) 
108
 
 
109
 
My model is that people will consider changing if 
110
 
 
111
 
1. it's at least as good as cvs/svn
112
 
2. AND there are no big concerns about implementation/safety
113
 
3. AND there is at least one feature which is easy to use and a big win
114
 
 
115
 
This gets you to some people at least trying it.  Will people migrate
116
 
big projects to it?  Maybe, if it looks safe, it fixes there problem,
117
 
and it doesn't look like something substantially better is on the
118
 
horizon.