Fun with market sizing

I’ve spent a lot of time over the years working with cloud market-sizings, and occasioanlly on them. They’re always a bit whackadoodle and can be difficult to pull apart. But, so long as they’re consistent year of year, they do give a good intedication of momentum and a comparision to other markets. This is what you should be using emerging technology marketsizing for: just indications of which way the wind is blowing and how strong that wind is relative to other breezes.

All too often, strategy and M&A people (and other “MBA” types who’re doing valuations and finances, plus all the hangers on in the chattering classes) get obsssed with market-sizing as if they’re “real” and start to do things like include them as fundamental parts of their business plan, e.g., “we’re going to capture 1% of the cloud market this year!” The implication there is that if they don’t, they’ve failed…but when you realize how corny the market-sizing are, you realize that basing your yearly plan on an Excel macro is a poor use of time.

With that disclaiming context established, I love finding market sizing numbers. They’re fun once you get enough of them and can start figuring out the relative size of markets. Which is to say: how much money is being spent each year across the world on various types of technology.

PaaS

Platform-as-a-Service is one of the more tricky markets to size and has spun all sorts of directions over the years. It’s always the smallest of the three aaS’s, but the highest growth. Even worse, most PaaS market-sizing you see is for only public PaaS. I’ve heard that Gartner has consternated much about this over the years: if you insert a simple “r” into it, they have an on-premises category called CrEAP that sizes what, I think, is “private PaaS,” and I believe they’re fixing it up further.

However, the problem with sizing the PaaS market is asking what you’re sizing. There’s “PaaS from SaaS” offerings like Force.com and then so called “first generation” PaaSes like Heroku (also at Salesforce) and EngineYeard. Then there’s hosted development tools (all the CI services otu there) that, for some reason, show up in PaaS market-sizing. But now there’s all the private PaaS offerings that happen to also run as public PaaS (it turns out the enterprise market really likes private cloud as well as public). And then there’s trouble-makers like us at Pivotal who bristle at the notion of being called (just) a PaaS. Layer Docker, Mesos, kubernetes and all those folks in there…and you’re head should be spinning.

The composition of this market has changed dramatically over the years. My theory is that it’s not well “shaken out” (defined) yet and it’ll change more. So, when I get asked for PaaS market-sizing, I sigh a bit inside.

Getting to a helpful PaaS market-sizing

I think the best process is to thinking through a what PaaS is used for and then try to figure out how much money is spent on solving that problem, not the exact technologies used to solve it. To me, that gets to some indication (whether it’s a ceiling, floor, or mid-point, I don’t know) of how much money there is up to grabs if you’re selling PaaS.

To that end, I always like this chart from a recent Goldman PDF:

As you can infer from my over contextualizing above, I think most PaaS market-sizing is bunk, but this chart a good way of thinking through getting to answer. It compares traditional packaged software and on-premises hardware spend to IaaS and PaaS to show how it starts to erode into “non-cloud” IT. I’m not sure if IaaS and PaaS and public cloud only (it probaly is, which is problematic).

When using this chart, the voice over is something like “tracking this market is difficult at this moment, as any analyst will tell you. I like to use something like this chart as a guide for thinking about it. With PaaS, what you’re interested in is how much traditional IT teams writing cloud-native applications are taking over, and this is one swag at it. Notice that the growth rates are drastically different too: there’s little to no growth in traditional.

The other thing (since most analysts don’t track private PaaS) this suggests is that all the traditional middleware money switches over to all PaaS (public and private) at some point…at least all the “new” money, the growth. Or, at least, that it’s a rough heuristic. It could be less (prices go down with cloud, right? ;>) or it could be more (software eating the world X IT - SaaS = what? == more customer software development at companies leading to more spend on the application development category).

So, if you add up the traditional markets of Appdev and middleare, you get something like a $35-40bn market in 2018 or so, depending how exuberant or dower you want to be, for pubic and private PaaS. Again, that wet-finger-in-the-winding is “bunk,” but it tells you type of money you should think about. Assume that over the next 10 years most “appdev and middleware” spend converts to “PaaS” and then you’ve got something that looks less shitty than the PaaS market-sizing analysts do now-a-days…and more real, I think.

I had lunch with Israel Gat yesterday. Lobster bisque in a sourdough bread bowl, to answer your first question. We were talking about the concept of a “software defined business” (and I was complaining about how HEB needs more of that, if only to get digital Buddy Bucks).

