Interview with David Dennis and Simon Bennett

Interview with David Dennis and Simon Bennett – GroundWork Open Source

We came across David Dennis and Simon Bennett at GroundWork Open Source, because they seemed to do something that didn’t entirely make sense. GroudWork is an open source company that released a plug-in for a completely proprietary product – a connector for Microsoft System Center Operations Manager, of all things.

Read on to see how they explain this, and how they school us on open source management tools.

Scott Swigart: First, please take a minute to introduce yourself, your company, and what you’re doing around open source.

David Dennis: Sure. I’m senior director of marketing and business development. We have Simon Bennett, who’s a senior director of product management, here with us as well.

Simon Bennett: Hello.

David: Groundwork Open Source is a venture-backed commercial software company in the systems, application, and network monitoring space. From a proprietary point of view, most of our customers choose us as an alternative to what are often called the “big four” systems management prospects. Those include HP OpenView, IBM Tivoli, BMC Patrol, and some of the CA products.

In the open source context, a lot of people use our product as a way to consolidate and move up the scale from various open source point solutions to do monitoring, applications, and system management.

We’ve been around since 2004. We have a couple hundred subscribers and about 20,000 users of the free version of our product.

Scott: I saw in a press release that you have written a plugin to Systems Center Operations Manager. If I understand it right, your pack is open source, and it’s designed for managing a lot of non Microsoft technology, but it plugs into Microsoft’s management solutions. Tell us a bit about what you are doing there.

David: Sure, but before we get into the SCOM connector, we should clarify a little bit more about what the product does without the SCOM connector.

First, I think it’s helpful to talk about our software development model, which is similar in many ways to that of Red Hat. For example, they incorporate the Linux kernel and the GNOME UI from those respective projects, and they combine those pieces with their own code, and then support the whole kit and kaboodle.

We basically do the same thing in the monitoring arena. There are a lot of open source point solutions that have been established for many years and are very good at what they do. Things like Nagios RRDtool, SNM PTT, and Syslog ng are very credible and have very big user communities.

While they’re very good at what they do, they don’t necessarily provide all of the features to create a really comprehensive monitoring system management product. For example, Nagios by itself doesn’t have a reporting engine, or RRDtool, which is a graphing tool, but it doesn’t have alerting capabilities.

We pull all of that stuff together, and then we have our code that basically normalizes the data, provides a configuration layer, and provides a fancy pants UI on top that gives you dashboards and all sorts of extra features.

That stack lets our product manage more than 1,500 different types of things using various plugins. Our product runs on Linux, but about half of what we monitor runs on Windows. Out of the box, we can manage Linux, Solaris, HP-UX, Windows, routers, switches, and applications running on top of those various operating systems.

People often use our product to handle heterogeneous environments. About 60 percent of what people monitor with it are operating systems and applications. About 40 percent is network infrastructure.

A lot of people who want to continue using SCOM to manage Windows, and while we can monitor Windows, there are a lot of features within SCOM that we don’t do. For example, there are a lot of things within SCOM related to patching and configuration management that are really outside of the purview of what we do.

At the same time, a lot of these people are running Windows machines alongside a lot of non Windows stuff. They may want to keep using SCOM for their Windows systems but also integrate non-Windows systems in the environment for performance data, alerts, trending, capacity, planning data, running reports, using dashboards, and so forth.

The connector we just released is able to forward information from SCOM about the status and availability of things SCOM is monitoring into our product. You can also monitor Windows natively with our product, but if you’re already a SCOM shop and you’d like to keep using SCOM, this allows you to see the Windows information and the non-Windows information through one UI.

Scott: That makes sense, because SCOM doesn’t, out of the box, monitor any of the other stuff that people have, like Linux, Apache, non-Windows applications, and some of the network gear.

David: They did recently release 17 platform extensions that are designed to give SCOM some native capabilities for some of the most popular and obvious things, like Solaris and Apache.

But since there are only 17 of them, there’s a vast universe of non-Windows stuff above and beyond the reach of Microsoft’s platform extensions.

Scott: Where does Open Pegasus fit in?

Simon: There are some platform extensions that are built on top of Open Pegasus.

Scott: Is that something you use?

David: We don’t use Open Pegasus, which is essentially a configuration management database. If somebody wanted to us Open Pegasus with us, people have built integration with our product and other configuration management databases.

