Thursday, May 16, 2013

My first MOOC (Massively Open Online Course)

Small icon hover

I recently completed my first Massively Online Online Course (MOOC), a term that presumably is at least passingly inspired by MMORGs, an online gaming genre that's most popularyl represented by World of Warcraft. 

The class was on Gamification and was well-taught by Wharton prof Kevin Werbach. But my focus here isn't to review or critique this particular class but, rather, to offer more general reactions to the instructional method. To reflect on what these courses seem to do well or at least handle relatively naturally, and what they struggle at. It's just a sample size of one—well, 1.5 actually as I'm currently taking a Data Science course that offers some additional insights—but I think it nonetheless exposes certain patterns.

I also encourage those interested in the topic to read Nathan Heller's "Is College Moving Online?" in the New Yorker, a thorough examination of the state of MOOCs and their potential effects on education—both for good and ill. 

The format

The format for Gamification—which it seems is fairly typical—is built around a series of lectures. These consist of fairly typical Powerpoint slides, typically with video of the instructor superimposed or off to the side in a small window. The production values are generally high and the combination of slide ware and video is engaging.

There's a syllabus with links to various articles and other (free) materials. Prof. Werbach actually has a book on the topic of Gamification but it wasn't required for the course. None of the Coursera courses I've taken a look at had much if any in the way of stuff to buy.

The course then had a series of multiple-choice quizzes and a multiple-choice final exam—plus three written assignments of increasing length and scoring weight. My current Data Science course likewise has a series of lectures. But, in this case, the score comes from a series of programming and other assignments that relate to lecture topics although they are more hands-on and practical.

Type of schedule

Gamification, like the course I'm currently taking, comes from Coursera, which has a large course catalog from a wide range of schools. It was started by two Stanford professors and has received $16 million in funding from Kleiner Perkins Caufield & Byers.

Coursera's model, like that of the non-profit edX, is to offer classes in more of less real-time—by which I mean, an eight week course has a fixed start date followed by an end date about eight weeks later. Depending on the class, there may be more or less flexibility in how closely students have to hew to a weekly schedule for assignments, quizzes, and the like. But, fundamentally, the class is on a calendar and you can't dip in and out on the basis of work or family obligations, travel schedules, and inclination. 

The downsides to this approach are obvious. There are a couple of classes I've considered but opted against because they overlapped periods when I would't have been able to devote much time to them.

On the other hand, after taking a class, I better appreciate why one might want to run a class to a schedule. Discussion boards, assignments (especially peer-graded ones—more on those in a bit), the availability of staff to answer course questions or address problems, and just getting forced into the "flow" of a class all require or at least greatly benefit from a schedule and associated incentive structure. (Education has a lot in common with a gamification system.)

In a related vein, I also better understand why you might not want to break a course into overly granular chunks, i.e. one or two week classes. I'm not just talking about any particular administrative overheads associated with putting a course in a catalog, but a broader set of transaction costs borne by all the participating actors such as figuring out how the class is run and understanding or dealing with prerequisites or tools. In many cases, it seems these would collectively just add too much overhead to a short course unless that course were more intensive than most people with a full-time job could undertake.

Does the fact that these Coursera courses so reflect the form and content of traditional university classes simply reflect tradition and the fact that much of the content was originally developed for such classes? Perhaps to a degree. On the other hand, whatever issues higher education may have today, it's also likely that not everything about traditional class instruction is wrong.

The MOOC alternative is to largely dispense with a class structure, even if related lectures still largely parallel the content of a semester of classes. Machine-graded quizzes can still exist, as can other types of computer- or self-evaluated assignments. Udacity, another VC-funded MOOC, follows this model today. 

Other types of online instruction that increasingly diverge from a true MOOC model include iTunes University and the many instructional videos on YouTube. More focused sites, such as Code Academy, teach specific skills.

I think both will have their place. Many of us have a limited ability to schedule courses that follow a fixed schedule and find the flexibility of watch-when-you-can attractive. At the same time, I appreciate the relative discipline and other potential benefits provided by a more formal course structure.

Grading and certification

Coursera, like edX, follows another aspect of most traditional university courses; it grades you. In Coursera's case, this takes the form of a Certificate of Completion based on your performance in various assignments and quizzes as determined by the individual class—70 percent in the case of Gamification. (Coursera is also starting to offer a "Verified" version for certain classes.) 