The question came up, so will companies really do this “software defined business” stuff (that’s the phrase I like for “third platform," “digital enterprise,” horseman style jabber-jargon)?

Well, over the next 3 years, I think much of the marketing efforts in tech will converge on exactly that. This is what tech companies will try to sell and the “thought lordship” they’ll try to deploy into the market. I think it’ll actually be to the tremendous benefit of customers, not just a hustle. Soon the egg will become a chicken, and the chicken will start making demands on the egg. Which one is egg and chicken? Indeed! One can never tell the causation directionality in these things.)

Why will tech companies focus on software defined businesses as a growth driver? Well, it’s kind of the only area for growth, at least interesting growth. Keep in mind that if you’re a big, publicly traded company, you have to grow, you need to find new money sources. Last year’s revenue can’t just sit there, staying stable. Otherwise you’re toast because investors will want to allocate their money in companies that are growing, not shrinking (they’ll dump your stock, and but another). This is true for any business, but very true for technology companies.

Here’s my rough sense of revenue streams tech companies will have:

1. Consumer churn.

You know, you get a new mobile phone ever 2-3 years. Instead of subscribing to a cable package, you subscribe to HBO Go. (You sort of end up paying the same amount, but who’s paying that close of attention when there’s so new Game of Thrones episodes to watch?) You buy subscription services. Games.

Basically, the “not enterprise” market. This is what most tech press covers and talks about; it’s (sadly?) what we think of as “tech” now.

There’s growth in here, but it’s a totally different space than traditional, let alone “enterprise” tech. Microsoft finally seems to have figured this out, but meanwhile Apple, Google, and Facebook are gobbling up all the revenue and growth…not to mention all the new companies that have come along.

2. How much more ERP can there be?

Businesses still need a lot of software, but I’d argue that “systems of record” are probably well saturated at this point and low growth. This used to be the fuel of the tech sector, but if everyone has a system of record in place…how much more more spend can there be there each year? (I’m sure we could look up some IDC or Gartner numbers about single digit growth in these markets.) Not much. One area of interest is shifting over to SaaS, or:

3. Rip-n-replace cloud.

“Well, I guess I need to replace all this ‘legacy’ stuff with cloud.” You know in storage, compute, and maybe networking. There’s lots of hardware and infrastructure software churn here. In the software category, I’d put migrating your on-premises ERP/systems of record stuff to SaaS here as well: moving to Salesforce, Successfactors, etc. In a squishy analogy, things like Adobe transforming from licensed sales to subscription sales.

This is a long term play with lots of cash; for businesses though: do they end up with anything net-new? Have you actually tried to use Salesforce? It removes the hassle of having the manage your own CRM instance, but you still have to manage how your company uses the application…otherwise it’s baffling what’s going on in there. My point is: the company ends up kind of back where it was before the great rip-n-replace, just more optimized IT, with hopefully HTML5 and native mobile apps instead of Flex.

4. Software Defined Businesses.

Here, companies are looking to create new custom written software that helps run their businesses in new ways or creates entirely new business models. It’s the thing we at Pivotal target, what you see coming out of the IBM/Apple partnership (mostly - some of it just the next step in the great rewrite the UI every decade journey of green-screen->HTML 1.0->Flex->HTML5->Swift), and it’s what will benefit us people most: companies get new businesses and, thus, growth themselves, us individuals get companies using software more to hopefully make working with them suck less. You know: Uber and all that.

There’s lots of “drag” (secondary spending) that gets to #3 above: you know, you’re gonna need a platform for all that stuff, and the hardware and services around it…but instead of just ending up with the same IT-driven capabilities, you’ll have new capabilities in your business.

Portfolio Management

So, if you’re a tech company, and you’re looking at the 4 sources of cash and growth above, the fourth option looks pretty good. #1 means competing with Apple, Google, and Facebook and then a dog’s breakfast of lower margin goods below the UI layer. #2 and #3 are good, known quantities, but probably with single-digit growth, if not tricky waters to traverse in the lower cloud infrastructure layers.

Then you look at the other option: a wide open field of possibilities where you “go up the elevator” and avoid the Morlocks. Large tech companies have to do all of these, of course, but I suspect you’ll see most of the razzle-dazzle spread on the fourth.

Those cigar makers have nothing to do with this, but cool picture, huh?

