Podcast: Redmonk's Stephen O'Grady on developers, The New Kingmakers

Redmonk co-founder Stephen O'Grady has a new book out, The New Kingmakers. It argues that developer influence has greatly increased because of open source and other reasons. I used to work with Stephen we we were both at Illuminata and he has great insights about how developers work and what they're interested in. I encourage everyone to read the book. The price is right (free), but you shouldn't take that as an indication of the book's value. It's a well-written, focused that should be read by anyone interested in how developers and their associated ecosystems have evolved.

I caught up with Stephen at Monkigras in London a couple of weeks ago. In this podcast, Stephen discusses the central thesis of his book and we spar a bit over the question of to what degree companies like Apple are really catering to the needs of developers (as opposed to the developers just going where the money is).

MP3 version (0:22:04)
OGG version (0:22:04)

Transcript:

Gordon Haff:  Hello, everyone. This is Gordon Haff, cloud evangelist with Red Hat. I'm sitting here with Stephen O'Grady, co‑founder of Redmonk and Boston Red Sox fanatic.

Stephen O'Grady: Indeed. How are you doing, Gordon?

Gordon:  Stephen, you just came out with a new book, "The New Kingmakers." First of all, congratulations. It's a lot of work. Maybe you could summarize the thesis of your book for us?

Stephen:  Essentially, the basic idea is actually pretty simple. What we've seen over the past decade is a number of different, related but distinct, technology trends in terms of things like open source. Things like cloud, software as a service, bring your own device. Which again, are related but quite distinct, have together conspired to introduce a shift in terms of the power structure. The net of that shift, ultimately, is that developers today are in control of their environment in ways that they simply were not a decade or more ago. They make their own decisions, as far as technology, and they don't have to ask for permission to get an operating system, get a database. With the cloud and with applications, to use an application they can go to software as a service.

To get hardware, they can go to the cloud. They're fundamentally enabled in a way that we really haven't seen before.

Gordon:  Can you give some specific examples?

Stephen:  The one that, I think, resonates with people probably the best is...I was a systems integrator before becoming an analyst. In the '90s, we would work with large businesses and small businesses. A couple startups here and there, to help them build out their technologies. If you think about the late '90s, one of the things that had to happen, for a startup to build out its infrastructure, was that they had to get funding because they needed to pay for a lot of technology. In other words, if you're going to start a business, typically one common pattern for businesses that wanted to scale out, would be...

They get hardware from Sun, who would also supply the operating system. They get a database from Oracle. They go out and get storage from somebody like EMC and so on. You look at the startups today and they're using a completely different stack. They're typically purchasing, essentially, infrastructure from a cloud provider, either Amazon or otherwise.

A lot of their infrastructure is free in terms of they're using Linux. They're using MySQL. They're using some combination of programming languages which are, themselves, open source. What that means is that the developers who used to have to ask permission to do anything, to start a business, or within the context of a larger business, to start a project.

They don't have to ask for permission anymore. They have all these tools. Really anything they want. Whether it's hardware, operating systems, database, virtualization layer, tools, there are lots of options available to them that cost nothing. Therefore don't require procurement. They don't require permission. Unfortunately for businesses, they're not necessarily subject...

They have the ability to bypass compliance, etc, restrictions and constraints. It's a very different environment than it was a decade ago.

Gordon:  To your last point, that's sort of an interesting one you bring up thought because it does raise the possibility of development being done in this ad hoc environment. Then when it comes to go into production, maybe that's not an easy process that hasn't been thought out.

Stephen:  Sure. It's sort of a recent trend. It's commonly referred to as Shadow IT or Rogue IT. What it refers to are pockets within an organization, who operate very independently and, in some cases, at odds with centralized IT. One exempt, you see this all the time in marketing departments. Marketing will go to IT and say, "Hey, I want a new site." Or, "I want an application that will track sales of my product." Or whatever. IT will come back and say, "That's fine. We'll get to that next year. We'll get to that in six months." The marketers say, "Look, this can't be that hard." In some cases they'll hire, but in many cases they find a couple of under‑utilized resources, in terms of developers, internally and they'll effectively spin up their own infrastructure.

They'll build this application. They'll build the website. They'll deploy it, essentially, with no input or help or assistance, et cetera, from IT. In the case of many marketing efforts, in this example, that's typically fine. You're not necessarily worried about the compliance implications or regulatory implications of sites like that where organizations are very concerned.

For example, if you're in finance, if you're in insurance, if you're in health care, most of your business is going to be subject to some form of regulation, some form of compliance requirements. If you have organizations that are, as I said, operating independently and paying less attention to these regulations and less attention to the constraints that are imposed for security reasons, or privacy and so on...

Then that poses an issue. That's an issue that a lot of businesses are concerned with today.

Gordon:  What do you see as a fix for that? Some hybrid IT management, in some way? I guess the challenge here is, don't throw the baby out with the bath water. Keep this flexibility while still meeting any regulatory and other things you have to meet.

Stephen:  You certainly don't want to throw the baby out with the bath water. Trying to push developers backwards is a bad plan for any number of reasons. Not least of which you'll probably lose some of your better resources, if you try to go backwards in time and make them subject to the same restrictions they were a decade ago. What we recommend, when we talk to people about this, is to try to understand why they're using these tools. In other words, why do people use the cloud? Again, there are many reasons. One of the simplest is the fact that you can deploy a server in 60 or 90 seconds. You contrast this versus centralized IT, who in many cases, is happy to be able to deploy a server in the same day...

That's a pretty big delta. If you're looking to reign in or at least gain some visibility into usage, you basically have two choices. You can try to say, "No, you can't do this and you can't use these tools." As I've said, that's an effort, in my opinion, doomed to failure in most cases.