I think somebody built one for the HP Universal CMDB, but we don’t have any customers using us with Open Pegasus right now. They could if they wanted to, but you don’t need to have Open Pegasus to make our product work.

Simon: I believe some platform extensions that Microsoft released were based on the Open Pegasus agent technology. Groundwork can work either with an agent or in an agentless capacity. We’ve done integrations with other types of agents that aren’t ours, such as Ganglia, which is particularly well suited for grid and cluster monitoring.

David: The other point of comparison and contrast with platform extensions, aside from the fact there is only a small number of them, is where the information is showing up. The extensions are designed to natively monitor some non Windows things, but to display the information via the SCOM UI.

A lot of Linux Sysadmins don’t want to do that. The SCOM UI is a thick client that runs on Windows. It’s very full-featured and rich, but a lot of the Linux guys aren’t even running Windows in the first place.

Scott: Let’s put some of that into the context of a use case. You might have an organization that has some Windows and some Linux. It’s got Linux admins who may want to use a UI like yours, but maybe they want a unified way of doing alerting. Or they want some kind of all up capacity planning and things like that.

The SCOM connector gives a sort of roll up across the whole company, and they could use your stuff too. If they’re 70% Windows and 30% Linux, maybe they’ve decided that it makes sense for them to live more in SCOM, if that’s the kind of organization they are, but you guys actually have a UI. You’re not just extensions to SCOM, and you offer Linux admins something that works the way they think.

David: I think a couple of scenarios help to explain it even further. If you have a shop that is mostly Windows with a little bit of non-Windows stuff, you have a couple of options.

The first option is that, if the existing Microsoft platform extensions cover all of your needs, you can use those X Plat extensions and view everything through SCOM. If the X Plat extensions don’t cover all your needs, or if the Unix and Linux Admins don’t want to view things through the SCOM UI, then you can use our product and cover the rest of it.

The other option would be, if you’re in a shop even closer to 50/50 Windows versus non-Windows, then you are likely to want to view the information through something other than the SCOM UI. Those people often do that by pumping SCOM into something like Tivoli or OpenView.

Aside from being more able to be integrated and open source–and now with our new JBoss portal based product, more Web 2.0–we’re a lot cheaper than OpenView and Tivoli. Combining our product with SCOM gives you an option that’s about 80 percent cheaper than OpenView for a new installation. If you’re comparing just the maintenance cost versus our subscription, its 50% to 60% cheaper.

Scott: Have you seen that in this economy, there’s less likelihood that people will simply pay a lot for a name and more willingness to do a real price-for-performance comparison?

Simon: Yes, and particularly with the current economic environment, people are also paying a lot more attention to things like how open solutions are. They are considering upfront future scenarios such as wanting to bring it in house or changing the way they are interacting with it, and they want to know what their options are there.

They are asking questions like whether they can integrate it themselves or whether they will need a very specialized, expensive third party to do it for them. Those considerations play well to open source solutions like ours, which is based on existing technology that many people already know.

We’ve added a development kit with our new release, the sixth version, to enable people to be creative on their own without being beholden to a reseller or partner with a particular SI specialization.

David: Fifty percent of the deals that we see that are larger than $40,000. For us, that’s a break point, meaning they’re a larger environment and we are likely to be up against Tivoli and OpenView.

Scott: We’ve talked about the business side of the open source that you’re doing, so let’s talk a little bit about the development side. Why an open source approach? It sounds like you’ve been doing this from day one. What is the benefit to you as a business to using open source as the methodology that you use to construct your solution and your offering?

David: There’s an important distinction between the sort of amalgamated approach that we take versus a more silo-oriented approach, where the commercial software company has ownership of a single project with which they’re associated.

MySQL is basically built that way, for example. The Linux distros don’t tend to be built that way. Our software model, as we’ve said, is more like the Linux distros. There are two main reasons that we did it the way we did it, as opposed to creating our own contained project that covers everything soup to nuts.

First, a lot of open source point solutions have been out quite a long time, and they have a good track record. In the case of Nagios, it’s been out almost 10 years, I think. They’re stable, well proven, and battle hardened.

That is really important in a production environment. This isn’t a tool for software developers, where perhaps one has a little more free rein to be a little more bleeding edge. This is stuff designed for running in a production environment, where being battle hardened is really important.

