At RedMonk, we’ve been fortunate to work with a wide variety of companies over the past seven years, ranging from two person startups to some of the largest businesses in the world. Given this diversity in our clientbase – which, it’s worth noting, we strive for both in our model and otherwise – it’s to be expected that some of our potential clients are less than clear on what it’s like to work with analyst firms in general, and RedMonk specifically. The big firms, after all, have entire teams dedicated to working with analysts. Smaller firms and startups, on the other hand, tend to be understandably fuzzy on what analysts do, let alone how to work with them effectively.

The past few weeks, all of us at RedMonk have been answering most or all of these questions as a bunch of new folks come in the door, so I thought it would be worth taking a minute to put it down in writing. We’re happy to answer any other questions you might have, of course, but these should give you a fair idea of what it’s like to work with us. Herewith, then, the Startup’s Guide to Working with RedMonk, or Everything You Wanted to Know About Working With RedMonk, But Were Afraid to Ask.

Q: What is an analyst?
A: There are lots of different definitions, and lots of different models. At the most basic level at RedMonk, we take in a wealth of data from blogs to research papers to conferences to conversations to Twitter to quantitative research to application testing, process it all extracting conclusions that we call analysis. Some of that makes its way on to the blogs where anyone can read it, some of it is used tactically and strategically on behalf of clients and some of it just rattles around in our brains waiting for the right outlet.

Q: Couldn’t I do that work myself?
A: Possibly, depending on your training and contacts. But it’s a full time job. Would you rather spend your time on your products or doing hours and hours of research? You could probably also learn to do your own accounting, but do you want to?

Q: Who do analysts work with, typically?
A: There are many different markets, but three of the biggest are a.) end users (enterprises, governments, etc), b.) vendors, and c.) financial analysts.

Q: Why should we work with an analyst?
A: Ask ten startups and you’ll get ten different answers. Ultimately, whether you decide to work with an analyst or not will depend on whether you think you’ll benefit from an informed set of eyes that’s external to your organization. What we find is that most organizations large and small have trouble, at times, seeing the forest for the trees. It’s difficult to retain an industry-wide perspective when you’re working all day, every day on your product. A big part of our job is providing that perspective: telling you where you’re good, where you’re bad, the same for your competitors, and where there are unleveraged opportunities. We’re your radar, your devil’s advocate, your conscience and your network in one convenient package.

Q: How is RedMonk different from other analyst firms?
A: Well, from what we hear some of the other firms have differing opinions on this subject But here are just a few of the ways that I think are important:

1. Bottom Up:
   At RedMonk, each of us has – in some way – lived Billy Marshall’s dictum,”The CIO is the Last to Know.” That’s not to say the role’s not important: as the one writing the checks, CIOs remain a key stakeholder. But they are no longer, in our view, the primary decision makers when it comes to technology adoption. Technologies like Linux, Apache, MySQL, PHP, Eclipse, and Firefox didn’t reach mainstream acceptance because of CIOs; they are where they are because they’re good technology and lots of people used them. When adoption hits a certain critical mass, CIO approval becomes a fait accompli.

   So we at RedMonk tend to spend more time focusing on the adopters than the CIO, because we think that in this day and age, they’re the make or break audience.

2. Coverage:
   At RedMonk, we are generalists rather than specialists. If you’re looking for someone to build you a product scorecard comparing every last feature between products A and B, then, we’ll happily direct you elsewhere. If you’re looking for analysts that have an understanding of all of the pieces that might go into, say, cloud platforms, from the virtualization technologies to the operating system to the database to the programming language to the development framework to the tooling, you’ve come to the right place. As the hard boundaries between technologies – be they individual software products, or how same interact with storage, hardware, and networking – it’s our view that analysts need to have a broad skillset to provide good coverage. Sure, we have areas of specialty: Cote spends the most time on IT Management for example, and I tend to be the point person for free and open source software questions, but we all have the wide beats necessary to answer complicated questions.
3. Independence:
   Simply put, as James said this morning, you can buy our thinking but not our opinion. What does this mean? In simple terms, it means that you can’t pay us to say nice things about you. There are analyst firms that do that, and we’re happy to point you in their direction. We’re a small firm, and our integrity is a big part of who we are. So that means no RedMonk-branded, commissioned whitepapers, period. If folks want to buy them after we’ve written them, great. But we won’t write complimentary whitepapers for cash. Not just because it’s – in our view – a dishonest practice; we also don’t think they’re high value for readers.
4. Open Source:
   As the home page advertises, we are built on and for open source. We believe in open source. We’ve covered it all along. We practice it ourselves, by publishing our content free of paywalls under Creative Commons licenses. We give back, by doing what we can in going to bat for various open source communities both publicly and behind the scenes, writing up open source HowTo‘s, commissioning plugins like Progressive License and building out sites like FOSS FAQ.
