Subclipse Usage Report

In CollabNet’s role as the founder and corporate sponsor of the Apache Subversion project, we invest in a number of areas aimed at making Subversion as easy to use and adopt as possible. This summer saw the launch of our new CollabNet Subversion Edge product which makes it very easy to install, configure and manage your own Subversion server. This includes the ability to connect all of your Subversion Edge servers to our CollabNet TeamForge product and manage them all from a single user interface as well as delegate a subset of administration functions to project teams. Earlier this week we announced our acquisition of Codesion (formerly CVSDude), which offers best-in-class provisioning of Subversion in the cloud. The Codesion service allows you to code, connect and deploy in the cloud with just a couple of clicks.

These products and services are all focused on the server. We have also invested resources over the last several years to maintain and improve Subversion IDE client integrations. This allows us to make the developer experience with Subversion as simple, yet powerful, as possible. CollabNet leads and hosts the Subclipse project, which integrates SVN support into Eclipse-based IDE’s, and also the AnkhSVN project, which integrates SVN support into Microsoft Visual Studio. These open-source community-driven projects form the basis of our CollabNet Desktop products for Eclipse and Visual Studio, which add Agile ALM features to the IDE for users of our flagship enterprise ALM product — CollabNet TeamForge.

The focus of this post is really going to be on Subclipse. In the most recent version, 1.6.14, we have followed the lead of the JBoss Tools project and incorporated a usage reporting plugin into Subclipse that provides us with anonymous usage statistics via Google Analytics. This is an opt-in feature and I envision using the data we gather to help us drive future product management decisions. For example, we still produce all versions of Subclipse so that they run well on Eclipse 3.2 and Java 1.4. The statistics we are gathering will help us decide what the impact would be if we moved to newer versions to take advantage of newer Java and/or Eclipse features.

After only a week of availability we have already gathered a lot of data. We have over 82,000 unique opt-ins, which I think is impressive for one week. One thing it tells us is that users adopt new releases of Subclipse quickly. After seeing Ian Skerrett’s blog post on Eclipse.org traffic analysis, I thought I would share some of the information we have gathered so far. Based on statistics posted in the new Eclipse Marketplace, Subclipse is far and away the most widely used Eclipse plug-in. Hopefully by sharing some of the statistics we have gathered, we can help other Eclipse developers make decisions about their own plug-ins.

Operating Systems

1. Windows 68%
2. Linux 21%
3. OS X 11%

The OS breakdown was the most surprising to me. Based on forum traffic and blog posts, I expected the OSX and Linux numbers to be reversed and I even expected OS X to be a little closer to the Windows number, something like a 50/30/20 split. Clearly I was way off here, which is why it is good to gather real data and not simply make assumptions. By the way, Windows usage breaks down as 48% using Windows XP, 43% using Windows 7 and then Vista with most of the rest. We do not currently gather information on 32-bit vs. 64-bit.

Java Versions

The way we are currently collecting the data makes it hard to summarize this neatly. This is because we are collecting the exact Java version string (ex: 1.6.0_22) as opposed to something you would want to report on like “1.6”, “1.5” etc. Just eyeballing the data, it looks like over 90% of users are using Java 1.6, and less than 1% are using Java 1.4. For my purposes, that is probably all the information I need.

Eclipse Versions

This is even harder to report on than Java because we are collecting the primary product ID and then breaking that down by version. Here are the top-five products and their percentage of the total:

1. org.eclipse.epp.package.jee 33%
2. org.eclipse.sdk 16%
3. org.eclipse.epp.package.java 12%
4. org.eclipse.epp.package.php 6%
5. org.eclipse.platform 5%

There are a LOT more products (146 total) and you can see that the top-5 only accounts for 72% of the total, so I am not sure if it is wise to draw any conclusions from the current data. However, if you break down the Eclipse versions used by these five products it comes out like this:

1. Helios/3.6 63%
2. Ganymede/3.5 30%
3. Callisto/3.3 5%
4. Europa/3.4 1%
5. Eclipse 3.2 0.4%
6. Indigo/3.7 0.22%
7. Eclipse 4.0 0.07%

We will likely look for ways we can improve the usage reporting plugin to provide us with a more generalized Eclipse and Java version. This should make it easier to report the Eclipse version across all products, including the vendor IDE’s that might be based on the older Eclipse versions. That said, simply based on this subset of the current data, it seems reasonable to infer that most users are using the newer Eclipse versions.

Languages

Finally, here are the top-10 Java locales in use by Subclipse users. It is pretty easy to see that Eclipse and Subclipse are used worldwide. We have actually had 124 unique locales reported so far.

1. en-US 38%
2. zh-CN 12%
3. de-DE 7%
4. ko-KR 5%
5. fr-FR 4%
6. pt-BR 3%
7. en-GB 3%
8. ja-JP 3%
9. es-ES 3%
10. ru-RU 2%

Conclusion

Hopefully other members of the Eclipse community will find this data useful in some way. In the near term, the Subclipse project will maintain our current policy of supporting Eclipse 3.2 and Java 1.4. However we do have a change coming on the horizon. When the Subversion 1.7 release comes out, we have to update our minimum Java support to 1.5 because the Subversion project has moved the JavaHL API to that level and is exposing features like Generics and Enums in the public API. From the data collected so far, it looks like this will not impact our existing user base too severely so I feel a little more comfortable about this change then I had previously. I think we will continue to support Eclipse 3.2 through the next release of Subversion, but it seems that we could get away with moving to Eclipse 3.3 as a minimum if needed. That said, I would rather wait until we figure out a better way to collect the data and account for the other 28% of installations I did not include here. Truthfully, the Eclipse API has been stable enough for us that we have not had too many compelling reasons to drop support for Eclipse 3.2 and unless we decided to move all the way to something like Eclipse 3.5, I am not sure we would receive much value as developers in updating our minimum supported version.

Mark Phippard

Engineering manager for several teams at CollabNet, including CloudForge, Subversion, Subversion Edge, Git and our Desktops and Integrations. Project owner for the Subclipse project, which provides Subversion support in Eclipse. Also a full committer for the Subversion project. Product owner for GitEye, Subversion Edge and the CollabNet Desktops and Integrations.

Posted in Subversion
2 comments on “Subclipse Usage Report
  1. Steve Elsemore says:

    I was surprised by those breakdowns too.
    It seems that one thing to keep in mind is that the only data we have so far is from the people who jumped right on getting the latest Subclipse. This might skew the numbers since these are likely to be mostly the same people who are not afraid to jump right on adopting the latest Java/Eclipse.
    I wonder if there’s a similar explanation for the surprising % of Linux users in relation to the forum traffic. Maybe Linux users tend to be among the more adventurous who like to figure things out for themselves if at all possible?
    But it’s encouraging to me because I can’t wait to be able to leave Java 1.4 and Eclipse 3.2 behind us.

  2. Steve,
    Those are very good points. Even though we have accumulated a lot of data, you are correct that the data might be skewed towards early adopters. It will be interesting to see if the data changes over time. Fortunately we are in a position where we are not in dire need to draw any conclusions at this time. I will try to post a blog update around end of year. At current rate, we should have well over 1 million unique opt-ins by that time. It seems like that would be enough data to be statistically relevant.

Leave a Reply

Your email address will not be published. Required fields are marked *

*