I suspect that, at this point, a Coursera certificate is more of a gamification element, i.e. a motivator, than something that's especially useful outside of Coursera. However, it's also true that Courser's business model will ultimately depend on being able to sell the ability to gain meaningful certifications—which means that they need to be able to grade.

Schools have, of course, been grading forever. But remember what the "M" in MOOC stands for? It's "massive," indicating that it's not at all unusual to have 50,000 people sign up for a MOOC. (Although far fewer will complete it.) It's obviously not practical for a professor and a few TAs to grade at that scale. In the future, I wouldn't be surprised to see hybrid models in which something "MOOC-like" is augmented with one-on-one and one-to-few interaction with professors and TAs for a fee—indeed we're starting to see examples of such—but let's stick to the subject at hand for today, given that what's actually being paid for starts to become a complicated question.

A couple observations about the state of grading in MOOCs.

Multiple choice works well, subject to the limitations of multiple choice. Given well-written questions, there's no more ambiguity than with any other multiple-choice exam. It's easy and instantaneously graded by computer. And modest feedback can be made available with respect to the answers. 

Computers also do well at grading freeform but well-bounded and unambiguous answer, such as a numerical solution that has only one correct response. It's "42" or it's wrong.

However, start talking more open-ended problems, even in quantitative topics like programming, and automated graders can start failing answers in unexpected ways. Without going into all the gory details, the autograder for the first assignment in my current data science course was highly sensitive to, for example, how the programmer chose to parse text fields and to any quirks in the output's format. While not fatal flaws, it's indicative of how automated grading challenges magnify exponentially the more creativity is allowed in solving an open-ended problem.

Also problematic is peer review. On the one hand, this offers a way for massive scale evaluation of freeform text in a way that it's hard for imagine computers tackling anytime soon. On the other hand, across a huge class with students of all ages, skills, language abilities, and interest, it's not hard to imagine that the evaluations can be… quirky—even given a relatively detailed scoring rubric. 

I didn't personally have a huge problem with my results. But it was obvious from the discussion boards that a lot of people took low evaluations made without comment and evaluations made with obvious disregard for the scoring instructions very personally. And it's worth observing that, given a large class, statistics suggests that some will have simple "bad luck" with those they draw to evaluate their written assignments—even given multiple graders, multiple assignments, and algorithms to screen bad actors.

At the current stage of MOOCs, I personally find it easy enough to shrug my shoulders and get on with things. I have lots of diploma and certificate things. But say a class has a written assignment contributing say, 33 percent of the grade. To the degree this grade has meaningful consequences for the student (for a resume or for tuition reimbursement if MOOCs start charging in some form), that's something of a problem. It's also fair to say that, real world significance aside, grades can have a motivating factor for many as well.

This hasn't been intended as an exhaustive look at the "grading issue" but it's been evident to me it's something that will have to be at least improved on—not that students are ever wholly happy about their grades—as MOOCs look to start collecting money from people and offering meaningful certifications.

Overall

I got a lot out of this course and it looks as if there's a lot of quality content out there—more certainly than I'll have time to dig into. I'm also happy to see both for-profit and non-profit initiatives probing at ways to make higher-education better and more efficient. 

What I don't have a real opinion on is what the effect of Coursera, edX, and their ilk will be. The effect will certainly be uneven although one wonders if some aspects of MOOCs can replace elements of classes even at elite institutions. (Though I'd note that we've had the technology to replace 500 student freshman lectures for at least a decade.) I do suspect, or at least hope, that MOOCs—or at least MOOC methodologies—can replace low-value-add broadcast education in many situations.

One of the reasons that this particular crystal ball is cloudy is that higher education is often this odd hybrid of credentials, socialization, and learning that can be impersonal, highly personalized, solitary, involving lots of peer interaction, or some combination all of those. MOOCs clearly don't address all those modes but it arguably can do a subset rather well.

 

Monday, May 13, 2013

Links for 05-13-2013

Podcast: Kinvey's Sravish Sridhar on Backend-as-a-service

One of the challenges with mobile app development is that they require a number of services, such as user authentication, that can take a lot of effort to develop--even though the requirements are largely common across many different mobile applications. Kinvey offers hosted services that mobile applications on clients can consume.

Listen to MP3 (0:16:26)
Listen to OGG (0:16:26)

