[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: How to get the message out (or: why there were only 6 people at the ApacheCon meetup)

From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Mon, 22 Nov 2010 15:09:55 -0000

> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: 09 November 2010 16:42
> To: Hyrum K. Wright
> Cc: Bolstridge, Andrew; Subversion Development
> Subject: Re: How to get the message out (or: why there were only 6 people
> at the ApacheCon meetup)
> On 11/09/2010 10:35 AM, Hyrum K. Wright wrote:
> > On Mon, Nov 8, 2010 at 9:39 AM, Bolstridge, Andrew
> > <andy.bolstridge_at_intergraph.com> wrote:
> >> I'm sure evangelical missions are still important - mainly to counter
> >> the "SVN is crap at merging, Mercurial/Git/a.n.otherDVCS is the
> >> ultimate SCM that fixes all your problems" type arguments that seems
> >> to be increasingly popular. Even our Serena dimensions admin
> >> (terrible 'enterprisey' ALM SCM) knows about git but doesn't know
> >> what SVN'd give him.
> >>
> >> So, I'd say there are still loads of poor souls needing the word
> >> bringing to them, and the FUD dispelling.
> >
> > Then aside from cold-calling all potential proselytes, what venues are
> > the best places at which to talk to folks? Are there ALM or SCM or
> > other types of conferences with which an evening Subversion event
> > would work well?
> >
> > (Or is this type of thing better left to marketing departments instead
> > of us technical peeps?)
> I think some of this starts with Subversion supporters being more vocal. Do
> we actually believe that "SVN is crap at merging,
> Mercurial/Git/a.n.otherDVCS is the ultimate SCM that fixes all your
> problems" is FUD? If so, we should be calling it out as such. This is not a
> battle for Marketing departments to wage, because the folks that need to
> hear the message don't care one lick for the latest output from those folks.
> (Honestly, when was the last time any of us got excited about some new
> technical thing because we read a press release about it?)
> Subversion didn't land on a bunch of CTOs' desks and get implemented as a
> corporate mandate. It took root with individual users who are more
> attentive to Slashdot-like buzz than press releases; folks who are more likely
> to try something based on their buddies' recommendations than on what has
> the slickest booth at a trade show. DVCS will infiltrate the current Subversion
> base in exactly the same way. If we seek to defend Subversion's relevance
> and utility, we'll have to do so in a technical communications ground war.
> And we'll have to do so while continuing to innovate and improve the
> software itself, closing down those pain points that cause our users to have
> wandering eyes in the first place.

I'm sure you've seen this:
and the link to http://hginit.com/ that he wrote to evangelise mercurial (over svn. The links are both basically saying 'look how much better hg is over svn, even when his merging tutorial is pretty much exactly what I'd do with svn!)
*This* is what I mean by FUD.

Martin Fowler redresses the balance, but in a matter-of-fact way: http://martinfowler.com/bliki/VersionControlTools.html

In fact, he gives 3 reasons to use a DVCS:
        Faster operations on history, because you have a copy of the entire repo, you can see a log quickly. Perhaps this can be solved in SVN by downloading more of the metadata (eg log) in much the same way as the last revision is stored locally to give you fast diffs.
        Better management of branches - in particular, much easier to branch, work, then delete the branch as if it never was. This is analogous to developer branches in SVN, but that never show up to others - SVN can get very full of branches (and tags!) if you let it.
        local development that can be committed at a later time, eg you can 'commit' even without a network.

        He doesn’t include merging, which is something that everyone says is so simple and easy in a DVCS compared to "the pain that is SVN". I treat this as FUD, though usability of merging is something that could be better (as always) and tree-conflicts need to be dealt with better. I think that an enhancement such as merging 1 change to multiple branches would be truly special for a corporate who often has legacy versions to maintain.

> Interestingly (to me, at least), while the typical corporate user is happy to
> absorb recommendations from the blogosphere and pull those into their
> corporate environments, they are absolutely *horrific* at communicating
> back *outward*. Here is where the corporate sponsors of this project still
> have a crucial communications role to play. As the primary liaisons with that
> whole (very large) class of user, it's important that companies such as
> CollabNet and elego and WANdisco and [[insert your company here if you
> depend on Subversion, too!]] continue providing this community with insight
> into the reasons why DVCS is getting a foothold in the corporate
> environment as well as with the resources to do something about it.

I'll tell you that I introduced SVN into our company 2 years ago after evaluating it and a few others. Since then its migrated across the other regions and soon even our HQ in the USA will be adopting it. There have been issues (not in the regions who are happy with it, but in the US) - many of the ground-level users wanted to use something else. I'm not sure why, but there appears to be a push to use anything but. Perforce is used by one group, and the group that's now migrating to SVN tried to get Mercurial in instead. I won't speculate why, but the fact that they didn’t embrace it directly is telling. I think it has something to do with the advertising DVCSs are getting.

I know the appeal of DVCS is that you get to work on the entire repo as if you were the only developer, occasionally fetching changesets from others but basically (appearing to be) working on your own. That's diametrically opposite to the corporate appeal of SVN. If we want to 'market' SVN, do we want to emphasise this difference, or try to appeal to everyone equally?

To appeal to corporate manager types, I would like to see the main SVN website include links to all the addon ecosystem. Stuff like WanDisco, Teamforge, Polarion, etc. If I was pitching SVN to my boss, he'd want to know how it manages things like requirement traceability matrixes and change configuration control, stuff that SVN doesn't do... but is such a good platform to have these value-add extras put on top, even if they do cost $2k a seat. Perhaps this is more a Collabnet thing, but it might be difficult for them to advertise competing products.

Anyway, there's my ideas/experiences with corporate SVN. Getting the word out means making sure corporates know SVN is available, is commercially supported, and is very stable. Many managers have an antipathy towards open source so instinctively will seek out expensive (and often inferior) products. One suggested way of getting to them would be case studies - everyone feels warm and fuzzy when hearing about how someone else took the risk on, allowing you to reap the gains that are described. Statistics are good to - programmer productivity and morale are good, as are cost savings type stuff, but again, I think all the above is more the kind of thing Collabnet should be putting out. That you can get the same stuff for free is just a benefit for the clued-up dev types :)

Received on 2010-11-22 16:10:40 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.