5. No Barriers to Entry:
   Because we at RedMonk preach heavily about lowering barriers to entry, we’ve tried to make them as low as possible for startups. Want to work with us? We have a standard $5K proposal available in PDF form that everyone signs: saves time on negotiations. Want to schedule a consulting session, purchase a screencast, or setup a speaking engagement? We’ll give you an hourly figure you can choose to debit from your bank of hours, a link to book our time and we’re done: no hassling over “seats”, or “web rights” or “lifespan.” Want to know what we’ve been researching lately but don’t have the time to follow our blogs? We have a bi-weekly newsletter that will keep you up to speed.

   We try to be easy to work with, and we think we are. If you think we’re not, just let us know how to fix it and we’ll do our best.

Q: Aren’t analysts the ones predicting things that have been obvious for years?
A: Well, we’ve tended to be a bit ahead of the curve. And some folks that we respect have seemed to agree. We were out front with our coverage (not to mention adoption) of open source, but let’s take something less inevitable. Five years ago, we were arguing for REST, four years ago we were talking about dynamic languages, non-relational datastores (think NoSQL), MySQL’s ubiquity, and the promise of SaaS, and three years ago we called Amazon’s EC2 a Big Deal. Seems like those have all been pretty decent guesses, and not obvious at the time. Our timing can be off, which is why we say “we can tell you what will happen, we just can’t tell you when,” but overall I think our radar is pretty reliable.

As it should be, because it’s all about listening to the makers.

Q: Who works with RedMonk? What’s your client list look like?
A: Check that out at any time here.

Q: How does RedMonk make money? Don’t you give everything away?
A: We give away content on our blogs, yes, because we believe giving back is the right thing to do and because the resulting commentary improves our analysis. But this in no way precludes our commercial opportunities; if anything, it dramatically expands them. Think of it this way: when we put out a piece on a new product or technology, we’ve only got a thousand words – three or four thousand, max – to explore the implications. Many of our clients engage us on subjects we’ve already written up to understand how what we’ve written about affects their respective businesses.

Q: Does RedMonk keep secrets?
A: Yes. As we’ve said before, many times, if you can’t keep secrets, you can’t do this job. We’re trusted with secrets every week; from the trivial to the financially material. As far as I’m aware, we’ve had zero complaints on our ability to protect the information we’re entrusted with.

That said, customers need to understand that secrecy is a tradeoff. If you give us a presentation of twenty NDA slides and four that are public, we’re likely to consider the whole thing confidential just to be safe. As long as you’re comfortable knowing that excessive confidentiality will negatively impact our ability to tell your story, we’re happy to keep your secrets.

Q: Even if you keep our information confidential, should I be concerned that you work with our competitor?
A: We get this question a lot from folks new to working with analysts, and the best answer I can provide is this: just about every one of our customers competes, in some form or fashion, with another customer of ours. If we didn’t protect their private information and strategies, we wouldn’t be in business today. It’s that simple.

Q: How do we manage the analyst relationships: can we pick who we work with?
A: Absolutely. Again, we want to be easy to work with. The only caveat here is scheduling; because we’re all busy, if you have an urgent need and the analyst you want is travelling, you’ll probably have to either wait or work with whoever’s available.

Q: What do we get for our money?
A: A number of services:

• Press Services: media handling and supporting quotes for releases
• Investor Relations: market and product education for angel/VC/etc
• Newsletter Subscription: access to client only bi-weekly research digests
• Network Services: identification and introduction to prospects, community or partner contacts
• Consulting Hours: may be used for strategy, messaging/marketing testing, screencasting, podcasting, speaking engagements, etc.
• Preferred Pricing: for rich/multimedia content, including audio and video (demos, executive and developer, interviews, etc)
• Interactive Briefings: briefings are always free of charge with RedMonk, but customers get real-time feedback and insight
• Recruiting Assistance: wherever possible, we are happy to broker connections from clients to available talent in our network

Apart from the consulting hours, which are preset at 10, you get 12 months of service for the contract. So if we end up talking to the press for 20 hours over the year – don’t laugh, that’s happened – it’s all included.

Q: I just need you for one specific project – can you work on an a la carte basis?
A: We can. It usually ends up being pricier to bill by the hour, but if that’s what’s easiest for you, we can figure something out.

Q: Does it cost me anything to brief you?
A: Never has, never will. Pay for play is a model that frankly should have died years ago. We can take a higher volume of briefings from clients, but everyone has the right to talk to us – provided it’s a relevant product – irrespective of whether they are a customer or not.

Q: What’s the first thing you do with new clients?
A: A kickoff call, generally. We’ll all get on the phone, do introductions to people and technology, and talk about what we see as opportunities and what you need. This doesn’t count against your time, of course.