The second reason we went the open source route is that, we’re competing against the Tivolis and OpenViews of the world, which have been around for well over 10 years, sometimes closer to 20 in the case of OpenView. How many thousands of coding hours have gone into building them?

If you were going to match what they did, you’d have to reinvent the wheel, which would take forever to do, and the economic advantage would start to disappear.

Scott: I’d like to touch back on part of your answer there. How are the kinds of contributions that you get from your community different because you’re making a product for system administrators as opposed to software developers or DBAs?

David: System administrators are more likely to make scripts and plugins and various kinds of configuration utilities that are the kind of thing a Sysadmin does. But they’re not going to give you the C code, for example, because that’s not what they do. That’s not how they scratch their own itch; that’s not the world they live in.

So as a result of that, when you’re dealing with this particular user base, you have to realize that the kind of contributions you’re going to get back from your community are not the core code. There are utilities and plugins that are extremely valuable in their own right, and we’re very thankful to have them, but you can’t really rely on having the Sysadmins actually code the product.

Scott: To recap some key points, it seems that the business benefit you get by using an open source development methodology is that you are able to aggregate other proven open source technologies, which you wouldn’t be able to do if you took a proprietary approach.

That gives you a wealth of discrete tools that your customers, the admins, are already familiar with. Therefore, your tool makes a lot of sense to them because they have an understanding of where that’s coming from. They’ve probably even worked with some of the underlying tools.

You stitch together those tools, to combine the strengths of all of them, and you increase administrators’ productivity because they no longer have to use a hundred different tools. They’ve got it all brought in under one roof.

Simon: That’s exactly right. To give you a concrete example, one of products we use is SNMPTT, which is designed to gather monitoring data, primarily from network devices, which it’s really good at.

We built a bridge between that and MySQL, which we use for data storage and normalization. And then we built a bridge from there to the BIRT open source reporting project, which is part of the Eclipse Project, to provide end-to-end network management, storage, de-normalization, and reporting.

None of those tools can provide all of that on their own, and we get the benefit of the combination.

Scott: That means that people are able to get data like the uptime and throughput of their network devices, what ports are active or not active, and it’s all archived. You’re doing that with MySQL, and they’re able to visualize that data.

David: Right. The other advantage we provide from an open source perspective is that we have a lot of the tools that they’re already using as part of our package, while at the same time, we provide commercial support for the whole thing.

For a lot of the projects that are part of what we provide in our suite, there isn’t a commercial support option otherwise, and a lot of businesses require a support team standing behind the tools they’re using.

Simon: It’s often a compliance issue.

David: And also security. Our whole stack has been audited by IBM Internet Security Services, and we responded to the areas of vulnerability they identified. That’s something individual open source projects typically don’t do on their own, because they just don’t have the resources.

On the flipside, for customers who come to us from the proprietary world and are not necessarily familiar with open source tools, they get a packaged product. They don’t necessarily even care that it’s open source.

They download it, it’s got an installer, and all the parts of our stack are already in there. They don’t have to deal with identifying, downloading, and installing individual projects, as well as trying to get them to run together.

Just to reiterate what’s in our stack, the front end is JBoss Portal, the database is MySQL Enterprise, it’s got Apache in there as the web server, and BIRT is a reporting instrument from the Eclipse Project.

In addition, we’ve got our own code, and down at the bottom, at what we call the instrumentation layers, that’s where RRDtool and Nagios and Syslog ng and those kind of guys show up.

Scott: You’re providing a support option for a lot of underlying projects that don’t really have one, and that’s a compliance requirement for many larger companies. How do you address the challenge of fixing a customer issue and then having to carry that patch or else doing the additional work of making sure that you get it into the upstream project?

To put it another way, how you balance meeting the needs of customers with getting stuff contributed back upstream?

Simon: As a general rule, we try in every case possible to contribute patches, fixes, improvements, and new features back to the upstream projects. We think that’s an extremely important part of being a good citizen.

We maintain good relationships with the projects, whether it’s Tobi Oetiker over at RRDtool or any of the other projects, and we try to go the extra mile to make sure those patches get distributed. In part, obviously, that’s because if they’re part of the upstream package, we have fewer exceptions to manage.