I’m just about the give a short presentation on developer relations and marketing at our HCTS conference. For those who didn’t make it, here’re the slides and the “script” I typed out. As you may recall, I wrote a large report on this topic published back in August. It’s been fun talking with people about over recent months.

Lost presentation: Selling to Hoodie and the Sticker-Festooned - Building a Developer Relations Program to Win Over Developers as Paying Customers

I often type out a “script” for presentations, not something I actually read, but just something to figure out what to say. Here’s the script for this one:

HCTS Developers

Hello, I head up the infrastructure software team at 451. Part of that is focusing on software development, developers. Back when I did real work, I was a programmer for a decade, so to me, the old saw applies: the answer is developers, what was the question?

Slide 2

More seriously, if you study the IT industry as I do, you notice a common trend: developers seem to gravitate around successful vendors and platforms. Sure, there’s a chicken and egg, cause/coorelation issue, but if we look at some big names, it’s obvious that having the good graces and favors of developers is key to making money in for many technology companies.

In the 90s and 2000s, Microsoft’s was a developer powerhouse, and still is, with countless applications written on its platforms. AWS rose to prominence rapidly from nowhere largely fueled by developers desire to run application on their platform. Similarly, Softlayer (now owned by IBM), expertly targeted developers as a core constituency. And, of course, there’s Apple, which is really cheating as an analyst to use as proof of anything.

We’ll get to some lesser known examples, but the message here is clear: developers matter a lot in the technology world and learning how to “market” to them is key for many vendors in this space. That’s what this talk is about: how to market to developers.

Slide 3

Now, as much as I like to be hyperbolic and categorical, not all technology companies need to worry too much about developers. Aside from the obvious cases - you’re selling middleware, IaaS, or PaaS - there’s an interesting heuristic to use to figure out if developers matter to you. As this timeline from Geva Perry shows, the role of developers in IT buying has been enabled by friction removal in the IT procurement cycle. If I have to go through months of fancy steak dinners and procurement paperwork, developers will have less of a role. If I can just download a database, install it in the public cloud, and go, there’s virtually no friction…and developers will more and more be the primary movers for IT procurement decisions.

Again, metered IaaS is an obvious match, and PaaS, of course. Look at your go-to-market - really map out each step it takes from concept to quote to cash - and see how much friction there is. The less friction, the more likely developers will be an important constituency.

Slide 4

Here’s two examples of that Heuristic at work: DigitalOcean and Atlassian.

DigitalOcean is one of the handful of SSD-fueled cloud providers out there that developers are flocking to. They do excellent product and developer marketing. Just like there’s less friction when you remove spinning dishes, the IaaS nature of getting to a blinking cursor in minutes to near frictionless. Developers love the easy performance boost SSD brings and the love how easy it is to sign up. As our recent reports on them show, this has resulted in 30% m/m growth and rocketed DigitialOcean to the 5th largest hosting company in the world according to Netcraft.

Atlassian is another example. They’ve been at it for years, putting out developer tools (requirements tracking, version control, etc.). They’re famous for having “no sales” and instead have removed so much friction from their GTM that developers can easily get their tools. And the tools are good. As you can see, Atlassian has been able to grow revenue from $59m in 2010 to $149m in 2013. That’s amazing consider that, you know, “developers don’t pay for anything.”

Both of these companies are good at developer relations and marketing and have harnessed developers to grow revenue. Let’s look at some highlights from my recent report going over tactics.

Slide 5

First, let’s define the goal of developer relations and marketing. I borrow this idea from several folks in the field, and it’s that you want to establish your technology as the de facto standard. Think Windows, HTML, Linux, the LAMP stack, the iPhone. Each of these became one of the top short-list choices for developers. Not all of them were “industry standads,” or even the #1 in the market, but they became de factor standards.

The result is that developers do all these activities in my Smart Art here:

• they consider using your technology
• they try it out
• if they like it, they word of mouth it
• they’ll purchase it (if it’s available to buy)
• and they’ll use it

This is pretty classic stuff, but the point is focus your goals around establishing your technology as the de facto standard. You can do other things, but it’ll be more difficult: you’ll have to convince people that your “exotic” thing is needed, like high-end Unix boxes vs. Linux and Windows.

Slide 6:

How do you do this? A lot of hard work and time. Really. There are no simple solutions. As analysts marketers ask us for the quick wins a lot - esp. towards the end of the quarter and year ;)

To give you a sense of what a developer marketing program will look like, here’s some examples.