Q: How do we best work with you?
A: Keep in touch. The more you talk to us, the more service you get.

Q: What kinds of things can you do for us?
A: Varies widely, of course, and depends on what you need. Is your organization engineering focused? We might discuss market segmentation, community outreach, and consider doing a screen or podcast to help educate about your product. Have the business and sales sides under control? We might talk about technical trends that are or will affect your product direction and strategy. Early to market? We’ll help you match your featureset to business problems and reduce the barriers to entry for potential customers. Have a product widely adopted, but problems in customer conversion and revenue? We’ll look at your business model and compare it to what we’ve seen be successful, as well as trying to help you identify unleveraged assets.

And so on. There are a lot of ways we can help be your eyes and ears, your checkpoint, and a broker for conversations you’d like to have.

Q: Where are you all located?
A: I’m based out of Portland, Maine, James is in London, and Cote‘s in Austin, Texas. We also have a GreenMonk line of business covering all things green, and that’s led by Tom Raftery who works out of Seville. Marcia, who handles all of our operations, is also based in Maine.

Q: If I want to engage, how do I go about it?
A: Drop a note to sales at redmonk.com or marcia at redmonk.com and we’ll get you set up. It’s that easy

Time, as Ben Stiller’s troubled, spree killing hitchiker correctly intuits, is very much at a premium these days. Perhaps he was a bit optimistic in his assessment of the value of a mere 60 seconds, all that differentiated his 7 minute Abs from his 8 minute competition, but the point is nonetheless well taken.

Yes, even in our industry. Maybe even more so.

As many of you know by now, we at RedMonk are something of a broken record on the subject of “barriers to entry.” Have been for years now, actually. And while said barriers may take a myriad of forms – poor documentation, lack of developer friendly APIs, platform centricity – few are more powerful than simple time. Few cases are more illustrative of this than my years old decision to leverage Zmanda’s ZRM packages for our MySQL backup needs.

Much as it pains me to admit it, back in 2006, our “backup” procedures consisted of a few manual rsync scripts, a bit of duct tape and bailing wire, and an inappropriate faith that our hard drives would never die or become corrupt. Which is another way of saying that we desperately needed a backup solution.

In my capacity as an analyst, I’d been briefed by Zmanda – suppliers of MySQL backup solutions – more than a few times, and I was aware, peripherally, that the solution would meet our needs. But besides downloading the packages and kicking the tires on a test CentOS instance (they didn’t have .deb’s back then), I had never seriously considered applying them to our production instance. Not because it was too expensive: the basic ZRM packages were free and open source. Not because the technical approach was unsound: it was basically automating much of the mysqldump and rsync process I was performing manually already, while providing niceties such as versioning and encryption to boot. No, I hadn’t considered using the technology simply because I didn’t think I had the time.

You can argue that one should make the time to craft a sufficient backup procedure, and I will not disagree with you. But I, like a great many other people in this industry, was busy, and there are so many hours in the day. Given how complicated the setup can often be for backup scripts – particularly because in this case I wanted to push the backups to S3 – I couldn’t be bothered.

Until I came across “How to setup and verify a backup solution for MySQL in 15 minutes – all using open source software!!.” Written by the Zmanda folks, it outlined a very simple procedure for backing up and restoring MySQL databases using their packaged software. A process that took 15 minutes. And even I, busy as I might have been, had 15 minutes. And while they said 15, I think it actually took me closer to the 7 of 7 minute abs. Once I’d coverted the RPMs, that is.

Anyway, three or so years later (here’s how we did things – much of the Amazon S3 sync we scripted is now a feature of the Zmanda product), RedMonk is still a ZRM user. Not really because of the technology. And certainly not because of a mix of industry magazine placements, PR pitches or webinars. We’re a user because Zmanda eliminated the barrier of entry that is time.

Many of the enterprise technology vendors in the audience are probably thinking that 15 minutes isn’t enough to show them their entire product, and they’d be right. But I don’t need to know everything: show me something. Something interesting that can be done in a few minutes. If you can do that, and your product is interesting enough, people will take the time to discover the rest.

And if you can’t, you might want to think about why you can’t.

Disclosure: Zmanda is not a RedMonk client, nor is Amazon.

Given that our job is analysis and advice on software and related technologies, it’s probably not terribly surprising that we’re asked to field a lot of questions on the subject. A couple a day, at a minimum.

Whether they’re from the media, software developers and firms, or end users, we’d very much like to answer them all. Regrettably, the volume makes this impossible. We therefore have to prioritize inbound requests by a variety of filters – customer, media, and so on – but I’d also like to try and pick representative questions out of the rest and answer them periodically.

In other words, I’ll answer the occasional emailed question but simply do it in public, so as to expand the potential benefits.