The alternative is to say, "I understand that there are reasons and very legitimate business reasons that you're doing what you're doing. I'm going to try to go along with that program as much as I can. In return for that, I want visibility into what's going on." In other words, trying to meet developers halfway and having them do the same.

We've actually seen businesses do this where rather than trying to ban use of Amazon. They say, "That's fine. But is has to go on our central account." At that point, the developer gets to use Amazon and IT gets the advantage of at least knowing what they're consuming by having centralized billing and allocation. Those are the kinds of tradeoffs I would expect businesses to make moving forward.

Gordon:  What role do you see platform as a service has going forward, in terms development of enterprise applications, in terms of enabling developers?

Stephen:  My old colleague, Michael Coté, came up with a model for cloud services that we love. It basically is... His original thought looks like a cheeseburger. You have a couple pieces of bread and a burger in the middle. Ultimately, the model tries to explain software as a service, infrastructure as a service and platform as a service. It was addressing them according to their equivalents. As an example, Software as a Service, we consider quite accurately to be the modern manifestation of applications. Back in the day, when you might have a PeopleSoft… or all these applications that somebody would come and deploy, instead now you consume them as a service, in a browser. Infrastructure as a service looks a lot like what we used to just call traditional infrastructure.

Servers and storage and all the other pieces associated. Platform as a Service...Ultimately, the closest equivalent, in terms of the architectures that we're most familiar with, is middleware. It's a container that tries to make your application portable, from environment to environment, platform to platform, and so on. Longer term, I think that's the potential.

It isn't there yet. In the sense that we haven't seen developers really embrace these platforms in a volume sense. We've seen very specific and tactical interest. But none of them have the visibility of, for example, the old LAMP stack. None of them are that far along in that process. But over time, that's ultimately the role that we expect them to play in any infrastructure setting.

As I said, it's the need for a container that makes it easier. Not easy, but easier to port an application from one place to another, more easily...The demand for that will always be there.

Gordon:  I wouldn't be analyst and indeed former colleague of yours, Stephen, if I didn't push back on your thesis at least a little bit. In your book you give Apple as an example of a company that has embraced developers, in a sense. Taking out the cover web page in iTunes to thank the developers for all the money they've brought Apple which, indeed, they have. But in fact Apple's been pretty widely criticized for rather unfriendly developer practices. Like, "Maybe they'll approve my app. Maybe they won't. And they won't tell me why." In fact, aren't developers just going to a company like Apple for the same reason Willie Sutton went to banks, because that's where the money is?

Stephen:  Chris DiBona, from Google, said it very well. He was talking about Android, but I think the same is true about Apple. Which is, there's a linear relationship between developer interest and the number of devices that are shipped. We see this with Apple's interest in devices like the iPad, the iPod Touch and the iPhone. Ultimately, they ship a lot of them and developers are therefore interested. My contention, with Apple, isn't necessary that they're treating developers well. I think it's difficult, if not impossible, to make that argument. As you note, they have, in many cases, done the exact wrong thing, in terms of working with developers. Their behavior, with respect to the app store, has frustrated tons of developers.

But the interest is still there, because of the volume. My point, rather with Apple, at least in the context of the book, was that Apple at least understands enough the importance of developers, to do some things very right. One of those is taking out a full page ad on their website to thank developers which does two things.

First of all, superficially, and I don't generally believe that Apple has a genuine sentiment about developers. I think it's like any other business, self‑serving. But they understand the importance of developers. So they thank them. You get the benefit there. But more importantly, it also reminds them just how many devices have shipped.

That ad served the duel purpose of thanking developers on the one hand, and reminding them of how big the opportunity was at the same time. But at the end of the day, Apple's done many things right, with respect to development. They make the process of developing applications reasonably easy. They certainly make it easy to generate good looking applications.

A lot of the applications on the Apple Store are great looking. Apple's history with developers is uneven, but they've done more right than they've done wrong. I think their success reflects that.

Gordon:  And certainly their interaction with outside developers, compared to the traditional carrier model, that's a big difference.

Stephen:  Yeah. Frankly, I think that's one of the things that Apple is unappreciated for. In the sense that Apple broke, for the first time in the industry, the carrier lock on the customer. Apple controlled that relationship with the customer in ways that we haven't seen before. Very much like if we think back to music, Apple was the first technology company to stand up for users and say, "Look, yes we have these DRM technologies. But you can't just...We're not going to kowtow to the record company and let the record company dictate all the terms." The result of which is, basically, a non‑usable product. We saw that over and over again. Apple put their users first and that user relationship first, and fundamentally changed that. We've seen the same thing in the case of the iPhone. As you note, they've fundamentally broken that tight connection to the carrier.

Now Apple can have a relationship directly with developers that it wouldn't, for example, if it had to go through a carrier to manage that relationship with a developer.

Gordon:  At the end of the day, this isn't a Kumbaya world where developers rule everything. But if we look in the flow of history, compared to where things were 10, 15 years ago, it really is a different world?

Stephen:  It's a very different world and I think, for better and for worse, in some cases. Much more rapidly innovating world. When you remove the shackles from developers and you let them innovate at the speed that they want to innovate, not surprisingly, you're going to see a lot more innovation. That's going to continue.

Gordon:  Thank you very much, Stephen. Again, Stephen is the author of The New Kingmakers. Where can someone get this book?

Stephen:  All the information about the book, as well as links to it, is at thenewkingmakers.com.

Gordon:  Great, thank you, Stephen.

Stephen:  Thanks, Gordon.