• You’ll do classic things like advertising
• You’ll provide white-paper level research to help developer understand and evaluate your offering
• Training is a large part of developer relations, and also a revenue opportunity: you’re indoctrinating people
• You’ll also need to understand developers needs. Right now, that has a lot to do with APIs and documentation for how to use them. APIs are becoming the de facto standard for how developers interact with platforms, and you’d better figure out your plan there. You’d think docs were obvious, but it’s shocking how often vendors miss this.
• At the code level, developer marketing is also often done in code. I call that “code as marketing.” You might source extenstion, do some biz-dev to get others to do it, or lucky enough that your community can do so.
• And there’s lots of publishing. Lots. The Internet is the primary channel to reach developers and stuffing that channel is all about content.

Staffing wise, this could be a partially dedicated person, but pretty quickly you’ll want someone fully dedicated who can keep all the threads going in their head. Also, they’ll start to establish a personal brand, credibility in the space. Developers actually like people, just developer-y people.

The team can obviously grow. SAP’s team is massive, and it has massive effect.

Slide 7

So, you’ve got a notion for what it looks like. How do you plan what to do?

Don’t just throw up a blog an start typing. Take some time to plan. Get some ice-tea and patinad table like these hipsters here and establish goals.

And don’t forget that you’re doing this for business reasons. Talk with sales to find out how you can help them with deal flow and closing. Talk with product management to see how you can be a bi-directional channel for driving product direction.

Know what you want to accomplish with your developer marketing program so you can measure and meter funding. Once you have the developer in hand, you need to pass them off to someone who can make money from them.

Obviously, you need to establish metrics so you can track progress and argue for more budget and corporate oxygen. I find that most people rarely base-line current performance how they’re currently doing before starting a new project, so that’s a good start: otherwise how do you know if it’s working or failing?

Finally, make sure you understand who “your” developers are. One off project lone wolves in coffee shops, startups, other vendors, enterprise developers? It drives what comes next.

Slide 8

So, what appeals to developers? It of course depends on how long their beard is.

More seriously, while there’s different types of developers, there are some core value props that usually work.

Developers like speed. They want to do more with less, they want things to compile quicker.

Many of them (not all!) want to try out new technologies. Their worth is all locked up in their head, so each time they learn something new, they become more valuable. Any many of them just like learning.

To that end, they like stability in their knowledge. It takes a long time to learn Java or node. They want the investment to pay off. Don’t be changing things around all the time.

They like solving riddles and puzzles. That’s what programming is, what tends to separate it from more “factory” like work.

The business side is simple: someone else comes up developers and tells them the requirements, what the code must do. This is where a lot of “enterprise grade” features come in like compliance, audit, and regulations. Developers generally don’t care about that, but they like satisfying the requirements.

And, while they may act - and dress - like they care, they care a great deal about getting paid. Those 128 gig iPhone 6 Pluses don’t pay for themselves. Developers rank themselves by pay like any one else. Money means freedom to developers, like most people.

Slide 9

Let’s close out by highlighting a few tactics from the report.

First, show up! Developers are very social, esp. online. There are numerous “communities” that they rely on for their work and entertainment. GitHub is popular, Hacker News, Stackoverflow, and numerous other sites. Large developer marketing programs like SAP even setup their own, highly successful communities.

We did a survey of the early mainstream DevOps market recently and found some interesting results there. Obviously we like the analyst reviews, but it also shows that “traditional” outlets are valuable to.

Find where developers are and go there.

Slide 10

So, when you show up, what’s the work product?

Content can take many forms. Blog posts are good, podcasts can work for certain types of developers if done right.

And look at everything as a “store front”: support forms, your docs, demos, and other “marketing material.” All of this, if tracked and experimented with properly is can the ether your developer marketing program flits about in.

Books can be oddly effective if you write one that’s a definitive “how to” of a narrow topic. I profile one on code reviewing that helped drive growth for SmartBear before it was acquired.

Presentations, webinars, and talks are always good as well. Check out what goes on daily at InfoQ. It’s documenting the tribal knowledge out there, which is incredibly valuable in a knowledge economy like developers.

Slide 11

Here’s some specific topic ideas, all of them good.

Let me highlight one, a wicked problem solved.

Back in 2012 when Thailand was flodded, Backblaze had a problem getting cheap hard-drives from its supplier. So they arranged employees to travel around the bay area and beyond to buy hard drives at CostCos and Best Buys. Developers loved this story. It’s a classic puzzle to solve in an almost subversive way. I know many, many developers who love and use Backblze.