Gordon Haff:  Hi, everyone. This is Gordon Haff, cloud evangelist with Red Hat. I'm sitting here with Shravish Sridhar, who is the founder and CEO of Kinvey, which is a backend app development platform. Greetings.
Sravish Sridhar:  Hey, Gordon. It's great to be here.
Gordon:  We actually used to work together for a while a few years back.
Sravish:  We did. I was always star‑struck by how awesome Gordon was. It's just funny that I'm now sitting at a podcast with him.
Gordon:  You're embarrassing me. Let's talk about your company. What is Backend as a Service?
Sravish:  Backend as a Service started with the premise that mobile and tablet developers need an entire backend stack to build really, really rich applications. In order to build these rich applications, they needed access to data, to push notifications, to file storage, and to interconnectivity with various other data end points like an Oracle database or a Salesforce CRM, et cetera. When you think about it, how is a mobile developer going to build this entire backend stack from scratch? That's what we do. We've taken the entire backend stack and provide it as a cloud service and tied it to iOS, Android, and JavaScript libraries so that it's easy for you to build mobile applications with them.
Gordon:  Really, when we were talking about app development these days, I think a lot of the time, if you're not talking about mobile, you're really ignoring the elephant in the room.
Sravish:  I fully agree. When we find people thinking about new user experiences, they're actually thinking of both mobile and web. They need to connect to their user where and when the user wants to connect to the information. And so, whether the user is mobile or sitting behind a desktop, you need to do both all the time from here on.
Gordon:  We'll talk a little bit more about exactly what your company does, but maybe for our listeners who may have heard various types of terms applied to this space. There's this idea of MEAPs for enterprise application platforms. Where do you fit into that space?
Sravish:  We get asked this question in two fronts. One is, we often get asked the question, "How is Backend as a Service different than Infrastructure as a Service or Platform as a Service?" The way we think about it is that Infrastructure as a Service provides you with hardware on demand and lets you scale it up and down. Platform as a Service lets you run applications, so it solves the hosting and scaling of the runtime, but you still have to build the entire backend if you want to have a backend stack.
We think about it as, Infrastructure as a Service and Platform as a Service helps you with the plumbing, so they're in the plumbing business, and Backend as a Service helps you with the data, so we're in the water business. If you look at mobile enterprise application platforms, or MEAPs, they started off about five or six years ago as classic on‑prem enterprise software.
It takes a lot of money and effort to install them, customize them, and learn how to use them, and they lock you in, into a specific, WYSIWYG, HTML5 SDK that each one of them have. As an enterprise, you don't have the flexibility to use any native or hybrid SDK of your choice.
Our philosophy is we want to deliver everything through the cloud, the entire backend stack through the cloud, securely bridge your enterprise backend systems, and do the whole thing through a self‑service mechanism so that any developer that you employ or that's part of a dev shop or an SI can use the platform immediately, day one, without any setup upfront.
Gordon:  Let's say I'm a mobile application developer. I'm developing for Android, developing for iOS, probably both platforms in many cases. I need to authenticate users. I maybe need some data store in the backend to maybe store information about my users across different instances of the application and so forth. What do I do?
Sravish:  You come to Kinvey, you sign up for an account, and we have this notion of add‑ons. An add‑on is a specific backend feature that you want. You can use us as the entire backend stack, for your entire application, or you can use us for only a handful of features. You would say you want user management, and in that case, you can use us either to authenticate your users via regular user name and passwords, or you can use any one of the numerous OAuth providers we work with, or you can use us to integrate with an LDAP or Active Directory system that you have. You can use us only for user management if you want, and that ties down to your mobile libraries. You can also turn on a data store, and that gives you a full data store as well as a file store, to store anything from data to large files and videos. You can also use us to run business logic or connect to your enterprise OAuth system.
It's essentially, you decide, as a developer, which backend features you want, you turn them on, and then you consume them through our libraries. The one nice thing that you get is, whether you use one feature or whether you use all the features, we have an in‑house mobile analytics platform, so we track all of your usage and tie them into identity of the users so you know who's doing what over time with your mobile application.
Gordon:  What would be the relationship with something like your Backend as a Service to, say, an on‑premise Platform as a Service, like OpenShift? How would you use those things together?
Sravish:  We find that relationship very important. The reason is we believe that mobile is one of the key drivers of cloud in the enterprise. As CIOs are championing mobile and tablet projects, they want to build those mobile and tablet projects using cloud infrastructure. A lot of the data that these mobile and tablet projects have to access is sitting inside the firewall. By partnering and working together with a company like OpenShift that provides both on‑prem as well as cloud‑based Platform as a Service, the enterprises have the flexibility to connect their data with Kinvey by running what we call a data link on these PaaS environments. It's completely secure. It stays on‑prem, running on OpenShift, and then can be consumed by the mobile developer through the library.
From a mobile‑developer standpoint, all that connectivity is abstracted. It's connected via their library into Kinvey, and Kinvey then connects to an on‑prem OpenShift environment and moves the data back and forth through OpenShift.
Gordon:  What's your business model here?
Sravish:  We are a classic cloud‑based subscription model. Customers pay us on a monthly basis, as long as their apps are alive. The kinds of research that we've done is, for a classic enterprise application, on average, enterprises spend anywhere from $250,000 to $500,000 per application per year, and this is to build it and then maintain it on an ongoing basis. With Kinvey and companies like OpenShift, the joint value proposition goes from a half a million dollars to closer to about $50K to $100K for an application. It's a substantial savings for the customer. They pay us anywhere from a few hundred to a few thousand dollars a month, as long as the app is live. It's a very small buy‑in for an enterprise to keep an application going.
Gordon:  You're very involved in the mobile‑development space. What are some of the interesting trends you see happening that our listeners might be interested in?
Sravish:  I think a couple of years ago, when folks were using Kinvey, we found that iOS was, by far, the number‑one platform people were building apps on. Now, we're seeing that Android and JavaScript applications are the fastest‑growing kinds of apps on Kinvey. We find a tremendous number of Java developers that are picking up Android and building Android apps. We find a large number of Web developers that are migrating to building HTML5‑based mobile applications and using tools like PhoneGap to create hybrid applications.
A big trend is the growing adoption of Android development and JavaScript‑based development. Then the other is enterprises are now making buying decisions today to build a standard mobile stack. Most enterprises are slowly and surely building out their mobile reference architecture, and as part of that, cloud is becoming an integral solution for how they deliver these mobile services.
The combination of growth in Android and JavaScript, as well as the growth in enterprise mobile applications, are two big trends that we're seeing today with our business.
Gordon:  That's actually interesting, because one of the things we at Red Hat are seeing with our OpenShift PaaS, in the enterprise space in particular, is a lot of organizations are really looking at PaaS to standardize their development work flows. Part of that is obviously having common sets of composable services that you can plug into your applications rather than writing a new authentication module every time you write an application.
Sravish:  That's absolutely right. The same explanation also exists for mobile. People want a standardized mechanism to build mobile applications. Part of the issue, quite frankly, is skills. If you go to an enterprise and say, "Who's building your mobile applications or tablet applications today?" very few of them have complete in house skills to build these mobile apps. And so, they are using SIs or dev agencies to build up these applications.
And so, they don't want to make the mistake where every project is built in a silo and then they have to deal with all this legacy. Instead, they're looking at what are these standardized building blocks that every stakeholder uses on a consistent basis to build the same kinds of mobile applications.
Gordon:  Of course, you talked about things like dev team security. There's a real risk if somebody who doesn't have the skills just sort of hacks something together.
Sravish:  Absolutely. In this BYOD world where data's sitting on an employee's device, security keys are sitting on people's devices, authentication tokens are sitting on people's devices. You need to make sure that you're providing all the developers, in house or outsourced, the same kinds of frameworks and rules so that you're ensuring that you have a secure application being built.
Gordon:  You mentioned BYOD and enterprise apps. Of course, historically you had enterprise apps that were very much designed for a specific type of client with some sort of proprietary data connect or going back to a specific backend. But today, you really have to develop apps, whether or not they actually end up running on a mobile device or not, so that they can run on a mobile device because really, the movement is towards having client side just being whatever and connecting to a backend.
Sravish:  I wholeheartedly agree. I think it's definitely a ubiquitous use case. People need access to data when and where they need it. As an enterprise, you can't decide anymore whether somebody should only have access on a desktop or not. Furthermore, it's not only connecting to one backend. I think enterprise thinking has changed, where they're thinking about, "How do I make my employees most efficient?" That includes connecting to multiple backends.
For example, it's no longer that I want to give my employee field Salesforce rep just a CRM app. I want to connect my CMS with my CRM so that, through this single app, my sales rep can not only update customer information but can also download and access presentation material or brochures that I want to show my customer when I'm talking to him or her.
Now, apps are getting sophisticated and connecting to multiple backend systems, but providing a much more streamlined capability through one application.
Gordon:  It's interesting, this mega trend of things coming from the consumer world, and enterprise certainly needing more things in terms of authentication and governance and audit and that kind of thing, but still, in many ways, being an outgrowth of the simplicity and so forth of the consumer area. Your company itself has kind of evolved from a B2C‑oriented business towards increasingly B2B.
Sravish:  Yeah, fair and absolutely. In fact, there's a parallel there. The parallel is we're all familiar with the phrase "consumerization of IT," where employees and enterprises want services to look and feel like the B2C applications that they're used to. I also feel that there is a thing called the "developerization of IT." I think developers today that work in big companies go and muck around with Amazon Web Services or other public services, and they know what self‑service looks and feels like. They're demanding the same level of usability for enterprise development tools in‑house.
I think it's forcing ISVs, like Red Hat and like Kinvey, to start providing its tools and its services in a completely documented, self‑service fashion, to make it really easy to stand up applications for customers.
Gordon:  I think the case can perhaps be overstated, but my former colleague, Stephen O'Grady, has a new book out called "The New Kingmakers," and the idea really being that developers really are increasingly in control of buying decisions within enterprises.
Sravish:  That's definitely true. In fact, a lot of our focus was building a strong developer community from day one for Kinvey. In the last two years, we've been able to do so. Now that we have an enterprise product that's up and running, a lot of these developers who are using us for their side projects and for their personal apps have contacted us and said, "Hey, we would love to see if you can come in and provide value in our day jobs."
And so, it's the folks that were using us for their side projects that are not becoming our proponents inside their companies.
Gordon:  That reflects what we've been doing with OpenShift as well. We've been putting a lot of energy into not only being open source but making that open source simple to consume and really putting a lot of energy into putting information for developers out there that isn't even necessarily product specific like how do you write a very geolocation aware type of application?
Sravish:  Totally. Examples, examples, examples. If developers can learn through your content, then they will start to create a brand affinity with you where they respect the fact that you're actually helping them with their skills and they're more in tune with wanting to work with your products.
Gordon:  Anything else you'd like to add?
Sravish:  No, this has been fantastic. The next time we chat, I look forward to a much more detailed integration on how OpenShift and Kinvey can work together.
Gordon:  That would be great. If our listeners want to get out there and try out your service, what do they do?
Sravish:  They go to Kinvey.com. K‑I‑N‑V‑E‑Y or you can just search for Backend as a Service on Google and we're the first link that shows up. You can sign up. It's free. You can start building mobile applications tomorrow.
Gordon:  That's great. Thanks for your time.

