We were happily surprised by this blog post from Rob Knight “Comparison of Maven Artifact Repositories”*. Here’s his intro:
“In the team I work for, we support up to 200-300 developers at any one time. We currently use Apache Archiva. This has served us well for a number of years, but due to various ongoing maintenance issues (many not related to Archiva itself), we decided to research the possibilities of switching to a newer repository system.”
Knight continues to outline a set of objective criteria for his evaluation procedure. He lists a series of features alongside a weight which will later inform a numerical evaluation of each feature. The end result of his comparison effort is in a table here (the higher the score, the better he rates the product): http://rob-knight.co.uk/nextgenrepoMOSCOW.htm
His conclusion? “The competition was close, but clearly the Nexus products succeeds in the majority of our requirements (except costing).” Even with the caveat about the cost, we’ll take it.
Oh, “That” Product Comparison Matrix
At one point he mentions that the product comparison matrix at Codehaus is useful. We’re not big fans of that particular comparison matrix. I get an alert every time it changes, and I’m constantly seeing a stream of new line-items designed to feature something only contained in the competing product. Very often someone will update the chart and add something that is blatantly incorrect. I’ve also had to place disclaimers in the Nexus column because our product does come with some opinions – “Nexus doesn’t allow you to modify artifacts because we don’t want to break PGP signatures.” or “Nexus doesn’t copy artifacts between release repositories because doing so leads to problems of consistency.” Simple check marks also don’t capture important nuanced differences: especially when it comes to approaches to caching LDAP credentials.
Maybe it is just my own personal style, but product comparison datasheets are not a great place for competitors. They end up being “tit for tat”, and it turns the buying process into a “used car showroom” experience where the differences between models are distilled down into misleading checkmarks designed to upsell. Still, it isn’t like we can just let the chart go, some people find it valuable despite our misgivings. Wouldn’t it be great if someone generated an objective set of features and rankings?
And, that is just what Rob Knight did (for his own set of requirements). Take a look at Knight’s comparison chart. Of course, we think it’s a good comparison, but judge the information for yourself. What’s interesting to me is that Nexus OSS qualified for the comparison and had a pretty impressive showing coming it at #2 to Nexus Pro’s #1 spot.
We compete with ourselves, that’s the reality of an OSS Company
We’ve always been committed to supporting Nexus OSS, even to the point where people in the business have asked us if Nexus OSS competes with Nexus Pro. It does, and every company based on OSS has the same problem. Our OSS product is production quality, there no reason why you couldn’t run it to support your development team. Yes, we can provide you with many reasons to upgrade to Pro, but Knight’s comparison gives you something we can’t – an objective third-party analysis of the differences between Nexus OSS and Nexus Pro.
This is where I’m focused, I’m not interested in the differences that Knight noted between Nexus and it’s competitor. I’m focused on the differences between Nexus OSS and Nexus Pro because it tells me where I need to focus to draw a greater distinction between the two.
* Note: Only one minor reaction, Nexus isn’t a Maven artifact repository. While we may have called it that at some point in the past, we have a large customer base that uses Nexus for Gradle, Ivy, Yum, .NET, OSGi, and a host of other technologies in addition to Maven.