Stories like this come out from other companies.

Also key is explaining your “philosophy” on the industry and even culture. To go back many years, as it was called then “37 Signals” used their philosophy of rebelling against Enterprise Java to help advance the adoption of rails and their own products.

Slide 12

So, other than reading my full report and doing crazy amounts of consulting with me, what are some tangible next steps?

• Understand how developers will drive revenue and growth. How do they fit into your value chain?
• Figure out who these developers are. There’s probably at least three types, if not more. Know them, and how long their beards are. And then go talk to them!
• Start with some cheap experiments. Have a beer and write-up what you think is wrong with how things are done; record a screen-cast of an obscure feature in your platform; rise-wash-repeat. Just do something!
• As you learn what works, get a regular cadence for content production. Blog posts, podcasts, docs, code, whatever works.
• Finally, never forget that your job is to move product. Engage with sales and product folks to fit into their pipelines and process. If you round up all this developer favor, how do you deliver that into your companies money makers?

Slide 13

So, that’s a really quick overview. If you like reading, there’s a full report on the topic available. There’s a lot more in there like:

• types of developers
• the role conferences play
• more on different channels and mediums, topic ideas and content
• and several large and mini-case studies of what’s been successful at for other companies.

Speaking of case studies, we’ve put together a panel of folks who’ve been successful at developer marketing and relations and we’re going to debrief them now to help you understand developers more.

This is the common OpenStack meme for coverage. Each Summit there’s more and more users - “customers” - but it will take a while before OpenStack is suddenly us an “overnight success.”

Looking at it from a different perspective, OpenStack is one of the biggest, new model for open source development: they’re iterating on the concept and mechanics of open source in new and novel ways, deep in bazaar mode vs. Fred Brook’s surgeon model, to mix metaphors and ages.

I think it’s best to think of OpenStack as a continuation of the Eclipse model, that isn’t really too explicit about it: the point of the overall effort is to provide and commoditize all the common components needed to make cloud software. The vendors - be try ISVs, service providers, or SIs - who take those common components make most of “the real” products (not all, of course). If there happens to be a fully functional cloud platform as a result apart from vendors, even better.

What’s incorrect in my comparison is that this doesn’t seem to be the explicit mission of the community. Indeed, I think holding back from a strong mission like that is intentional: and that’s where the OpenStack is more like the ASF. Unlike the ASF, the OpenStack community isn’t opposed to profit and business; those ASF guys seems allergic to it (which maps to their mission perfectly well).

Hence, it’s all sort of new. I don’t really know what “The Model” is yet.

See also Nancy’s piece on the meme.

The great OpenStack conundrum: with 15,000 members, why is adoption lagging?

Oracle announced that it’s putting OpenStack into Solaris, which is good fun. James Niccolai asked for my thoughts on the topic for his story. I hadn’t been briefed, so it was just speculation, but here’s the full text of what I sent over:

Solaris was always - and no doubt still is - technically advanced. For example, the zfs filesystem, dtrace, and zones were always tasty looking for Linux folks. At the end of the day, Solaris is a rock-solid UNIX system that got run over by Linux becoming equally rock solid: but Solaris is still what it’s always been, a solid operating system. Layering OpenStack over Solaris is a good step for Oracle who’s always been dodgy all the way up to Larry on cloud. I’m eager to see how the OpenStack community reacts to this - it’ll be all over the map (the first salvo will be to question Oracle’s genuineness, followed by “yeah, but how much will be open source?”), Oracle having a mixed reputation in the open source world, unfortunately. To pick one technology of interest: Docker is of course a darling of the cloud world for the last 6-7 months. Docker is built on Linux containers, which are painfully similar to Solaris zones. And since Docker is OpenStack…you can start to imagine that you’d be able to do Docker/container magic with Linux containers and/or Solaris zones. Then there’s zfs which has all sorts of file system magic: seeing how that gets applied to the OpenStack world will be interesting.

Finally, Oracle’s database and ERP portfolio is widely used in IT departments now. If Oracle gets to the point where you can run its database and ERP apps on OpenStack (even if it’s Oracle “proprietary” version vs. the Red Herring of “OpenStack mainline”) then that’s a big deal for the OpenStack world.

Here’s James full story.

Embedding OpenStack in Solaris - Press Pass

I spoke with a couple of reporters earlier this week on the partnerships between Google and VMware and Google and Citrix around supporting Windows XP on Chromebooks. VMware has $200 off Chromebook discount for business buyers, and Citrix has a discount as well. Both are deep into vying with each other around the Desktop-as-a-Service market and interested in dominating that market which is looking to be driven by a pretty simple need: providing a way to use Windows applications on non-Windows devices.

The role of Chromebooks in all of this is interesting: perhaps it’s the cheapest “non-Windows end-user device.” It hasn’t seen massive market-share, but has been growing quickly to something like 2-5%, to throw out a wild-guess driven broad range. (ABI and NPD have some recent Chromebook marketshare estimates as well.)

Amazon launched a DaaS offering recently as well, which I covered in a 451 report; VMware released their DaaS just a tad before Amazon; Citrix, of course, sells a DaaS platform to others who want to run it, and of course has its current virtual desktop empire.

Back to the press part! Both Kevin McLaughlin of CRN (his story) and Dan Kobialka of Talkin’ Cloud (his story) asked for my take on the VMware/Google partnership, and then on Citrix’s involvement. Here’s the amalgamation of my responses to them:

Last I saw somewhere in Twitter there’s something like a quarter of the market still running XP which is certainly significant. I’m not really sure how many customers would take advantage of switching over to DaaS: the time and expense to do so might be the same as just upgrading to Windows 7 depending on how grueling the process was.

When I look at VMware and Citrix (just announced) working with Chromebooks the impact is mostly about adding legitimacy to Chromebooks as a viable business tool. VMware’s partnership means that there’s one way to keep using Windows applications on Chromebooks, through Horizon via the Blast protocol. Citrix announced a similar partnership today as well. Both have a constellation of service provider partners who do Desktop-as-a-Service (VMware has it’s own DaaS as well), or enterprises could just use their own on-premise virtual desktop setups, which both vendors support as well.

I’m not sure how many Windows applications are out there, but there’s likely an uncountable amount ranging from older packaged software to custom written applications used inside the confines of corporate firewalls. Rewriting all of these applications to be pure HTML or native iOS and Android is sort of ludicrous at this point, so as things like BYOD and the spread of iOS and Android devices in the enterprise plays out, companies will need some way of accessing these Windows apps. Android and iOS have had the kind of virtual desktop support needed for awhile, and the Chromebook work that VMware and Citrix are doing here is making it so that Chromebooks can fit, technologically at least, into that corporate mix as well.

VMware and Citrix team-up with Google Chromebooks to run Windows apps - Press Pass

A few weeks ago, I talked with Chris Kanaracus for his story on Infor moving parts of their application portfolio to Amazon Web Services. Chris said this looked like a pretty strong endorsement for using AWS, and asked for my thoughts, which were:

Yes, this a nice vote a confidence for AWS. However, I think most SaaS companies would look at AWS as capable of being used like this. There might be questions about pricing long-term, but technologically it’s just a stack of middleware running on a bunch of servers. The larger bet by Infor is around that: do they want to align their application to Amazon’s services and cloud-based middleware? (Maybe they’re not and just using raw EC2, S3, etc…but you’d assume they’d want to use things like Red Shift and other services/middleware offered by Amazon).

What with the pricing war that Google is announcing right now (reducing cloud prices by 32% across the board for it’s Google Cloud offering, and deeper for some other services), Infor has to be thinking that the costs will be cheap. The longer-term hope is that their agility - measured by how fast they can code and releases features to their existing products, as well as modify how current features work - will increase as well. We all know in our guts that after 4-5 years, software is incredibly hard to change due to the code getting stale, supporting middleware being antiquated, and the difficulty of shifting around the underlying infrastructure. I’m not sure “cloud” will solve those problem, but hopefully it’ll make it a bit better.

(Enterprises tend to be more leery of relying on cloud and are feeding the current interest in “private cloud”, along with vendors who’d love to preserve that market. Enterprise FUD around public cloud is mostly because their needs are much different than ISVs/SaaSes: enterprises have 100’s, if not 1,000’s of applications behind their firewall that must be supported that may be technologically, culturally, or otherwise incompatible due to drivers like policies and regulations.)

Infor ERP moving products to AWS - Press Pass

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.

Press Pass: PaaS in 2014 (Pun!)

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.

Press Pass: GitHub Traffic Analytics Comments