As an analyst, you often gets asked and paid to provide press release quotes (see some of mine here, though the I haven’t been good at saving all of them). Yes, press releases are still widely done and used. As someone who write-up the tech world happenings, I actually find them handy. Knowing how a vendor talks about themselves is actually important for analyst work, and the good press releases are more like media kits that line up all the relevant facts and links to other sources…and there’s all the bad stuff too, that’s still floating around.
So, as an analyst, how do I do press release quotes?
In general (meaning I don’t always do this) I try not to reference the vendor in my press release quotes. Instead, if I believe it to be the case, I try to follow a format that points out the problem the vendor is solving and then say something along the lines of “there’s clearly market desire for products that address this problem” type of thing. However, if I truly believe that the product/vendor in question is somehow awesome (and, esp. if they have a track record) I’ll reference them directly.
Put another way: I try to make most of my press release quotes into just validating the problem the vendor is working on, and, if real, that there’s market potential there.
(And, yes, if the news, vendor, etc. in particular is BS, I don’t just stand there and say “this BS is awesome!” That can be a tricky situation.)
Paul Krill asked a few questions about the future of PaaS last month for an omnibus appdev article of his (it’s a nice round up!). Here’s the only slightly edited full reply I sent him:
Q: Does 451 Group see 2013 as a banner year for PaaS? If so, why?
PaaS has always had the issue of being “big next year.” The nature of PaaS has shifted around so many times that it’s little wonder it’s yet to achieve escape velocity. To my mind, PaaS has come to mean “integrated middle-ware and services developers use to run cloud applications,” and in that sense I think PaaS will have an interesting year in 2014. The tools and practices behind DevOps are reaching mainstream, and the fast rise of things like Docker and mainstream hocking of Cloud Foundry are all encouraging. I still think PaaS needs to evolve to something close to that looser middle-ware-as-a-service definition than the clearly defined and contained platforms we’ve seen in years past. One thing is for sure: developers are going to keep writing application destined to live on the cloud to support web and mobile apps. It’s unclear if they’ll chose classic ideas of PaaSes (Heroku, etc.) over assembling their own middle-ware stacks with the help of things like Chef, Puppet, and Docker.
Everything I hear from the buy side of the market indicates that they’re hungry for better ways of developing and delivering cloud applications (whether to support classic web apps, mobile, or analytics applications). To me, this means a big uptick in spending in the middle-ware and developer categories, or the PaaS part of the cloud market. Companies like Pivotal Labs are premised on this opportunity, and numerous other vendors seem convinced as well.
Q: From Forbes: “Platform-as-a-Service (PaaS) will attain a 41% CAGR through 2016, generating 24% of total cloud revenues. 71% of PaaS revenues will be generated by vendors over $75M in sales according to the study.” Does 451 still stand by these numbers?
As Greg Zwackman put it in Paul’s article:
Analysts at 451 Research also see improved prospects for PaaS. “For 2013, we are projecting well over 50 percent growth over 2012,” says 451 analyst Greg Zwakman. The research firm expects PaaS usage to grow 41 percent each year through 2016, to account for 24 percent of total cloud revenues.
My reply: I believe this segment of the market will grow fast and be a large part of spend. It’s clear that deploying custom written software is a large part of what cloud is used for, and developers are always looking for better mouse-traps. Also, included in these numbers if I’m right, are ALM (Application Life-cycle Management) and supporting services and tools. From what I can tell, developers are eager to move to cloud-hosted versions of these tools, and vendors like IBM are starting to respond as well.
Q: How does 451 define PaaS?
Here’s the official definition: “A PaaS is a cloud-enabled development platform designed to let developers interact with code and create running applications, without maintaining or operating the runtime.”
And the longer definition:
“PaaS is defined as a remotely hosted framework that supports the building, deployment and ongoing management of applications throughout their life-cycle (development, testing, deployment, runtime, hosting and delivery). PaaS provides the computing environment on top of the infrastructure where multiple applications share a single plat- form for development and deployment. It also provides all the tools necessary to build and deploy applications and services via a Web browser, and offers user-friendly functionality streamlining workflow collaboration and speeding up production and time to market. Included in this category are vendors that provide the entire stack of PaaS functionality and partner with third parties (i.e., hosters) for the infrastructure component, as well as those vendors that provide the infrastructure themselves. Cloud computing components of the PaaS marketplace we track include: PaaS From SaaS, Stand-Alone PaaS and Application Life-cycle Management as a Service (ALMaaS). Within the ALMaaS space, we categorize vendors in two sub-sectors: Pre-Production & Testing and Integration as a Service.”
Q: What’s next for PaaS in 2014?
This year the PaaS market needs to decide if the Cloud Foundry approach (a very loose, buffet of services that interlock together, reminiscent of J2EE vs. the more clearly defined approach you’d get on AppExchange or even Heroku) is the winner. Also, how something like Docker fits in, and by extension the idea of using Chef, Puppet, AnsibleWorks, and Salt instead of a PaaS are important. Put another way: do developers want to build their own stacks and control the configurations of them, or do they want to deploy into a more clearly defined “app server,” to use a Java analogy.
GitHub Traffic Analytics service gives developers insight into interest in their projects
Paul Krill asked for some quick input on GitHub’s newly released analytics. Here’s what I sent over for his story:
As the blog post says, it does look like fun, though pretty minor in the grand scheme of things. GitHub has been a major driver of getting the development community to care more about social interactions and collaborations, here, tracking who’s looking at your code and where they’re coming from - standard web analytics stuff. Before GitHub, most of the community around code was pretty faceless: it was just forum posts, really passive users and lurkers around the code. With things like this, and GitHub as a whole, developers can get a better sense for who’s interested in their work. Developers have been learning to use this kind of meta-data in their applications to do A/B testing (is this feature better implemented one way or the other) and it’s interesting to think that they’d do some meta-data navel-gazing on their own code.
Another class of user - marketers - would find this extremely valuable. I like to throw out the idea of “code as marketing” to illustrate the idea that code can be a good source for driving a vendor’s marketing needs. As an example, you can see Rackspace putting out command line tools and other developer SDK-ish things to market to developers. More than just “tools” to use on Rackspace’s cloud, this code is a marketing artifact. Since code is, essentially, the major currency of developers, if you want to do more marketing to them, you need to spray more code their way, hopefully that’s useful. In that instance, marketers will want to intimately track who looks at what on sites like GitHub, and this will give them an even more complete picture.