Spiceworks 3.5 – Plugins, More Devices, More Channels

RedMonk client Spiceworks rev’ed their software today, releasing version 3.5. See release notes here and a overview post here. Their IT management is still solidly focused around providing a free, attention-channel (ads and more) support platform for doing basic asset inventorying and monitoring. Over the past major releases, they’ve been expanding the functionality with things like a help-desk, reports, and diagnostic tools built into or cross-launched from their tool.

I’ve covered Spiceworks extensively in the past (see here, here, here, and here as some examples), so I won’t do too much more overviewing on them. On to the new items.

To summarize the general theme of the items, I’d say they’re most of them are around catering to the higher-end and “power user” part of the Spiceworks community. It’s all about more devices, customizing reports, integrating with other tools, a plugin framework, and the other types of things you’d expect from a platform with a bigger shoe size.

More Devices: from 250 to 500

Servicing the small end of the market (the “S” in “SMB”), Spiceworks has long supported just 250 devices. Devices are computers, printers, routers: anything with an IP address. While that may seem small for IT management wonks with their head in the enterprise space, it’s actually just fine for Spiceworks base: small shops without dedicated IT people or budget.

That said, there are more “serious” users in the Spiceworks community, usually the one IT staff for a smallish business or branch office. I meet several of them at Spiceworks’ recent, first user conference Spiceworld last Fall. When I spoke with Spiceworks’ Jay Hallberg a couple week ago about 3.5, he told me that they have over 20,000 (out of 500,000 or so) installs that are using ,more than 250 devices. That’s a nice enough number that Spiceworks has upped the supported number of devices from 250 to 500.

Along with this comes other scaling up improvements such as beefing up the help desk to support 1,000’s of tickets better, along with the usual “we fixed the code up to run better” fixes.

Integration: Nagios & Beyond

Also in the 3.5 release, Spiceworks added in support for creating alerts from emails. Here, what you can do is setup Nagios to email alerts into Spiceworks and get Nagios integration. More than just chunking an email into a ticket, Spiceworks has come up with a little DSL to let you parse through the Nagios emails to pull out information you need to create the alert or even, if I recall correctly, decide to alert or not. By default, it ships with some scripts to parse the default Nagios emails.

Nagios, of course, is everywhere: it’s like the kudzu of the IT management world. Undoubtably, there are many people in the Spiceworks community who’ll be rigging this up.

Also, as you can imagine, since this alert workflow works through email and there’s a DSL written around it, you could wire-up anything that sends email. The Spiceworks community, hopefully, will come up with some of those scripts and provide them back to the community – doing a little collaborative IT management, you see.

On the topic of help desk tickets, there’s still not the more advanced work-flows you’d expect from medium and enterprise level platforms. But, again, to be an apologist, Spiceworks target isn’t that market.

SQL-driven Reports

While Spiceworks has had reports in the past, it hasn’t let you muck around with the raw data too much. Also in 3.5, Spiceworks added the ability to work directly with the Spiceworks database to build up reports. Jay demo’ed this and, essentially, you type up your SQL and then map the results to various charts and tables that you can display in the dashboard. It’s like doing charts in Excel, essentially.

Here again, like most of these user-generated things in Spiceworks, there’s the potential for the Spiceworks users to share these reports and get collaborative IT management benefits.

UI Plugins

The last major item in 3.5 is one I’ve been encouraging them to do for a long time, as I would any IT management platform. They’ve added a plugin layer that’s essentially like a built in Greasemonkey for their application. The plugins you can build don’t cross beyond the UI layer into the “back-end” or monitoring layer (like, say, Microsoft Management Packs, Zenoss ZenPacks, Hyperic Plugins, and so on do). Instead, you can create new widgets in Spiceworks, but you can also modify existing parts of Spiceworks, like adding new fields to help desk tickets.

One of the characteristics of good IT management platform is allowing the community to extend the platform without the vendor getting involved. This, of course, calls for a plugin framework.

I spent some extra time with Spiceworks’ Tabrez Syed going over the plugin layer (thanks!). To summerize the questions I asked him:

• You get access to the database.
• It’s all UI-level.
• It’s all request driven, so there’s no background processing.
• The architecture is an event driven one: you find the different UI events involved in the request you’re hooking into, and register your code to fire off those events.

But, as mentioned above, the end result is a sort of Greasemonkey layer for the Spiceworks UI.

Others

With each Spiceworks release, there’s always a handful of other small features peppered through-out. They’re also always quietly releasing things, like the little pie-charts that tell you the online back-up services your peers are using (so you can decide which you should use yourself).

In this release, there are bandwidth charts that look pretty similar to MRTG charts and some new diagnostic, trouble shooting tools. Also, like many of non-consumer software products now-a-days, Spiceworks this release has the equivalent of a Facebook “activity stream” for each device. In the realm of IT management, this means you’ve got a rough change and configuration log around each device. There’s lots more to do with that kind of thing, esp. when it comes to doing collaborative IT management things like comparing config churn to others in the Spiceworks community (with an eye towards figuring out if the churn you have is good, bad, average, etc.).

Revenue

As mentioned at the top, Spiceworks’ product is free. The way customers pay for it is through the cleaned-up attention-channel Spiceworks builds up: IT people at small shops. Another Austin startup, OtherInbox is on the same path, though much earlier in the business.

The Spiceworks folks never give me much of a hint of their revenue, which is probably good since that’s the number question people ask me about Spiceworks. The answer I give these people is that the Spiceworks folks don’t have the haze of startup-implosion that you’ll see in people when The Plan isn’t working out. That’s no way to judge anything, but that’s often all I’ve got.

On the other hand, Jay told me that they do direct sales on their ads and other channel activities: they’re not just slapping Google Ads on there. More than just ads, just about every part of Spiceworks can be looked at as a channel for vendors and others to “sell into.” This is a key part to the business-side of Spiceworks: every part of the applications, each piece of functionality is a potential place to either sell “ads” or a point of access to sell to someone. That is, Spiceworks “paying customers,” if you will are IT vendors who want to buy both their (potential) customers (Spiceworks’ users) attention or access to them for distribution. This distribution could be of software, papers, notifications: whatever sort of thing you’d want to deliver in a highly targeted way.

There’s a fine line to walk there between being a functional, legit application versus AdWare, but with an ever growing install base, there’s a lot of quality eye-balls and, better, clicks in there who seem to think of Spiceworks as an application, not an ad.

Disclosure: Spiceworks is a client, as are Zenoss, Hyperic, and Microsoft.