One of the managed services industry’s best-known Master MSPs is moving to a new software platform. Specifically, MSP Services Network (MSPSN) has migrated to itControl Suite.
What’s behind the move? MSPSN CEO Amy Luby (pictured) offered some thoughts to me over email.
First, some background: MSPSN hosts managed services software for peer VARs and MSPs. Luby is a prolific voice across the managed services industry, driving education and also launching a face-to-face conference series known as MSP Revolution.
Making Her Move
Now, to the story at hand. Luby has experience with a range of remote monitoring and management tools but recently decided to standardize MSPSN’s business on itControl Suite. According to an email to me from Luby:
“The reason we chose itControl Suite was because it’s the most advanced and nimble product we’ve encountered to date. It has all of the same functionality that the other RMM tools have, and more. The core foundation of the product was built for MSP 2.0 and beyond.”
Luby is quick to note that itControl Suite is built on a Linux kernel — a fact that catches my attention, given all the recent buzz about open source within the managed services industry.
Adds Luby:
“The MSP model is maturing faster than the existing RMM software vendors can develop the right features and functionality into their existing products. So when we found itControl Suite and experienced how quickly they can develop features into their product, we asked them to build for MSPSN the right functionality into their product for the Master MSP model.”
In response, itControl Suite had MSPSN’s core requirements done in 3 weeks, she adds. “The rest will be done by the end of January. Without getting specific, we have been asking for all of this functionality from our other vendors for years.”
Her conclusion: “I would argue that the top tier RMM tools might be leap frogged in functionality by these new solutions that are nimble, built for development speed and are hungry to gain market share in 2009.”
She Said, He Said
It’s tough for me to offer a point-by-point response to Luby’s thoughts, since I’m an “observer” and she has actually run various MSP software to build her business. However, keep in mind:
- Perhaps I’m a bit of a wimp, but this article doesn’t mention which MSP tool(s) Luby abandoned. I didn’t feel comfortable throwing a vendor under the bus, especially since choosing an MSP tool is often like buying a car: Just because you select one brand doesn’t mean all the other brands are horrible.
- Master MSPs must — by their very nature — speak highly about the platforms they run. Otherwise, customers (subscribing MSPs and VARs) would worry about the master MSP’s core business software.
- I don’t know if there are financial or other business arrangements between MSPSN and itControl Suite.
I offer the paragraph above because as a journalist, I think it’s important to play devil’s advocate for readers. But there’s no doubt Luby has garnered respect from dozens of VARs who work regularly with MSPSN. And she earned my respect by opening up the MSP Revolution (her fall 2008 conference) to me and other industry bloggers, speakers and educators — such as MSP University’s Erick Simpson.
Finally, I fully agree with Luby on a key point: Nimble MSP solutions (especially those that effectively leverage software as a service and open code bases) will potentially disrupt big, monolithic applications that are difficult to polish and push forward.
MSPmentor is updated multiple times daily. Don’t miss a single post. Subscribe to our Enewsletter, RSS and Twitter feeds.
Read More About This Topic
Share This Post
Posted In: Master MSPs | Platforms | RMM
Tags: Amy Luby | itControl Suite | MSP Revolution | MSP Services Network | MSPSN | Remote Monitoring and Management Tool | RMM
Interact: Add a Comment | Trackback Link | Permalink
Subscribe: RSS Feed
Get Started: Visit our new 
So the big question in software development is always around quality control. As a software development shop grows, QA becomes more and more of a problem in order to keep standards high. More ‘mature’ products have learned this, and often this is why development appears to slow as products mature. QA takes longer as the product matures.
There’s no magic in software development speed — smaller companies always start off fast, and then are forced to slow by QA and support requirements.
Important to consider as product roadmaps are compared.
Dave: Generally speaking I agree with you. But the open source model does allow for faster development in some areas, since communities of developers are able to access the source code, submit bug fixes, etc. Ubuntu Linux for instance is upgraded roughly every six months.
Hi Dave,
I wish there was an event we were at right now so we could have one of our very good debates over beers about this. Maybe involve Erick and Karl? I think this one could go on for a long time and will definitely get livelier as the weeks and months progress through 2009.
First, good point about dev cycles. Having dealt with the existing top tier “mature” products for the past 7 years I have not experienced a higher standard of quality with a lengthening development cycle. I have experienced exactly the opposite unless a full re-write is initiated, but that gets us all back to the beginning where dev is fast, focused and meets the needs of the end user. In fact, the longer the dev cycle it seems that the less confidence any of us can have in an eventual quality product. The most common response I get when asking for features to simply work as advertised is (I am not talking about new features, but core functionality), “Wait until the next release, then it will work like it should.” This isn’t a good thing and indicates an improper development foundation that can only be cured by a re-write. One of the most recent tools I worked with has been “developing” their most important competitive feature for over two years now. They announced in November that they pushed off the release date again. If a software developer cannot produce a feature that is really the number one feature they lose sales to their competition for for over two years, that tells me they either don’t know how or don’t have the proper underlying foundation to create it. In other words, the core product is flawed and the new feature set cannot be built on top of it until the core product is fixed. Either answer is a bad one for you and I.
I am not saying you’re wrong, but I think there is definitely a cycle in dealing with software companies and the more “mature” contenders have not been producing and will continue to lose ground in providing the features that the mature MSP needs to compete going forward. Also, I don’t necessarily think it’s is a bad thing that we have new and emerging tools to look at. Competition is good, and the more tools we have that come into the marketplace, and really disrupt it, only forces our “mature” vendors to step up their game to stay in it. I don’t think the top tier tool vendors will give up without a fight, but I do think it’s going to be a bloody battle.
I am sure you’ve noticed a number of deeply seated proponents of “mature” product vendors beginning to change tools, process and procedure? If you haven’t noticed, keep your eyes peeled. This is a result of maturing the MSP business model and needing a mature tool set to support it. Our “mature” tool developers certainly paved the way, and I wish that they could step up today to deliver what the mature MSP needs. It just isn’t reality and the choice you and I are left with is do we wait it out with our “mature” product vendors hoping that they will eventually get it right? Or, do we switch tools now so that we’re ready to compete going forward? If we wait, how long? One year, two years, more? If we change tool sets now, what if the new guys don’t live up to their promises? Either answer isn’t easy and one isn’t necessarily the best one as they are both fraught with risk, problems, and pitfalls. The issue then that you and I as business owners have to deal with is do we want to deal with the risks, problems and pitfalls of a new product or a “mature” product? The answer is more and more complicated as your MSP model matures and includes or accommodates for distributed computing, cloud services, traditional LAN/WAN architecture, outsourcing, and all of the peripheral managed services like spam control, email archiving, remote backup, virtualization, etc.
The real complication I see among MSPs in the Channel today, which I will challenge that the “mature” vendors will use to their competitive advantage at least in the short term, is that some will see this as a repeat of the major issue we had about 4 years ago which was the “my tool is better than your tool” argument. I am sure you remember those long debates? Some MSPs are still having them. Right now the focus shouldn’t be on why your tool is better than mine, but you and I should be focusing together on whether vendors are creating or have created the right foundation to take us all into MSP 2.0 and beyond. I would argue that this discussion would result in a conclusion that included some of our “mature” product vendors and some of the new and emerging vendors. The MSPs who will lose out on this debate are those who refuse to consider all options going into 2009, stick their heads in the sand and don’t take this opportunity to look carefully at how their model has or has not matured and how their existing tools have or have not matured. The “mature” vendors who will lose out on this debate are those who stick to the “My tool is better than their tool argument” too long which is the equivalent of sticking their heads in the sand. They won’t mature or deliver for us and will lose market share to the new and emerging tool vendors who are willing to deliver for us.
Where’s the beer?
Amy Luby
CEO, MSPSN
http://www.mspsn.com
aluby at mspsn dot com
When I’m out and about these days, i hear more and more that SP’s are running more than one RMM in house. With the nice laundry list out there these days, it can be comforting to know that you don’t have to really choose just one. Thoughts?
the typical MSP uses three tools on average. We will publish more details with the MSPmentor 100 report in early Feb 2009.
That stat really confirms in my mind that none of the tools that exist in the Channel right now really meet the needs of the mature MSP. That doesn’t mean all tool vendors are bad or evil, it just means there is a lot of room to grow. That means opportunity for new players to make some headway.
Amy Luby
CEO, MSP Services Network
aluby at mspsn dot com
http://www.mspsn.com
Amy: The stat also shows that MSPs want to specialize in different areas. Some are pushing into storage management, others security, others hosted apps. It’s like buying an ERP suite. There are multiple apps you’ll need to select from and plug into your system. Same thing in the MSP market…
Agreed. That’s why integration and co-opetition are more and more important for the Channel and the MSP. If these systems don’t ply nice together then the MSP’s business model becomes more complex which is a direct negative hit to their bottom line.
Amy Luby
CEO, MSP Services Network
aluby at mspsn dot com
http://www.mspsn.com