This blog comments on a variety of technology news, trends, and products and how they connect. I'm in Red Hat's cloud product strategy group in my day job although I cover a broader set of topics here. This is a personal blog; the opinions are mine alone.

Forecast 2013 Registration - RT @opendatacenter: Enterprise tends to turn to private #cloud, but will it stay that way? @ghaff will discuss on a panel at #Forecast13:

Why Do Not Track is destined to fail (DNT is DOA) | getwired.com - "Rather than driving efforts like DNT, which fundamentally cannot occur (in the manner users think those words mean “do not track”), we’d do a lot better as an industry to drive standards that delineate what types of information a specific site or tracking engine like Google Analytics or Adobe’s Omniture products can collect on you. But even if you throw those back at users, they’ll be overwhelmed. Perhaps the best angle is to reinforce that no activity on the Internet is totally anonymous, and no matter how hard you try, you cannot ever completely prevent being tracked."

Thursday, May 23, 2013

"Going with your gut is out." That line, from Russell Reynolds Associates managing director Shawn Banerji, neatly summed up a big chunk of yesterday's MIT Sloan CIO Symposium. There was discussion of the computing side of things as well. I especially liked EMC CTO John Roese's description of public clouds evolving to a "chaotic" (as in heterogeneous/hybrid) pool of resources in which special purpose clouds would have specific functions. But the majority of the day revolved around data.

Not necessarily "big data" by the way. One panelist—Jack Norris of MapR—even remarked that the "big data term is probably short lived." But, rather, the pervasive use of data, in whatever form and at whatever speed, to drive decision-making. As Annabelle Bexiga, the CIO of financial services firm TIAA-CREF put it: "Big data is just a richer set of data. [It's a] natural evolution of where data is going."

Erik Brynjolfsson (above) is the Director of the MIT Center for Digital Business. He spoke to how the data explosion was a revolution of technology but was also (and required) a revolution in management.

He offered the example of publishing, described as historically a "culture of lunches"—which is to say a culture of hunches and people networks. But Amazon brought a culture of numbers to the industry. And things haven't been the same since.

A 2011 paper, which Brynjolfsson co-authored with Lorin Hitt and Heekyung Hellen Kim found that data-driven decision making at firms resulted in 5 percent higher productivity than at firms which weren't so data oriented.

Brynjolfsson also discussed what might be called ambient data, data collected almost incidentally from sources such as cell phone records. He offered the example of streetbump in Boston, which uses an iPhone app to find potholes. At the same time, he observed that the app did best at finding potholes in the Back Bay, Beacon Hill, and other relatively upscale Boston locales. Why? Because that's where iPhones predominate. As Sloan's Andrew McAfee would elaborate on in his closing keynote (paraphrasing science fiction author William Gibson), "the future is already here. It's just unevenly distributed."

The panel which Brynjolfsson moderated also touched on some of the privacy issues associated with this ambient data. The MIT Media Lab's Sandy Pentland told how a big data commons, created by French telco Orange, was used to reduce commuting times in the Ivory Coast by 10 percent by rearranging bus routes using location-based data from mobile phones. Pentland went on to note, with more of a bit of understatement, that this sort of thing is politically controversial in places like the UK.

For his closing keynote, Andrew McAfee (above) took as his jumping off point a fascinating graph that appears in Ian Morris' Why the West Rules—For Now. At the risk of offering up spoilers, the central thesis of the book is that, viewed from the perspective of today, the level of worldwide social development prior to the industrial revolution is effectively in the noise.

(Although McAfee didn't get into this, the answer to the book title's question is basically that the West was better positioned to create and take advantage of the industrial revolution when the factors making it possible came together. It's a great read. If nothing else, it's a good history of the world from the perspective of the Western and Eastern core.)

The industrial revolution had such an impact because it overcame the limitations of human muscles. (I suppose, given farm animals, it would be more accurate to say it overcame the limits of human and domesticated mammal muscles generally.) In any case, though, McAfee's thesis that that today we're starting to overcome the limitations of our individual minds.

