Q&A With BCW Magazine

Here’s an interview I gave with Business Computing World (http://www.businesscomputingworld.co.uk/qa-david-richard-wandisco/)

Can you position SCM and SCCM technologies as you see them in relation to ALM in the wider sense?

WANdisco’s heritage is in distributed computing—our technology enables active-active replication over a wide area network. The first application we implemented this with was Apache Subversion to create Subversion MultiSite (a distributed, highly available and scalable Subversion implementation).

Over the past couple of years we have become a very active participant on the Apache Subversion open source project and we are keen to ensure that Apache Subversion maintains its position as what we consider to be the world’s leading SCM tool.

Recently we announced uberSVN an open ALM platform for Subversion. The uberSVN platform is a very easy to use, easy to implement and easy to extend inside a distribution of Subversion. We see SCM as a core component of ALM—it’s where the source code files are stored. So transforming Subversion into a platform that enables you to choose best-of-breed ALM components is a very natural and evolutionary step for us. We don’t believe that any single vendor can provide a complete, best-of-breed ALM solution.

Why would a firm choose Subversion over traditional SCM solutions such as Perforce, Serena or even products from HP?

I guess a better question would be “Why do firms choose or replace traditional SCM solutions with Subversion?” I guess this is because Subversion is open source and hence free, but it performs and scales in some of the most aggressive SCM environments on the planet where some of the traditional SCM products could not. Subversion now has over five millions implementations—how many do the traditional SCM’s have? Not even a fraction of that and that means Subversion must perform and scale in a huge amount of environments.

It sounds like WANdisco’s core technology could be applied across multiple applications. Are you looking at other areas?

Indeed our replication technology is generic and can be applied to other areas. Relational databases is one area we are investigating in our labs right now. Maybe next year we will be in a position to announce something more concrete around database replication/shared-nothing database clustering.

Is WANdisco actively supporting the development of Subversion?

WANdisco is a huge supporter of the Apache Subversion open source project in a number of tangible ways. We have dedicated committers on staff that we pay to only develop Subversion, we are a sponsor of the Apache software foundation and we produce Subversion binary downloads and make them freely available on our website. There was some controversy last year but that was ‘rabble-rousing’ by one of our competitors. The end result is that Subversion development on the open source project is very active again. There is a lot of energy on the project right now and that is good for the wider community.

Are there any clear trends in the SCM space?

Subversion is continuing to gain adoption in the enterprise and government organisations. That’s probably not entirely surprising given that, in product lifecycle parlance, Subversion is in maturity. As I said earlier it continues to replace traditional SCM solutions. I would also say that Microsoft’s Team Foundation Server (TFS) is also gaining traction and is probably in the number two position. We don’t see enterprises moving their source code to the cloud yet. That may change but we have see some of the tooling move there—just not the source code.

What’s the uptake been like for uberSVN?

I’d say things are looking healthy, we have thousands of installs in just over a month and the feedback has been very good. I have never seen so many product installs and that is a good sign that the product is very easy to install. We worked very hard to get a product that could be installed in less than five minutes and we will never trade that off for anything.

Are there any big announcements scheduled for uberSVN?

In July we are planning a major new product feature that will enable customers to very easily install third party applications. It’s a really cool feature that will change the way ALM software is delivered behind the firewall. We also have some partner announcements around software build and quality tools.

Is GIT a threat to Subversion?

Funny, I was talking about this only today with an industry analyst and he has the same conclusion that we have. Git has its uses but probably not in the enterprise. OK please listen, I know that statement will upset a bunch of senior developers who think that GIT solves everything but it really doesn’t.

If you think about it GIT actually promotes anti-social software development; development in small, disconnected silos is not how software is developed in the real world. Most software is developed by teams whose members have a variety of skills who need to see what each other is doing and that’s the fundamental reason why GIT is not a threat to Subversion in the enterprise. It’s fine for the development of the Linux kernel but that model doesn’t work for most companies.


About David Richards

David is CEO, President and co-founder of WANdisco and has quickly established WANdisco as one of the world’s most promising technology companies. Since co-founding the company in Silicon Valley in 2005, David has led WANdisco on a course for rapid international expansion, opening offices in the UK, Japan and China. David spearheaded the acquisition of Altostor, which accelerated the development of WANdisco’s first products for the Big Data market. The majority of WANdisco’s core technology is now produced out of the company’s flourishing software development base in David’s hometown of Sheffield, England and in Belfast, Northern Ireland. David has become recognised as a champion of British technology and entrepreneurship. In 2012, he led WANdisco to a hugely successful listing on London Stock Exchange (WAND:LSE), raising over £24m to drive business growth. With over 15 years' executive experience in the software industry, David sits on a number of advisory and executive boards of Silicon Valley start-up ventures. A passionate advocate of entrepreneurship, he has established many successful start-up companies in Enterprise Software and is recognised as an industry leader in Enterprise Application Integration and its standards. David is a frequent commentator on a range of business and technology issues, appearing regularly on Bloomberg and CNBC. Profiles of David have appeared in a range of leading publications including the Financial Times, The Daily Telegraph and the Daily Mail. Specialties:IPO's, Startups, Entrepreneurship, CEO, Visionary, Investor, ceo, board member, advisor, venture capital, offshore development, financing, M&A

25 Responses to “Q&A With BCW Magazine”

  • That wasn’t a very objective statement about Git. I can agree upon that Git is much better suited for open source projects of all scales, everything from the linux kernel to smaller projects. However, on the enterprise side I’m sure that it all depends on the developers, as much as it does with subversion.

  • It’s funny, how all the arguments against Git and Mercurial in favour of Subversion and TFS boil down to “These are the problems that you *might* encounter with DVCS *if you don’t* use it correctly.” On the other hand, the argument that we DVCS users make is, “These are the problems that you *are* encountering with centralised tools *because you can’t* use them correctly.”

    Git doesn’t promote anti-social software development any more than Subversion does. What Git does promote is much more fine-grained check-ins that are easier to describe and easier to understand. A merge between branches in git/hg is roughly equivalent in your workflow to an update/commit in Subversion. It also gives you the concept of source control as a project-wide, persistent undo button with offline commits and local history, and that is *very* useful.

    In fact, the equivalent problem in Subversion and TFS is a lot worse: delaying check-in till you have a completed unit of work. This results in huge, bloated commits that are difficult to understand and review, and to make matters worse, if you run svn update and get into a mess trying to resolve the conflicts, you can’t cleanly roll back to what you had before and will have to start over from scratch, losing hours of work.

  • Imma go ahead and say it. You don’t know shit.

  • This is an offbeat perspective. GIT is preferred over Subversion in the corporate environments I’ve been in for purely technical reasons. I’ve not encountered any social differences in actual use between the two in business.

  • Git, or git – never GIT.

  • “If you think about it GIT actually promotes anti-social software development”

    I call FUD because git “promotes” no such thing. Sure it can facilitate it but tracking changes privately is better than not tracking changes at all which is the only option with subversion.

    If you’re worried about your developers being anti-social perhaps you need new developers because your choice of SCM is not going to prevent them from keeping changes to themselves.

  • It is called “git” not “GIT”.

  • Mike – I disagree. Choice of SCM can and does influence level of collaboration. DVCSs actively promote an offline mode and consequently infrequent commits whereas centralized models do not. This is not a valid model for a development team that may run into thousands of users in multiple locations. Show me a git reference deployment in enterprise of >10,000 users (who by implication have a ariety of skills) and I will revise my view. I can show you many, many SVN deployments of that nature….

  • As I said earlier show me a deployment in a very large enterprise team and i will revise my view. I can show you loads of SVN deployments (some > 40,000 users)

  • James, Thank you for the constructive response. You say “Oh, and by the way, there are plenty of success stories of DVCS in the enterprise.” can you please refer tome one of significant size? You see the elephant in the room here is that Git is way too complex for many. I was talking to a Math grad from Harvard a couple of weeks ago who’s in this business and he can’t store the mental model of Git in his brain. Enterprise dev teams have a wide variance of users that need to work together.

  • Thank you for this wonderful insight.

  • You simple say “Git doesn’t promote anti-social software development” but fail to explain how and then revert to criticize Subversion…

  • “DVCSs actively promote an offline mode and consequently infrequent commits…”

    DVCSs actively promote no such thing. DVCSs actively promote *more* frequent, fine-grained check-ins — it’s common for DVCS users to check in locally several times an hour and still integrate (merge) daily or more frequently. On the other hand, the centralised model, where everyone is doing everything in trunk, forces you to choose between integrating immature work and making huge, bloated commits.

  • Another thing…

    What does the size and scale of deployment have to do with the claim that Git promotes anti-social software development?

  • You obviously understand nothing about Git or how it works. While you do have a complete local copy of a repo, this does not encourage one to nopt push changes to the upstream repo anymore than SVN does. This is solely a work flow issue.

    Git can simplify the upstream repo by cutting down on the number of commits per feature or bug fix. This is accomplished utilizing interactive rebasing and squashing. Thus, a feature or bug fix is a single commit. It is much easier to wrap you brain around a single commit than multiple commits (w/ small steps in a feature).

    In addition, if you need some changes that a colleague has made on his or her feature branch, they can push the branch to the upstream repo and you can pull it and rebase to it in order to get their changes.

    I suggest you use a tool to its fullest potential before making an assessment such as this. Every enterprise I have worked in for the past 3 years is using it. It sounds like your ‘enterprise’ is one of the only ones not.

  • James – 2 separate points.

    Git promotes anti-social behavior because of its model.

    This model is not suitable for a large enterprise deployment with a cross-section of skills.

  • Jason – why is the first thing out of a Git-fundamentalists mouth always abuse and something along the lines of “you don’t know what you’re talking about”?

    You have done what you guys always do and refuse to think beyond what is good for just you / your work style and assume that the whole world should adopt this overly-complex, anti-social, disconnected model.

  • “Show me a git reference deployment in enterprise of >10,000 users (who by implication have a ariety of skills) and I will revise my view”

    What i know Android is on Git, and is picked up by Samsung, Sony Ericsson, LG, Google id say those are enterprise company’s all of them.

  • None of those companies (that you claim) have deployed git for enterprise software development… Google use Perforce for a start. Sony Ericsson were a big IBM shop last time I checked.

    See this article from Wired about Google and others getting their source hacked: http://www.wired.com/threatlevel/2010/03/source-code-hacks/

  • Precisely. We may be “Git fundamentalists,” but at least we are speaking from experience, not from conjecture. The reason why we say “you don’t know what you’re talking about” is because you are *describing us* in ways that we *know from experience* to be not only totally detached from reality, but also quite uncomplimentary.

    Besides, I think the discussion about the size of organisations deploying Git or Mercurial is getting a bit off-topic here. The issue at stake is the unsubstantiated assertion that Git promotes anti-social software development processes — which, as I said, is simply not the case.

  • we use git with gitosis and all pull/push from/to a central repository. So, it just comes down to how your software development process works really, git doesn’t enforce anything. Git does make branching very easy, that’s the main reason why we use it. But in the end, everything will be merged/pushed into our central development/staging/production branches (which are also linked to a real environment).

  • Asumming 10,000+ users of the enterprise company, a fair number of developers are not smart enough to use the git.

    Believe me, it’s true.
    I’m working at one of those companies.

  • I remember the first days of OO and C++ when the world was using C. git is complex and offers many workflows that svn does not. It is the same thing – takes time for new concepts to be part of the daily fabric. Until then, the two can co-exist. We routinely switch to git (thanks to git svn) when we know we want a complex workflow. We find some developers becoming converts.

  • Incidentally, here’s a Stack Overflow post from someone who has successfully introduced Git at a “large banking company.” He gives details of the problems that he encountered in an enterprise organisation and how he overcame them.


    Interesting point: there *are* a few minor challenges to DVCS in an enterprise environment, but they are not the ones that centralised source control users expect, and they are not insurmountable.

    @dorado2: Have your users tried Mercurial? It’s much more newbie-friendly than Git (most people I’ve introduced it to have managed to grok it straight away), albeit at the expense of being a bit less fluent for expert users. Git does some things by default (e.g. automatically merging and committing when you pull, or fast-forward merges) that make perfect sense when you understand them, but can be confusing and intimidating to inexperienced users.

  • > Asumming 10,000+ users of the enterprise company, a
    > fair number of developers are not smart enough to use
    > the git.

    Which, in turns, means that git should not be used in this kind of setup. And I’m pretty sure you were trying to say that you’re more clever than many because you are using the git.

    Regarding the git vs. svn debate, I don’t understand anything about the argument. You can do small, easy to explain commits and branch manipulation with both. The cleverness of git do not lie in its list of functionnality, but in the way branches are pulled and pushed (ok, add bisect, because bisect is very nice). But then, you can achieve a similar workflow with svn – at a greater expense (I know at least one company where svn is used in a very similar way).

    Really, this git vs. svn debate sounds like the old svn vs. cvs debate (BTW, dear host, you should know that svn is taking the same way as cvs ; I’m not saying that svn is not technically superior to cvs, or that is is technically inferior to the git or hg ; just that DSI are more and more aware of these younger alternatives, and they slowly – but surely – phase out svn, which is viewed as a rock-solid but painfull (wrt branch manipulation) SCMS).

    Best regards,

    — Emmanuel

Leave a Reply