Subversion is not Dead

I often see posts on hacker news or proggit exclaiming how Subversion is dead and should not be used by anyone anymore. I do not agree with this but not for the reasons you might think.

Before I get to the reasons why Subversion will still be around for many years to come, let me rant about the anti-subversion movement…

Anti-Subversion Rant

I have a hard time when people lump CVS and Subversion into the same group. Subversion is vastly superior to CVS in almost every way. After working with CVS for a few years, Subversion was a breath of fresh air. People seem to forget that these days. True, distributed version control systems may equally be a leap forward above Subversion but that does not discount what Subversion did right.

When using Subversion with a small team, the merging and branching issues are not usually a problem. For commercial end user software, it has some benefits. For most commercial software, a centralized model for source control is beneficial. I love how the subversion revision number works. At my company we use it to identify the build. It works well to identify exactly what version a customer may be running. Git’s 40 character ID simply cannot be used in this way.

Subversion does have some things going for it especially when you intend to impose a centralized model anyway. Distinct product versions (1.0, 1.1, 2.0, etc) lend itself to this model. If you think about it, this is how commercial software always used to be. Web based products and continuous deployment kind of changed this which is why I think we have changed the way we do version control.

I still do think that DVCS is the way to go and will be the future of version control. I am currently looking into how to easily transition from Subversion to Git for our core product source control (using git+svn). I think the benefits out weight the few nice things we will lose. That is a topic for another post though.

Why Subversion will never Die

Now for the real reason Subversion will not die in the foreseeable future (particularly in the enterprise world). The real reason is the licensing. Consider licensing of Subversion. Subversion is licensed under the Apache license. The apache license is very commercial friendly as I’ve written here previously.

Alternatively consider the licensing of the various distributed version control systems:

  • Git – GPLv2
  • Mercurial – GPLv2+
  • Bazaar – GPLv2
  • Darcs – GPL

Notice a trend?

I totally understand why this is the case. The communities around these products want to protect from commercial companies who will fork these products, enhance them and not provide source for these changes. Typically if this was a client-server type model, it may be acceptable to have the core server licensed under GPL and have a library for accessing it under the LGPL. This would allow commercial offerings to freely build clients to these tools.

That simply cannot work here. Because of the nature of distributed version control systems, each user has their own repository. This means all of the magic that goes into providing a version control system lives as part of the client the user accesses. Licensing this under a commercial friendly license essentially provides that to the whole product. You cannot separate the ‘client’ from the ‘server’ in a distributed version control system as they are one and the same.

Perhaps it is easier to consider a case of this in action.

Embedded Version Control Support

Consider the popular text editor for Mac OS, Textmate. First a disclaimer, I am in no way involved in textmate and am just using it as a plausible example of the problem.

Textmate provides source control access within their editor to Subversion. They created a Java library called SVNKit for this purpose. I’ve actually used this in a product to provide subversion access from Java.

If you look at Textmate’s feature list, you will notice that they do not offer support for Git, Mercurial or any of the other GPL-DVCSs. They do have extensions for these but they cannot bundle support for it like they can with their SVNKit library.

The products I work on are in a similar state. We are excluded from providing Git or Mercurial support in our product due to the licensing. It may be possible to provide this as a plugin or extension that only drives the command line. Though technically possible, many of our enterprise customers would have issues accepting this especially when they have to download and install the GPLed version control software themselves.

Conclusions

As long as the distributed version control systems stick with the GPL license, they will be in exile from many enterprise environments. Perhaps some day we will have an alternative distributed version control system under the apache license. Until then, Subversion will continue to exist in the enterprise. Especially now with the community at Apache, Subversion will continue to grow and evolve for many years to come.

6 thoughts on “Subversion is not Dead”

  1. You can bundle GPL software in a commercial product, you just have to provide the sources of the free software program (not of your unfree software which you just distribute along with it) – which is dead simple in the case of Mercurial πŸ™‚

    You just can’t link against it with unfree software, but you *can* use the commandline API (both the main stable interface of Mercurial and of Git).

    Besides: As far as I know, Bazaar is GPLv3.

    And Bitkeeper is not GPL. Bitkeeper not being free (and actively restricting the kernel devs) was the reason, git and Mercurial were created.

  2. @Arne Yes, there are ways to bundle GPL software with a commercial offering. The issue is more with enterprise customers. Many big firms look at GPL as a liability and have blanket policies that they will not accept any GPL software. Their reasons may be unjustified but it does not change the fact that they will not purchase your software if you use GPL. You have no choice but to comply if you want their business.

    This becomes even more of a problem for the OEM market. We have OEM partners who resell our software. The list of supported licenses for this is even more restrictive. Some of our OEM partners will not accept LGPL either. Their reasons are probably not justified but their legal departments refuse to budge on this.

    GPL is bad for political reasons more so than for technical ones.

Comments are closed.