But we also take that approach because it makes the projects that we include better overall. If a new feature gets added to a project, whether it’s something we were involved in or not, it makes the overall solution more capable and more powerful.

Scott: It seems like one of the things you’re providing to your customers is the assurance that certain functionality’s going to be available. Have you ever had to replace one of those instrumentation pieces with a different one because the one that you’d originally been depending on became defunct, and something else was better meeting those needs?

Simon: It’s not quite as black and white as you outlined there. It’s usually not the case that we need to move from one project to another for some cut and dried reason, although we’ve certainly seen our usage and blend of the different pieces change over time.

As projects evolve, some get better at certain things, while others become less active. That comes with the territory. We amalgamate 60 or 70 different open source projects, so managing their individual life cycles, making sure that we’re getting the best features, and taking advantage of the best solutions that are out there just goes along with the usual product management life cycle.

If there’s is a particular solution that looks promising, we keep an eye on it with a view to including it either as an add on or part of the base project on an ongoing basis.

David: I don’t know if we had any cases where a project has died on the vine completely and we had to replace it for that reason.

Scott: I’m sure the functionality also overlaps to some extent, too, so you may decide to get a specific piece of functionality on occasion from a different project that you are already including.

Simon: That’s true. One of the strengths of open source is that there are always seven ways to do the same thing, and as we learn more and operate in bigger, more complex enterprise wide deployments, our approach sometimes changes at the implementation level.

Part of the strength of the solution is that there are a couple of different ways to go. When we roll an individual installation out, we can advise the customer about what the tradeoffs might be, which is a better approach in many ways than having to say, “This is how you will do a particular thing, whether it fits your needs our not.”

David: This line of discussion also brings up how we choose what we put in the product by default. As Simon said, there are typically many ways to do the same thing, and we choose the one that we think suits us best.

We also have cases where there are open source projects out there that do not ship as part of out standard suite, but that people have integrated with our product more than once. Ganglia’s a good example of that.

As Simon mentioned, Ganglia’s a very specialized grid and cluster monitoring tool that collects metrics but doesn’t, for example, have a notification engine of its own, so people often use us in conjunction with it.

As of right now, Ganglia does not ship as part of our standard package. If you want to work it with Ganglia, there’s a Ganglia integration module available that you can work with us to get. If we start seeing more and more people wanting Ganglia, it could get folded in as part of standard offering.

Scott: What are some of the things you see as really likely on the horizon? Physical virtual management? Things around storage? Are there opportunities to manage some sort of external cloud?

David: Virtualization and cloud computing are obviously significant. In fact, we already have an instance that runs on the Amazon Cloud, and there are also plug ins you can get for our product that help to integrate things like the Amazon billing information with the kind of stuff that we do.

One interesting scenario is that a lot of people are going to have things running in the cloud, but very few people are going to have everything running in the cloud. One of the things they seem to be looking for is a way to centrally keep an eye on everything that is running inside and outside the cloud. You can actually already do that today with our product, but we’ll be looking to do more in that direction as well.

Scott: We’re getting near the end of our time, so is there anything you’d like to bring up that we haven’t talked about yet?

David: Continuing on that virtualization and cloud angle, we’re in the same space that, for example, Hyperic was in. As you may know, Hyperic got acquired by SpringSource, which then got acquired by VMware. That’s part of a trend among the virtualization platform vendors to try to make an all-in-one offering that covers the hypervisor, the application stack, and the management pieces. We think that’s going to continue, and it will be interesting to see how that unfolds.

We also think that open source has a particularly important role to play in the cloud. Some people have been writing as if open source and the cloud are somehow at loggerheads, as if somehow the proliferation of cloud computing is somehow going to be bad for open source.

I think it should be good for open source, because open source licensing models fit the cloud very well. It’s a little tough to figure out how some of the usual proprietary licensing works in a cloud situation, especially when the instances go up and down.

We think that the cloud movement is going to continue, but we also think it’s going to be combined with traditional data center and private clouds. People are going to be wanting a solution that can handle both.

The economics of open source fit the cloud perfectly, as does the kind of amalgamation model that we have. We’re designed to allow for all of these things to connect with us, which makes it very easy for us to integrate with other people, whether they’re proprietary or open source. The SCOM connector is just one example of that.

Scott: Thanks for taking the time to talk today.

David: Thank you.

Simon: Goodbye.

Bookmark this: