“Three years ago, your biggest risk was cloud; six years ago, your biggest risk was Open Stack. If you look at it now, you can clearly say, ‘Hey, these next-generation applications, are you going to be the enterprise supplier of choice?’. So in that sense, I think we had a bit of defensive risk … our platform was at risk.
“At the same time, if you look at the dollars, the business value at play in the developer layer — a lot of money there. It’s a very rich, offensive opportunity as well — both defense and offense — and if we expand the value proposition for all of the VMware operators today, to be able to effectively reach the developers and the application in a much more effective way than they do today … if we can bring those worlds together, that’s a pretty huge benefit for our customers as well.”
- How to use containers, even managing them.
- Being more autonomous – developers love freedom.
- Keeping up to date on skills (see containers).
- Dealing with or hiding from stupid business culture in their org.
- Getting permission to try new things.
- Testing code, automation to avoid legacy traps.
- More scalable architecture for distributed apps, new types of data stores for dealing with new types of apps. [Maybe Thought Works style radar thing]
- Modernizing old core and frameworks that they’re stuck with.
What else do they like talking and learning about?
That’s a lot of money.
“on the other side of the spectrum, purely enterprise-focused companies like IBM or Oracle would be tempted to wring every possible bit of profit out of the company…. What Microsoft wants is much fuzzier: it wants to be developers’ friend, in large part because it has no other option.”
Original source: The Cost of Developers
That’s a lot of money.
“on the other side of the spectrum, purely enterprise-focused companies like IBM or Oracle would be tempted to wring every possible bit of profit out of the company…. What Microsoft wants is much fuzzier: it wants to be developers’ friend, in large part because it has no other option.”
Original source: The Cost of Developers
“[Developers are ]not asking themselves, what are the ethical consequences of this? Who could get hurt by this? Who does this enable over another person? Who does this disadvantage or advantage? They’re not asking those questions. My goal is to have that part of the natural sequence of developing software.”
Original source: Why Software Developers Should Take Ethics Into Consideration
Yup, this is the thing: “I think this is actually a really important point to understand about remote work – on the remote teams I’ve been on, the the whole team has adopted a working style where all important team communication happens over Slack / video calls / email. IMO if your team is mostly remote, you’re forced to adopt a remote-first working style.”
Original source: Working remotely, 4 years in
‘Teams come into the dojo with a backlog of real work they are trying to deliver and are paired with DevOps coaches for six weeks. Some managers expect the teams to deliver these projects faster over the course over this period. Sometimes it happens, but Clanton explained it is really about building the skills that will allow them to deliver faster software and with better quality when they return to the office.’
Training by doing.
Original source: Creative ways to encourage the integration of DevOps processes
My co-worker Richard wrote up a laundry list of tactics to cultivate and maintain developer skills. It’s drawn from the tactics we’re seeing organizations put in place and a recent survey from the Cloud Foundry Foundation.
While I used to scoff at internal brown bags and workshops, I’ve seen those be highly effective in organizations looking to buff up at their developer skills. It both transmits actually new information and shows developers that the company actually cares. Upping morale and skills is hard to beat.
Also, it looks like the continual cross-training you get from pair programming is effective. Staff keeps up to date from the micro level of new keyboard short cuts to the big picture stuff like architectural patterns and domain knowledge. Plus, they learn and practice working together and trusting each other.
More survey findings
The developer survey that Richard kicks off with has some more interesting answers. Here’s some details from the survey:
– “By a nearly 2:1 margin, they are choosing training over hiring or outsourcing as the preferred method for addressing a shortage of skills in their own companies.”
– “We suspect that the companies further along in their cloud journey are doing more interesting things and are more risk tolerant; developers find those jobs more attractive. However, those companies that still primarily rely on legacy architectures, don’t push the envelope or are only very sluggishly making efforts toward digital transformation, struggle to hire and retain people that have the skills necessary.”
– “the majority of companies (62%) express confidence in the abilities of their developers to “keep current” with their IT knowledge and skills. At an individual level, however, only 47% of developers express confidence in their own ability to keep current.”
– “By a large percentage (60%), companies say they first adopt a technology—then upskill, train, or hire as necessary. This is preferred to selecting a new technology based on the skills already available in the company (40%).”
– “By and large, companies are addressing the shortage of skills by training or upskilling existing people rather than outsourcing (61% versus 39%) or hiring (62% versus 38%). They are making use of a variety of training methods from formal internal trainings, vendor-led trainings to informal trainings like ‘lunch-and-learns.'”
– It was done in 2016Q3, over 845 respondents in an online survey. “The survey divided respondents into four broad IT ‘roles’: Developer 30%, Operations 30%, Manager 20%, and Line of business leadership 20%.” And spread across geographies and industries.
That’s a big chunk of change. Developers don’t pay for anything, eh?
Including an estimate (11.5m?) of the number of developers globally.
“Only 20% of mobile developers target enterprises, but 46% of them makes over $10K per month, versus 19% for consumer-oriented developers.” The other thing to note is how close we are to having “mobile developers” just upgraded to simply “developers.”
CD enables us to deliver the business value inherent in new software releases to our customers more quickly. This capability helps the company to stay a step ahead of the competition, in today’s competitive economic environment.
We noticed that the frequent releases enable the application development teams to get faster feedback from the users of the applications. The feedback enables the teams to work only on the useful features. When a feature is found not useful, no further effort will be spent on it. This helps the team to build the right product.
Before, the team usually got to know the thing that they were building was not useful, until after the next big release. By that time, they had already spent months of efforts on it.
“Over 26k developers from 157 countries answered 45 questions.”
I find your lack of documentation disturbing.
I’ve talking with an old collegue about pitching a developer-based strategy recently. They’re tryin to convince their management chain to pay attention to developers to move their infrastructure sales. There’s a huge amount of “proof” an arguments you can make to do this, but my experience in these kinds of projects had taught me that, eventually, the executive in charge just has to take a leap of faith. There’s no perfect slide that proves developers matter. As with all great strategies, there’s a stack of work, but the final call has to be pure judgement, a leap of faith.
“Why are they using Amazon instead of our multi-billion dollar suite?”
You know the story. Many of the folks in the IT vendor world have had a great, multi-decade run in selling infrastructure (hardware and software). All the sudden (well, starting about ten years ago), this cloud stuff comes along, and then things look weird. Why aren’t they just using our products? To cap it off, you have Apple in mobile just screwing the crap out of the analagous incumbants there.
But, in cloud, if you’re not the leaders, you’re obsssed with appealing to developers and operators. You know you can have a “go up the elevator” sale (sell to executives who mandate the use of technology), but you also see “down the elevator” people helping or hendering here. People complain about that SOAP interface, for some reason they like Docker before it’s even GA’ed, and they keep using these free tools instead of buying yours.
It’s not always the case that appealing to the “coal-facers” (developers and operators) is helpful, but chances are high that if you’re in the infrastructure part of the IT vendor world, you should think about it.
So, you have The Big Meeting. You lay out some charts, probably reference RedMonk here and there. And then the executive(s) still isn’t convinced. “Eh,” as one systems management vendor exec said to me most recently, “everyone knows developers don’t pay for anything.” And then, that’s the end.
There is no smoking gun
If you can’t use Microsoft, IBM, Apple, and open source itself (developers like it not just because it’s free, but because they actually like the tools!) as historic proof, you’re sort of lost. Perhaps someone has worked our a good, management consultant strategy-toned “lessons learned” from those companies, but I’ve never seen it. And belive me, I’ve spent months looking when I was at Dell working on strategy. Stephen O’Grady’s The New Kingmakers is great and has all the material, but it’s not in that much needed management consulting tone/style – maybe his upcoming book on Oracle will add to it.
Of course, if Microsoft and Apple don’t work out, don’t even think of deploying all the whacky consumer-space folks out like Twitter and Facebook, or something as detailed as Hudson/Jenkins or Oracle DB/MySQL/MariaDB.
I think SolarWinds might be an interesting example, and if Dell can figure out applying that model to their Software Group, it’d make a good case study. Both of these are not “developer” stories, but “operator” ones; same structural strategy.
Eventually, they just have to “get it”
All of this has lead me to believe that, eventually, the executives have to just take a leap of faith and “get it.” There’s only so much work you can do – slides and meetings – before you’re wasting your time if that epiphany doesn’t happen.
I don’t think of Uber as a force that dis-intermediates—as we olds used to say—transportation, but one that creates value for itself, its drivers, and its users, by developing a new layer that integrates them all with maximum utility. A very talented developer once told me that the secret to a world-beating service like Dropbox was to make something very, very complicated seem devastatingly simple. To me, uberizing meant trapping a series of innovative processes—phone-enabled geo-location, payments and driver management and distribution—into an app-accessible service.
That’s good framing. It’s not (just) removing a middleman, it’s better overall UX. One might even say “design.”
I often brow-beat people into the notion that “cloud is all about developers.” That’s hyperbolic – there’s actually a lot more to cloud than just supporting custom written software…and yet, that seems like the bulk of it. By “developers” I mean you’re running a SaaS (you’re a company who sells the SaaS, like an “ISV” would sell packaged software) or you’re a company that uses cloud-based applications to help run their business (think of online banking, or Uber, or mobile loyalty apps like the Starbuck’s app…or internal applications just used to help run a company).
“Developers” seem like one of the best work-loads for cloud and what cloud platforms are mostly oriented around (there’s some NFV stuff scurrying around in the OpenStack world which is possibly “a thing” – there’s also HPC/batch/Big Data/Hadoop which matches as well…I’d suggest that the second is just a stats nerd type of programming, sort of) What cloud doesn’t seem perfect for is running packaged software. That might work, but it seems like your best bang for the buck would be using it to run and support custom written applications. And then, you probably want DevOps.
This may seem obvious to many of you readers…however many of the conversations I get involved with as an analyst never talk about developers, ever. It’s worth pointing out, then, that unless The Point of your cloud project is to support developers, you’re probably doing it wrong (or know so well what you’re doing that you don’t need silly diagrams).
Footnote: there’s also what I’m going to start calling “The BlueBox Private Cloud Correction,” so named because they always chime in when I over simplify “private cloud” in public. Their point is that “private cloud” is a lot more complicated/expansive than just “on-premises cloud run by the company using the cloud.” I think they’re right. Remotely managed “private cloud” is a-OK in my book.
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.
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:
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
WTH: How do you see the path towards the software-defined Data centre?
AB: What I believe is driving this trend is that developers and organisations are looking to move extremely fast. Developers are getting used to the paradigm of going on AWS (Amazon Web Services) and getting resources immediately instead of weeks/months of provisioning time. That is the benchmark against which they are now holding their internal IT organisations.
They are benchmarking their IT organisation against AWS in terms of ease-of-use, agility and price. I think that is the fundamental macro trend that is driving the desire for the software defined data centre.
That feels right, and is probably missing some tricks (doing better analytics, new end-user devices, etc.), but hey, like I used to say cloud == speed.
I’ve been working on a large (30 pages in lovely PDF) report on developer relations and marketing, especially, though not exclusively, targeted at people like cloud and service providers who are discovering the need to cater to developers. It’s published now. As with most of my work, I’ve tried to inject a bunch pragmatic, tactical advice alongside just enough macro “trends and drivers” nonsense to make the case for why you should care and then how you should start planning what to do next.
The report is available for 451 clients, but here’s the key findings which summarize the meat-y parts of the report:
- Developers have played a large part in driving the success of companies like Microsoft and SAP, consumer websites like Facebook, and service providers like Amazon Web Services and DigitalOcean. These companies’ offerings can be traditional ISV software, SaaS,
infrastructure delivered as a cloud service, or even “Internet of Things” devices.
- While developers may emote a distaste for traditional marketing,they are actually very responsive to finely tuned developer relations and marketing programs. These programs revolve around understanding how developers fit into the offering’s strategies and plans, creating value propositions that appeal to the needs and desires of various types of developers, and ensuring that you “show up” to relevant developer communities.
- There are many developer communities, both on the Web and in real life; most of them will be third-party sites that are not under your control. However, as developer relations programs grow, gaining more budget and resources, building your own developer community may be beneficial.
- One of the strongest clusters of developer value propositions centers on speed and increasing productivity: getting software to production faster, ensuring very low barriers to entry to try out new technologies, and otherwise simply moving faster.
- “Content” (text, video, audio, documentation, and even source code) is one of the primary mediums for interacting with developers, and, depending on the type of content, it has many different applications in developer relations programs.
- There are many topics for content, but some of the more popular ones are educational materials about using your offering; “war stories” about how you solved a difficult problem; the story of how you made something (aka “sausage making”); commenting on industry trends and how your offering fits in; and case studies on how developers have used your offering. Documentation and source code are key types of content for developer relations programs.
- Documentation is a particularly important type of content – both “manuals” and narrations or tutorials that are in a more natural voice. With rare exception, every developer relations program should look at documentation as a core type of content. Source code and the social networks associated with sites like GitHub are also an important type of content that most developer relations programs should have.
- Conferences continue to be an effective engagement point for developer relations communities. They can range from large, vendor-centric events to small “unconferences.” Companies have reported to us that both types can be highly successful, depending on the tactics and conference.
You can always sign up for a trial to take being a client out for a spin.
Thanks to all the people who helped with it, esp. Claire Hunsaker and Barton George who were extremely generous with their time and suggestions, and of course my 451 colleagues who gave much input. The organizers of DevOpsDays Austin and SAP’s developer relations program staff we also very generous with their time and comments for the related case studies.
And, of course, I’m thankful for all that time I was lucky enough to spend at RedMonk pacing through the mechanics of getting non-developers to understand us nerds. If you haven’t read the seminal The New King Makers, go read that or much of this fancy PDF of mine will seem odd.
Another fun looking presentation from Andrew Shafer. He’s been doin’ a lot of ‘em lately.
I had a briefing with Serena a short while ago around the new release of their ALM product Dimensions. They’re interesting to talk with because of their conservative customer base: so it’s a good way to track mainstream adoption of emerging developer practices. Things seem to be moving along nicely there. Since changing PE hands, they seem to have a renewed interest in shipping new releases, which should be fun to watch as well.
451 clients can read the full report, but here’s the 451 Take:
While our research in devops shows strong interest in the market, with developers in the technology sector ‘getting it,’ mainstream adoption of devops (or even continuous delivery) practices is still lagging. Serena has long serviced a chunk of this ‘mainstream’ pool in the form of the more conservative developers in finance, insurance, defense and other highly regulated industries. These teams require maximal governance, risk and compliance trappings; often need to integrate with a variety of not-so-new tools and processes; and are looking for very safe bets when it comes to tool suites. Thus, a company like Serena, with more than 450 customers, is responsible for bringing new innovations in application life-cycle management (ALM) to these customers, and is seeking to do just that with the Dimensions 14 release. The reception should be good, if slow, since the technologies and practices in software development have been experiencing a pleasant refresh in recent years. Serena will have to contend with several competitors – like Atlassian and TaskTop, which are similarly bringing fresh takes on ALM to the market and increasingly looking to sell into conservative accounts.
If you’re not a client, you can always sign up for for a free trial.
We recently re-wired how we arrange our coverage areas (or “practices”) at 451 Research. Previously, I oversaw a big bucket called “Infrastructure Software,” which has now been split into two practices:
- Enterprise Platforms and Infrastructure Software – download this free PDF to for an overview, whose intro says: “The Enterprise Platforms channel covers the management and infrastructure software used by digital businesses. This channel contains systems management, cloud management, cloud platforms, cloud management, virtual desktop management and other infrastructure platforms such as visualization and operating systems. Historically, this software has been used to run and manage on-premises datacenters, starting with physical, then virtualized servers. Increasingly, as our market studies show, companies are considering building private clouds.”
- Development, DevOps, and Middleware (DDM) – download this free PDF for an overview, whose intro says: “The development, devops and middleware (DDM) channel covers the digital infrastructure used to design, develop, deploy and run the applications and services needed by an enterprise to run its business. It includes analysis of the technologies, practices, vendors and cloud services that are used to develop and integrate applications, fuel them with data, run them and keep them current. DDM examines recent and emerging trends that will affect how applications and services are to be delivered in the cloud, mobile, the Internet of Things and social-computing era.
As you can imagine, I’m most excited about the second area, "DDM” as we call it or, more simply put: developers. 451 hasn’t had a dedicated focus area on that for awhile – though folks like Jay Lyman and our mobile team have been covering developments there well – and it’s nice to start that back up.
Rather than build out your next Instagram or SnapChat knock-off, consider disrupting 30 years of clunky software with horrendous user interfaces. The office-drone masses will bless you for it.
I wanted to test out MindMeister, so I took some notes while I was reading two pieces on microservices yesterday:
I used to use mind maps as my primary note-taking tool when I had a free license to MindJet sometime ago, which was delightful. So far, I find MindMeister a little clunky due to be in a web browser (I think?), but it seems OK. It’d be hard to go away from the mixed markdown and rich text stuff I do in Evernote, but we’ll see.
This anecdote sums up an annoying problem on cloud marketing (and product management):
At the break I chatted with a somewhat bemused attendee who had come in the hope of learning about whether he should migrate some or all of his small company’s server requirements to Azure. I explained about Office 365 and Azure Active Directory which he said was more relevant to him than the intricacies of software development. It turns out that the Azure User Group is really about software development using Azure services, which is only one perspective on Microsoft’s cloud platform.
There are (at least!) two differer buyers for “cloud” now-a-days: the operations and admin staff who keep raw infrastructure an (packaged) applications up an running, the developer who wants to write new code and run deploy it to cloud services to run (or use those cloud services as middleware). Make sure you know which one you are – or which one you’re pitching to!
Of course, there’s “DevOps,” which seeks to conflate the two of them together, which makes it, I guess, a more efficient marketing construct.
And then there’s another group: actual end-users who just want services without all the Morlockian “infrastructure” crap. SaaS!
Once “cloud” and “IT” become synonymous, nailing all these and other fiddly segments is even more important.
“You guys keep asking about that [the IPO] . . . we try to slow down. I don’t think we could move any faster, I don’t think we feel any extra impetus to move faster,” Mr Cannon-Brookes said
“There is no time in the future by which it has to be done, it could never happen, we absolutely could do that. We are in the luxurious position that we have the two founders that are still in total control of the business, so when we feel the business is ready, from the perspective of our market and culturally, we can take that step.”
Evans Data’s Developer Marketing 2014 survey of 450 software developers showed that 19.3% (or approximately 3.5 million) developers worldwide are women, compared to the years between 2003 and 2009, when the percentage of female developers was in single digits.
Of note, if you do the math (thanks to @barton808 for correcting my bone-headed thinking) you get 17.5m developers world-wide.
One of my collegues at 451 asked if I’d be interested in taking over his column at The Register. Of course I would, that’s only about my favorite news outlet ever. My first column is up now, all about what feels to me like the re-emergence of the developer market (tools and middleware), a theme I’ve been puttering about with at 451 for those who’ve been following along.
Here’s the last bit of the column:
Will the developers finally pay for the tools they use to make their write and run software? In the consumer space of $19bn exits, oddly enough, perhaps not: many of the old ways hold true – there is still DIY pride and 20-year-olds with nothing better to do than code all night.
Outside of the Ramen-noodle-coated technology world, however, as more devices get IP addresses and need software accordingly, it’s not full-on bonkers to think that there will be more developers at “normal” companies. And that’s the meat-and-potatoes of any “infrastructure” play: the mainstream companies which would rather purchase tools and middleware than quickly polish off another cup of Ramen before firing up a bare-bones editor to type up yet another chunk of middleware from scratch.
I’ll be doing this monthly, so there’ll be something more up in April. If you still know how to spell RSS, here’s the feed for my pieces.
Some pundits may argue that it is also going up against Amazon Web Services, but this is not the case: at around 5,000 Intel-powered Dell and SuperMicro servers the company fields around five percent of Rackspace’s fleet, and at most one per cent of Amazon’s.
This funding caps off a period of torrential growth for the company. In January 2013, it had about 2,000 customers and by the end of the year it was closer to 100,000, Uretsky said.
Hey, that SoftLayer investment worked out well.
I just gave this presentation to the Ansible Meetup here in Austin. It’s, hopefully, a “living presentation” that I can roll through-out the year, freshening up next time. It gathers up key parts of 451’s quantitative work, included a fresh DevOps study, to noodle on the equation IT – SaaS = what? (Spoiler alert: As you, dear readers, would probably guess: the “what?” equals developers.)
The abstract: We all know that cloud is a big deal, and cloud-native production cultures like DevOps are increasing in interest and maturity. Wide-spread market-adoption of all this cloud fun is slowly creaking out beyond the hoodie-festooned set, a trend we rabidly follow at 451 Research. This short talk with provide a brief baseline of where we are with cloud and DevOps as seen through the analyst lens of end-user surveys, market observations, and plane old screw-ball analyst-think. It wraps up with a “so what?” to motivate folks to chase that “software is eating the world” unicorn dream.