This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
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.
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.
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.
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:
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:
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.
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.
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.