With that, “Ask RedMonk” is born.

Today’s question comes from an anonymous reader, who writes (edited for clarity):

I am a reader of your blog tecosystems and I have been reading about your migration from Exchange to Zimbra. I noticed on a recent entry that you moved away from Zimbra to Google Apps.

[The company] where I work as a systems administrator is thinking of moving to Zimbra instead of Exchange. We are moving to a hosted solution and I am leaning to Exchange but [others prefer] Zimbra.

I am wondering if you could take a few minutes of your time to just let me know if you really thought that Zimbra was a good product or [needs work]. I don’t like the webclient as it takes a long time to pull information using Ajax and also I am not so happy with using a connector to access email on Outlook since it is not native to outlook.

In other words if you had to [advise] someone based on your experience would you still recommend someone to migrate to Zimbra? I would like to know your opinion an appreciate any piece of advice you might have.

Now I realize that I said I’d answer the question, but of course I can’t: not specifically. I’d need a lot more information, such as a.) the desktop landscape at the firm, b.) the relative costs (do they have an EA w/ Microsoft, etc), c.) the client picture (all Outlook? mostly Outlook?), d.) the types of users, e.) the existing email solution and surrounding infrastructure, f.) the skillsets of the sysadmins, and so on.

That said, some general thoughts for those considering Zimbra versus Exchange:

• Commercial Support:
  Obviously Microsoft is larger and more established in its commercial support staff and resources, but from our interactions, my conversations with Zimbra customers and my observations of the user forums I am not of the belief that commercial support will be a differentiator on a software basis. And given that the application is to be hosted, the real importance will be with the hosts of the given applications, as all hosts are not created equal (I would not host anything, for example, at 1and1, which provides Exchange services).

  Microsoft has a slight edge here, perhaps, because the Exchange/Outlook combination is designed to work together without the added complexity of a connector or bridge.

  That said, we’ve had issues in the past with corrupt PST/OST files, new Exchange server setup, and so on.

• Cross-Platform:
  This has traditionally been a significant differentiator for non-Microsoft products. While Exchange delivers a very solid experience if you’re using Outlook or the Outlook Web Access on Internet Explorer, it’s far less attractive if you’re using, say, Firefox.

  If you have a mix of desktop machines, then, or want to preserve that option in future this might be worth considering. If the environment is all Windows and likely to be so indefinitely, it’s obviously less important.

• Interoperability:

The concern here specifically is Zimbra ==> Outlook mail integration, but I don’t believe this to be an issue. Zimbra speaks IMAP fluently, as will Outlook, so mail should be a non-issue. What is, however, more problematic is Calendaring, and that’s whether the Connector comes in. Zimbra has worked to provide this functionality for Outlook users, and largely succeeded, but internally we had some strange issues with Connector and given that it’s a non-standard protocol it’s likely to remain somewhat flaky.

• Maturity:

Is Exchange a more mature product set than Zimbra? Undoubtedly, as it’s significantly older. But the product’s maturity was never a question for us, and doesn’t seem to be for deployments of significant size so I don’t see this as a legitimate concern.

• Multi-Tenancy:
  One of the advantages occasionally claimed by Zimbra advocates (and other Exchange competitors) is that they were designed from day one to be comfortable in multi-tenancy deployments, while Exchange and other more mature products are more client-server products bent to multi-tenant needs. There’s some truth to this from a design perspective, but this is important mostly for the systems administrator – not the end user. More specifically, I was able to manage our Zimbra instance via a fairly well designed Zimbra admin interface, while our Exchange instances were managed instead by host provided, heavily customized clients some of which were usable, and some of which were dramatically less so.
• Performance:
  Setting aside questions of which product “scales better”, as they tend to be complicated to answer, the question is as a user of both products which performs better. The question above indicates that Outlook is the client of choice, and I’ve noticed little difference in Exchange/Outlook versus Zimbra/Outlook performance. Which of the web interfaces, then, performs better?

  The fastest loading is unquestionably the non-IE OWA client, largely because it’s functionally very limited. Of IE OWA and the cross-platform Zimbra, I’d say that OWA loads more quickly, but not by a huge margin.

  Comfort levels with the Zimbra web clients’ performance will depend largely on the type of usage. If, like me, a given user simply opens an email tab once per day and operate out of that for hours, performance is likely to be more than acceptable. If, however, Zimbra is opened and closed periodically during the day, performance will be an issue as the initial load is not quick. That said, neither is the loading of Outlook.

What about the question, “based on your experience would you still recommend someone to migrate to Zimbra?” That depends. What I can say is that I can think of no reason that Zimbra should not receive serious consideration as a potential solution – nor Google Apps, actually. From there, it merely depends on what’s a good fit for your particular organization.