Sravish:  Thanks so much, Gordon.

Tuesday, May 07, 2013

Links for 05-07-2013

How Open is Eating the World (and what it means for marketing)

I gave this presentation at ProductCamp Boston last weekend. I confess to this not being an especially self-documenting deck. I'll try to get a video or narrated version up at some point. You can also download the PDF.


Friday, May 03, 2013

Book Review: Vintage Tomorrows

You probably know O'Reilly for their programming books. However, they also publish books in a variety on variously geeky themes—a number of which I've rather enjoyed. So I readily accepted their PR agency's offer to review a copy of Vintage Tomorrows: A Historian and a Futurist Journey Through Steampunk Into the Future of Technology. One author, James H. Carrott, is a freelance historian and former Xbox 360 hardware product manager. The other, Brian David Johnson, is a futurist at Intel. 

The steampunk themes explored in the book that resonated the greatest with me were those of exploration and making. 

The Victorian era—steampunk's nominal origin and venue—was a time of great scientific exploration and wonderment, when things like carbon arc lights were still marvels.

To light the sea underwater, there is a strong light or 'ships lantern'  in an exterior enclosure at the aft end of the top deck.  The enclosure is tall enough for Nemo to rest his elbows on it while he gazes on the surface of the ocean (perhaps 1.2 m or 47 inches) and the sides must be pretty nearly vertical, also.  The windows are Fresnel lenses with annular rings, like windows in lighthouses.  Fresnel lenses can be circular, square, or cylindrical, surrounding a light, so Verne may have had any of these in mind.  This light illuminates the sea all around the Nautilus so it is more a flood light than a search light with a narrow beam. The light source is an electrical carbon arc in a vacuum, with graphite points.   The exterior light or lantern of the  Nautilus  combines the best technology of Verne's day.

VintageTomorrows Cover 200x300

Claire Hummel says in the book that "I really love the Victorian sense of exploration, never giving up on exploring new things and new worlds. We have covered most of the planet but we still discover new deep sea creatures or go into outer space. That's why I like steampunk—at it's core it's about discovery and wonder."

According the authors of Vintage Tomorrows—and their many interviewees—steampunk is also a celebration of making, the antithesis to mass-produced, featureless goods. As Cory Doctorow puts it in an interview: "Technology should be tinkerable." This dovetails into ideas such as individuality, the ability to change, and the control over technology. 

As Carrott notes:

There was a time when you could take apart devices. A pocket watch is just one example. People took apart things like rotary phones, transistor radios and cigarette lighters. An ordinary person could take one of these apart, understand how it worked, and maybe even put it back together! Empowering, right? You were smarter than the device. You understood how it worked.

The book features lots of interesting interviews, rumination, and dinner party conversations around steampunk and vaguely related topics. I'm sure that I (and many of you) would have enjoyed being guests at those dinners and other events. 

That said, the prologue warns that "We couldn't tell this story in a traditional manner. It literally defied our every attempt. So we gave in and let it lead us."

In fact, the book is not really a narrative on the topic as you'd probably expect, but more of a journal or memoir about writing the book and filming the associated documentary. It doesn't really have a narrative flow as such. 

I also confess to finding that the style of Carrot's writing in particular—most of the book explicitly separates the voices of the two authors—often seemed to be about making interviews as much about himself as his subject:

"Well, there's something going on," he [science fiction author William Gibson] agreed. "There's something wider going on culturally that I don't identify with steampunk, but I think steampunk might be another slightly more exotic symptom of it."

I couldn't suppress a grin. Bill-freaking-Gibson (I know that's not his middle name) had just, without prompting or a direct question, affirmed the suspicions I'd voiced from the story of this project. There's something bigger going on. And that's what this chapter is really about—the something bigger.

Far from being unique, the above text typifies much of the book. It's not a case of an author occasionally personalizing some experience. It's about constant interjection.

Furthermore, the book makes frequent references to works such as Gibson's The Difference Engine, a book which the index tells me is mentioned on eight different pages. Yet, although it also profusely quotes Cory Doctorow's introduction to a 2010 edition of The Difference Engine, it nowhere really explains what it is about this work that makes it worthy of so much attention in a book about steampunk and how it relates to the various steampunk themes discussed throughout.

Such is probably the nature of interviews; interviewees don't always provide a lot of context for what is, to them, well-plowed ground. But that's the value of wrapping interviews with additional narrative and background. Of which there's too little here.

Ultimately, this book contains plenty of interesting—even fascinating—primary source material. And that may well be enough for someone with a strong interest in the topic at hand. It was (barely) for me. But I can't help feeling that Vintage Tomorrows succeeds better as source material for a book about a "journey through steampunk into the future of technology" than it is at being that book. 

Monday, April 29, 2013

Links for 04-29-2013

Thursday, April 25, 2013

Podcast: Gunnar Hellekson On PaaS and Cloud

Platform-as-a-Service offerings, such as Red Hat's OpenShift, provide a great way for government agencies to provide separation of roles (so that the scope of contractors, for example, can be narrowly defined). Red Hat public sector technology strategist Gunnar Hellekson also discusses how overall cloud adoption in government is proceeding, Red Hat Enterprise Linux FIPS 140-2 certification, and cloud in the Department of Defense.

Listen to MP3 (0:13:17)
Listen to OGG (0:13:17)

[Transcript]

Gordon Haff:  Hello everyone, this is Gordon Haff, cloud evangelist with Red Hat. I'm talking today with Gunnar Hellekson, who's the chief technology strategist for Red Hat in the government sector. Welcome, Gunner.

Gunnar Hellekson:  Thanks Gordon, it's great to be here.

Gordon: Lots of exciting things happening in the government space around cloud computing in general and PaaS specifically. Why don't you tell us a little bit about what's happening around DISA and the DoD?

Gunnar: Yeah, this is exciting for us. I know that you've talked about OpenShift a great deal on your show and certainly I've been talking a lot about OpenShift and the value of having a platform as a service, the value of having an open source platform as a service. DISA, the Defense Information Systems Agency, who acts‑you can think about them as the IT organization for the DoD. DISA stood up this program called STAX and STAX is a platform as a service.

A little while ago they stood up their first attempt at a platform as a service, they wrote it themselves, and it functioned pretty good. Then we had a meeting with them and we gave them the roadmap for OpenShift, and they said, well, that's our plans for the next two or three years, so let's see about getting OpenShift in our organization. Indeed that's what they did. Now STAX is available to anyone in the DoD and it's really, really exciting, actually, to have OpenShift now available to anyone with a CAC card. It's pretty cool.

Gordon: Maybe you could tell our listeners a little bit more about OpenShift and why it's particularly interesting in the government.

Gunnar: Sure. OpenShift, the first problem that it solves is it makes it really easy for developers to stand up a development environment. That is often a huge problem in the DoD. If you can imagine not just a Fortune 500 company but a Fortune 1 company trying to get anything done the bureaucracy is just unimaginable. It's not unusual for it to take six months for someone to stand up a server. In that environment if you're developer, especially if you're a young developer working with some of the new languages like Node.js or Ruby or Python and so on, waiting six months for a server is just‑well, it's out of the question.

What OpenShift allows them to do is basically have a pre‑certified, pre‑approved, standardized platform that they can stand up and allows them to just go on and go ahead with their work. That would be great if it was just helping the developers, but in the DoD you have this huge demand on the operational side of the house. You have security standards that you need to meet, you have contractual and procurement standards that you need to meet, and OpenShift actually helps on that side as well.
Because OpenShift allows the operations folks to define, OK, here's what Python looks like, here's what Ruby looks like, here's what Node looks like. They can very quickly stamp out a new version whenever a developer wants it. Really it keeps both parties really, really happy. The operational guys have the standardization that they need and the developers don't have to wait six months for a server.

Gordon: One of the ways I look at platform as a service, OpenShift, is this really nice abstraction layer, in that it keeps the stuff the developers care about separate from the things that the operations, the architects, arguably even the procurement people care about. That kind of, I don't know, firewall or level of abstraction or the wall between those can sometimes be very useful.

Gunnar: Oh, that's exactly right. That's especially true in government where almost all work is done by a contractor at one point or another. When you're a contractor it's very tempting to get your hooks into as much of the system as possible because that ensures subsequent work in later contracts. Right?
If I'm the guy who builds the system from everything from the plug and the wall up to the keyboard, well then I'm uniquely qualified to go take care of that system for the rest of its useful life. That's great for the integrators and great for the contractors. Not so great for the procurement folks and the government folks who really want a more competitive environment for their IT systems.

As you're saying, having this abstraction layer, having something divided between this is what's mine‑which is the OpenShift platform‑-and this is what's yours-‑which is the code that's running inside it. Having that division makes it a lot easier for procurement folks, actually, who seem to like it the most. It's procurement folks who like it, because they can now write the platform into their contracts and say, great, you can give us this capability but you're not allowed to give us anything that plugs into the wall, because we're going to provide that in a platform that we've already built, already approved, and already certified.

It's neat to see OpenShift‑-and this is one of the reasons why I think it's so, frankly disruptive in the DoD is because it is a tool that actually allows the government to change the way that it interacts with its contractors in a way that something as old and boring as Linux doesn't necessarily do.

Gordon: In a way I think this is a little bit funny, of course, because a lot of the early talk around PaaS, particularly the online services, were around this whole idea of DevOps and you didn't need to separate the responsibilities. You look at something like Netflix and you don't really have much in the way of dedicated, separate operations staff. Here we are with PaaS and the government really being used because it can, if you want it to, on an on‑premises solution like OpenShift Enterprise, really can actually enforce those differences in layers.

Gunnar: Yeah, that's right. A lot of the DevOps work that's being done today‑-and a lot of it is outstanding and provided a huge inspiration for OpenShift, obviously. But a lot of this work is around-‑I want to call it single purpose enterprises. It was developed in an environment where you have one application that was, that that's all the company did was build this one application. In that context it becomes relatively simple to do a DevOps approach. Once you reach something with the kind of sophistication and the number of moving parts as, say, the DoD as an example.

Hugely complex organization, a whole bunch of competing missions, a bunch of competing contractors, competing procurement shops, competing program offices. Suddenly being able to say, well this is what is operations, this is what is development, and let's stay out of each other's swim lanes, that becomes a lot more valuable. We can take all the lessons learned from the DevOps world and apply them to a more enterprise‑y context, I guess. That's how I think about OpenShift.

Gordon: Maybe we can talk briefly about adoption of cloud in government in general. You read periodically, seemingly when the tech press needs some exciting headline to get people to click on, that adoption of cloud in government isn't going as quickly as their former CIO mandated to happen. What's your perspective on the ground?

Gunnar: When Vivek Kundra first put down the cloud first policy‑-a lot of people don't realize it--it's the policy of the federal government to put something in a cloud first and only if you couldn't possibly put it into an existing cloud are you allowed to go buy new hardware. That rule has been in place for a number of years and helped the, there's a grand federal data center consolidation that's underway. By 2015 they're actually going to shut down 800 data centers around the country.

Obviously if you're going to do that you need to adopt cloud. But actually the big winner in the cloud first policy was virtualization. Was just, I'm consolidating a data center, I need to virtualize to take good advantage of my hardware. That's where we were for a while, as people were looking askance at public clouds and trying to figure out, well, what kind of workloads are allowed to be in there.

Since then the government's actually developed a set of rules for how and when you're allowed to use a public cloud. That's called FedRAMP. That process has actually mildly successful because it actually, it provides a set of relatively unambiguous rules, and it provides a process for approving a particular public provider for a government workload. That was absolutely necessary. Without that I don't think we'd see the kind of cloud adoption that we see today.

You have FedRAMP in place now, and what's interesting is‑I'm trying to remember who the analyst was. I think it was Simon Wardley who talks about cloud adoption being something that moves very, very slowly and then all at once. Just last week we had Terry Halvorsen, who's the CIO for the Navy. He put out guidance, policy guidance to his deputies that said that not only are we going to go to cloud first, we're actually going to go to public cloud first.

That is, unless you have a super‑good reason for not putting your workload out on Rackspace or Amazon or another public cloud provider, you better do it. Because the Navy can't afford to keep buying servers. Then he wrote for an internal publication called CHIPS, he actually wrote almost a case study on how they moved the Navy's website up to Amazon. With folks like the Navy adopting public cloud at this pace, you can imagine that many of the other agencies are going to follow right behind.
As soon as I say that, I'm also going to add my traditional caveat which is, trying to describe the US government as a single entity is a fool's errand. We're talking about literally thousands of IT shops, and they don't certainly don't move in lockstep. While we have Navy maybe reaching out in front in the adoption of cloud services, you've got other agencies who are still trying to figure out what the best approach to virtualization is. There's a broad spectrum and it's going to be a multi‑year story.

Gordon: Maybe you could tell our listeners about some of the new things that Red Hat's doing, or they're coming down the pike?

Gunnar: Yeah, so this is actually exciting news. A lot of people, at least folks in the government space know about this. We are huge supporters of the FIPS process, this is the Federal Information Processing Standard. There's one standard in particular, FIPS 140‑2, which tells everyone how they are supposed to implement cryptography. If I'm trying to keep something secret on a machine, I can't just write any software I want. I have to take that software and have it scrutinized by a third party and make sure that when I say I'm using the SHA‑2 256 algorithm that that's in fact the algorithm that I'm using.
We have actually been certified under FIPS a number of times with RHEL and just recently we rounded out the FIPS certifications for RHEL 6, so now people can have encrypted SSH sessions, encrypted networking, encrypted disc, and be assured that it's actually meeting the federal standards. Super‑excited and not a little bit relieved to finally have those certifications in our pocket. It's really great.

Gordon: That's great, Gunnar. Anything else you'd like to share with our audience?

Gunnar: No, no, this is great. I think that maybe the last thing I'll leave you with is, back in 2008 there was a lot of talk about open government. When the Obama administration came in everyone was talking about open government and how open source could help open government. People were skeptical about it, maybe, and just this week we got two proof points for folks to let them know how successful open source has been in government.

The first is that Black Duck released their annual survey of industry, more than 800 respondents to this and these are folks like director, CIO level. Government actually came out for the first time this year as the number one adopter of open source software, which I think is super cool. The second thing that came along was the government actually using open source to improve its mission. NASA ran a hack‑a‑thon for the International Space Station last week and they had, in this hack‑a‑thon, over 9,000 participants around the world, which I think is just staggering and a great example of what the government can do when they not only use open source but actually adopt open source methods to accomplish their missions. It's real exciting.

Gordon: Well that sounds great, Gunnar. Thanks for spending time with us.


Gunnar: Well thank you Gordon.