He laid out four elements to this:

Cyborgs—as in new combinations of people and machines.

Open—which will define successful organizations in a variety of ways. (If you want to delve more deeply into this thought, I point you to a presentation I gave at ProductCamp Boston a few weeks back.)

Data-driven—because for the first time we have data-driven visibility in all sectors of the economy.

Evolving—for which McAfee offered the example of the car rental industry which evolved only incrementally since it was founded after the Second World War but has seen the introduction of radically new services made possible by the Web and mobile phones from Zipcar to Lyft.

So it's more than data. But data—along with the compute needed to operate on it and the networks needed to move things around and tie them together—is a common thread. Big challenges lie in gaining access to the right data, even within single organizations. Cutting across data silos was also a theme heard more than once throughout the day. Asking the right questions matters too. As McKinsey's Michael Chui summed up that thought: "Be data driven. But don't suck at it."

Making Big Data Technologies Work in the Enterprise - “A lot of the architectures and products that technology managers may have been accustomed to for traditional transactional activity don’t map well to a big-data world,” says Gordon Haff, corporate technology evangelist at Red Hat and the author of Computing Next, a book on cloud computing. “You very much need to think about an architecture in the context of big data.”

The Serious Superficiality of The Great Gatsby : The New Yorker - "Baz Luhrmann’s “The Great Gatsby” is lurid, shallow, glamorous, trashy, tasteless, seductive, sentimental, aloof, and artificial. It’s an excellent adaptation, in other words, of F. Scott Fitzgerald’s melodramatic American classic. Luhrmann, as expected, has turned “Gatsby” into a theme-park ride. But he’s done it in exactly the right way. He hasn’t tried to make the novel more respectable, intellectual, or realistic. Instead, he’s taken “The Great Gatsby” very seriously just as it is."

Thursday, May 16, 2013

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 popularly 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 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 slideware 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.

Another form of MOOC largely goes self-paced, 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 more- and less-structured forms 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 Coursera'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 answers, such as a numerical solution with 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 gathering dust somewhere. 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 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.

Obama Signs Open Data Executive Order: U.S. Government Data To Be Made Freely Available - Forbes - "The order states that “going forward, newly generated government data shall be made freely available in open, machine-readable formats, while appropriately safeguarding privacy, confidentiality, and security. This requirement will help the Federal government achieve the goal of making troves of previously inaccessible or unmanageable data easily available to entrepreneurs, innovators, researchers, and others who can use those data to generate new products and services, build businesses, and create jobs.”"

Project Open Data - "Data is a valuable national resource and a strategic asset to the U.S. Government, its partners, and the public. Managing this data as an asset and making it available, discoverable, and usable – in a word, open – not only strengthens our democracy and promotes efficiency and effectiveness in government, but also has the potential to create economic opportunity and improve citizens’ quality of life."

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.

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.

50 Years of Stupid Grammar Advice - The Chronicle Review - The Chronicle of Higher Education - "Notice what I am objecting to is not the style advice in Elements, which might best be described the way The Hitchhiker's Guide to the Galaxy describes Earth: mostly harmless. Some of the recommendations are vapid, like "Be clear" (how could one disagree?). Some are tautologous, like "Do not explain too much." (Explaining too much means explaining more than you should, so of course you shouldn't.) Many are useless, like "Omit needless words." (The students who know which words are needless don't need the instruction.) Even so, it doesn't hurt to lay such well-meant maxims before novice writers."

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.

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.

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.

About Me

I'm technology evangelist for Red Hat, the leading provider of commercial open source software. I'm a frequent speaker at customer and industry events. I also write extensively on and develop strategy for Red Hat’s hybrid cloud portfolio.

Prior to Red Hat, as an IT industry analyst, I wrote hundreds of research notes, was frequently quoted in publications such as The New York Times on a wide range of IT topics, and advised clients on product and marketing strategies. Among other hobbies, I do a lot of photography and enjoy the outdoors.