1
>>: So I think I kick it off. Today is an awesome day. It is the publishing
date of the book Interop. So very special to have John here, and it is also
Venus is doing something crazy in the sky. I think it's like passing by the
sun or something. Not quite sure. But we wouldn't know here.
Anyway, just want to welcome you all. Thanks for coming to the lecture series,
and we're super lucky to have John here. John is awesome. He helped found the
Berkman Center and he is an expert on sort of the internet and society and how
it impacts youth and how these interconnected systems are really changing the
way we live and provide all kinds of new opportunities and challenges.
And so he's a good friend of lots of us here, and I just want to thank you for
coming.
>> John Palfrey:
>>:
Thank you.
So welcome.
>> John Palfrey: Thank you, thank you. Lily, thank you so much. This is a
real pleasure to be here. This is no surprise, at least from my perspective,
that I'm here in Seattle and at Microsoft on publication date, because,
actually, this book owes a lot to many of you who are in the room I'm a great
admirer of MSR and Lily, your lab, and everything going on here.
My great friend, Tom Reuben, who is consistently from your legal team come to
the Harvard Law School, even though he didn't graduate from Harvard Law School
to teach with us. And in particular, a group of people who are represented
here in the room from the Interop team at Microsoft, actually a lot of the work
on this book dates back to conversations from 2005 and 2006 with people here,
in particular Nick [indiscernible], who I'm deeply grateful for all the wisdom
he has shared with us on this topic over the years.
So it's a great pleasure to be here on pub date with all of you. We had a
funny experience earlier where some people on the team we were talking to had
bought the book on Kindle, but hadn't been able to read it, and Tom had the
old-school version of it, just like this, and it had been available much
earlier in analog hard copy. But for whatever reason, wasn't released on
Kindle until the publication date, until this morning. So yet another one of
the ironies, which is a little bit Interop related and we'll get back to that.
2
But I'm delighted that now it's available in digital form as well as analog and
that you're all here to talk about it.
I'm going to try to talk no more than about a half hour and hopefully have time
for some questions. I learn a ton when I'm here on this campus and I look
forward to today being no exception about that.
What I wanted to do by way of introduction of the book was to run through some
of the case studies that we have been using as the grist for the mill in making
the argument about interoperability. This is a book I wrote, I should note,
right off the bat, my better half in this effort is a man named Urs Gasser, who
is an incredibly good law professor. He's Swiss by background. He's now
executive director of the Berkman Center, but we've had a long partnership in
this effort, and he actually would give a better version of this talk were he
here. So I should acknowledge him before getting going too.
The source of this project does come from conversations here at Microsoft and
elsewhere in the IT space, and it started with a very basic question, which was
trying to answer whether or not this thing we often think of as a good thing,
interoperability is, in fact, a driver of innovation. That was the core
question. In the IT setting, if you have higher levels of interop, do you have
more innovation.
That's where we started and this, and I think the answer, after a bunch of
different work, was yes. By and large, higher levels of interoperability drive
higher levels of innovation. But the book project, the one that resulted in
this form of the argument, is trying to do something broader and more
ambitious. And admittedly, we might have failed. I will accept that it was so
ambitious in one respect that you can tell us that we've reached too far.
But the effort was to say that interoperability is something that
sense and is important on a campus like this one and has a lot to
technology and data. But the fact that it has more to do in many
other kinds of interoperability, with human interoperability, the
people work together and frankly how institutions work together.
like legal systems work together.
does make
do with
respects with
way that
How things
So what we're trying to do is make a broader argument about interoperability,
that is not just an IT story and, in fact, it's something that goes to the core
3
of many of the urgent problems that we're trying to solve today, climate
change, healthcare reform, and so forth. That's the much broader and more
ambitious argument that I'm going to try to make over the course of this half
hour, and I welcome your telling us that we've overreached or if we've gotten
it right.
I think no matter where you look after you get into interop, you see interop
stories everywhere. And I admit now, once you become sort of an interop geek,
it's sort of unstoppable. So it's a fair warning, don't read the book or think
too much about it if you don't want to start seeing interop everywhere you
turn. I'm going to give three examples that just have been in the paper in the
last few days.
I think the story about Facebook and its IPO, which is in some respects being
told as one about a valuation and whether or not it's really worth a hundred
billion dollars or 80 billion dollars or no matter what you guys got a good
deal when you invested in, I'm quite sure that that much is resolved. But most
of the discussion about Facebook has been the question of whether its ad sales
can support this valuation and so forth.
I actually think that it's an interop story in many respects. That one of the
reasons that, were I to invest in Facebook, it would be on the basis of the
extent to which their design has been, at least to a large extent, still to be
determined. But has been about building an interoperable platform that, when
they opened their very popular platform, two third party application developers
and had 4,000 applications developed in a short period after that, and the way
in which they have become so deeply ingrained in the mobile infrastructure and
the lives, frankly, of our kids, the people that Lily and I study, that it's
this degree of interoperability that Facebook has achieved at multiple levels
that has set it apart from things like Friendster and MySpace, which are
obviously worth zero. But also, I think, which set it apart from LinkedIn,
which is worth a mere $10 billion.
So I actually think there is a reason, a rationale in interoperability that
helps to explain part of that story.
Second, kind of ripped from the headlines example of this week, you may have
been following the flame virus and the extent to which Kaspersky labs' CEO, Mr.
Kaspersky, has been running around talking about this worst ever virus and the
extent to which the spread of it represents major cyber warfare threat and so
4
forth, and tieing that into discussions about how we need treaties to ban cyber
warfare.
I think this is hugely an interop story as well. That the story about the
ability for, whether it's a government or not, to unleash a certain amount of
code that then may have a threat to Iran, in this particular case, or any one
given geography, but which cannot be contained ultimately across multiple
boundaries is about interoperability. It's about the rush to interconnect up
to 200 countries around the world on a single network and the extent to which,
once we do that, there are potentially negative consequences.
So this is one of the rifts in the book, which is it is great to have interop,
by and large. There is a yay interop quality to the book. There is also a
quality that says be careful for what we wish for. When we have these highly
interoperable systems, that we also need to figure out what are the fire
breaks, what are the speed bumps that we erect at various different borders to
ensure the interoperability doesn't come with too high of a series of costs.
Third of three ripped from the headlines examples you may be following the
Greek Eurozone example, the idea that the failure of the banking system and the
public pension system and so forth in Greece is affect not just this one
relatively small company, but it is threatening the entire European Union and,
frankly, all of our economies.
Now, this is the part where we're reaching, obviously, a long way from this
notion of IT. But I actually think that in he's stories, we can see examples
of interoperability in the nation state context and in the international
context. And if you think about the way in which interoperability has occurred
in IT systems, it's not that dissimilar from the way in which it's developed in
financial systems as well.
If you think about economies that grew up on a local basis and a barter basis
and eventually you get some currency and trade within a given state, and then
you get to these much more interconnected systems where if you have something
like these derivatives that are being used and not well understood in one
place, it can affect economies way further afield. That's especially and
acutely so the case in the European Union. I think the EU is one of the best,
most amazing interop stories, good and bad, that we've seen yet. This is
obviously now much at the institutional level, not at the technology level.
But I think the risk level that we're seeing with the Greece is a good example
5
of the spread of interop more broadly.
Okay. So to back up and to try to ground the conversation, where we started,
again in this conversation with Nick and others, was to say this is in the
context of something like document formats or in the context of email systems.
What is interoperability. And adopted initially a very simple technical
definition. I think NIST has done a lot of work in coming up with very
complex, technical definitions. So if you really want the what is interop, I
send you over to NIST. But we've worked with this relatively simple one,
interop, as the ability to transfer and render useful data across systems,
including organizations, applications and components. That's our working
definition, what we mean by interop.
But I think again, as we look at the expanded play version, what we mean to be
the ultimate punch line here, we think of interop as the art and science of
working together. In fact, when we sold this book to Basic Books, I had the
subtitle as the art and science of working together. They thought it was too
namby-pamby, and no one would buy the book if it wonder the promise and perils
of highly interconnected systems.
However, I actually think that the art and science of working together is
really the essence of interop in this bigger and broader frame. So that's
where we started from.
And at I mentioned, the idea here was to work from a series of very technical
arguments and then expand the argument out. We have done this on the basis of
case studies. So those of you who are academics in the room or have been to
the question of methodology, we wanted to have a lot of empirical evidence, but
it's actually very hard to find good empirical evidence for the relationship
between interop and other things. So we ended up using very rich, in-depth
case studies and lots of interviews and so forth.
We've looked at music in particular, DRM-protected music is a great early
example. Mash-ups and lots of aspects of the social web, I think, are really
important. We did a lot of deep work on digital identity systems. In fact,
working earlier with Kim Cameron of Microsoft was a very big influence on our
thinking around identity and interoperability. And these are all papers that
we've published online.
And in many respects, the project of studying interoperability is not the book,
6
but rather what we think of as a very deep set of cases that are online. So if
you think about what is the book interoperability, it's in a way the summary of
a whole lot of arguments that we've put freely online. We've had a great
research team working with us. The book, in a way, is kind of only one cap
stone of that. And it's meant to be a single narrative. And a single
narrative that not academic and not geeky people would actually want to read.
And that's the far reach of what we're trying to accomplish with this book.
So I'm going to share with you just a couple of case studies that we thought to
be compelling. I'm going to leave out actually some of the biggest ones that
we have in the book. For instance, I actually think healthcare reform and the
electronic health records is one of the great examples. And if anybody here
worked in the vault projects or otherwise, I'd love to hear some of your
thoughts on it.
But one that I think is really revealing is this idea of the move toward smart
cities. So you know, half the people in the globe live in, one way or another
in an urban area. One of the big projects that many cities are working on is
trying to overlay a fair amount of intelligence into the network. And just as
one example, with the goal of trying to fight climate change.
So I actually think interop is a story about trying to solve some of the
hardest problems on the planet by using technology; in this case, the smart
grid, the overlay of information on top of the old-fashioned grid as well.
And from these different examples, like the smart cities or the smart grid, I
think we can draw a bunch of observations that are useful across a series of
different interoperability examples. Increasingly, when we try to solve a big
societal problem, take climate change, that we need an interoperability
strategy. If you're a public policy maker or you are a big utility in this
case, that you need to figure out how much interoperability you want, how you
want to put it into place.
And this goes to the core point about interoperability, which is it's not an
on/off switch. Interoperability is not either there or not there. It comes in
a variety of degrees. And I think historically, we have failed to see it as a
core design challenge when we're building some of these complex systems. I
think something like the smart cities example or the internet of things,
something I talked earlier today with one of the teams at Microsoft about, is
it's ultimately a design challenge. It's best handled at the outset of a big
7
project as a set of principles. As a framework for what we want to have.
What's good about it, what it can accomplish, but also how we can maximize
those benefits.
So ultimately, we're making argument in favor of interoperability, but not
maximal interoperability. Optimal interoperability at a certain level in order
to accomplish other benefits.
So the argument at its core is not about interop for its own sake, but rather
because it helps accomplish other benefits, three examples of what those
benefits are, and there are more, one is efficiency. I think most interop
solutions are driven because users want it for a variety of reasons. It makes
it more efficient that using your smartphone, you can access lots of different
platforms directly and that there's frustration if you don't.
Second, user autonomy and choice. The ability, of course, to have more choice
across a spectrum. And third, ultimately, I think we have found that our hunch
about the relationship between interoperability and innovation is right, that
boy and large, the higher levels of interoperability do lead to innovation and
economic growth.
But I think it's crucial to make that point that there are interoperability
solutions at multiple levels in a stack. As I mentioned before, technology and
data are crucial aspects of this in many cases. But ultimately, the harder
cases and, frankly, the more important aspects are often at these human and
institutional layers further up the stack. And with any of the interop
challenges, I think this model helps to break it down.
So that's example number one. Second example is open platforms, one that will
resonate here. And I should say any number of these, in fact, probably all of
them could be made as Microsoft examples. I've chosen not to do that since you
are my hosts. I thought that would be rude to be talking entirely about the
pros and cons of something that's so close to home. So I've used other ones.
But I think you could easily substitute.
I think much of the debate over the development of Facebook and how it has
emerged again is one about whether or not they are getting interoperability
right. And I think there are two narratives here that are emergent. One is to
say yes, they opened up their platformed for third party developers to be able
to create new applications and to create more innovation about it. Others
8
argue, no, they've gotten interoperability wrong, in a sense, which is they're
building another walled garden on top of the open web.
So I think that in the example of Facebook, you can see interop as a design
challenge playing out very directly.
I think second, Twitter is a really good example of it, in the sense that they
likewise have created an open platform, a web platform that is highly
interoperable in many respects, that both Facebook and Twitter have created
systems that function also as the identity layer for many people that you can
log into other applications via these things. This is another hallmark of
these open platforms. And yet, there are proprietary qualities to both. And
whether or not they are getting it right I think will have a huge impact on the
outcome of their companies.
Third example, and in some respects more profound, is the example. Of
Ushahidi. You may be familiar with this very, very open platform. This is one
that is open in every sense of the term. It was created by a graduate of the
Harvard Law School, I'm proud to say, Ory Okolloh, who hung out at the Berkman
Center, and she created a platform with her colleagues in Kenya that could be
used in particular in disaster circumstances to create support networks very,
very quickly using an extremely interoperable and open platform. This example
is one where a young man named Patrick Meyer sent out an email to a very large
number of people at tufts right after the Haiti disaster struck. And within
hours, they had set up this response system, helping people find help when they
were in need. Also figure out where infrastructure was having problems and
also where, in fact, certain people were when they had been lost. This was
something that could happen extremely quickly, totally unthinkable without this
very interoperable and open platform and one that could be turned on at a
moment's notice with no constraints and no intellectual property restrictions
to worry about.
From the sublime to the ridiculous, you can also see that in Harvard Square, if
you're looking for a place to go to the bathroom in public, safe2pee.org is
another example of these open platforms and it's actually pretty reliable.
We've found at least in our neighborhood.
Okay. So what can we glean from these open platforms? One of the things we've
been testing is this question of whether or not interoperability leads to
innovation via competition. And I think one thing that we can show looking at
9
the Facebook and Twitter type examples, but also the Ushahidi ones is that,
yes, that is a fairly straightforward relationship. But you could also make
the argument that it is interop leading to collaboration leading to innovation.
And that sometimes, the swapping out of that term actually makes as much sense
as not.
Second, we've been working, this is a truly geeky and academic thing to slide
in here, but working with how much our theory works with the theories of others
who have been trying to examine similar topics. So here are three, which I
think are actually totally compatible or interoperable theories with our own.
Our colleague, Jonathan Zittrain has written a book called the future of the
internet and how to stop it. At the core of his book is an argument about
generativity. The idea that we should favor platforms that allow for people to
create innovative things on top of them.
So the idea that generative platforms are the ones that we should protect.
He's famously written about the extent to which early Microsoft by allowing
executables to be written on top of it is a good example of a generative
platform. And rethinking what the terms of open mean and why we're actually
driving it. I think the design of generativity actually works well with this
interop theory.
Second, colleague named Eric Von Hippel, who works at MIT at the Sloan school
has done a lot of great work on user-driven innovation, peer innovation. I
think again, this is another example where the theory works very well,
compatibly, the notion that much of the innovation that we care about in this
new environment is actually driven by peers. This is very much what I think
Lily is working with in the new social platform is allowing for peers to do a
lot of the work together and to see a lot of the innovation as totally
unexpected. The designers of the system can't anticipate what that innovation
is going to be, put people who are interesting together and see what great
things come of it.
And third, most familiar, I think, of the theories, clay Christensen's designs
around small step innovations, I think, totally compatible with the findings
that we've had. Small caveat. I think that we've found in looking at these
examples is that the extent to which competition and a competitive behavior is
something to watch out for, particularly in the context of standards battles.
We spent a lot of time on this actually talking with some of your Microsoft
colleagues this morning that often, in an interop situation, you work very hard
10
to come to a standard, through an open standard process or otherwise, and there
can be still anti-competitive activity within that context. The holdout, for
instance, using patent and the Rand licensing regime which makes for not such
reasonable pricing is something to worry about.
So there's not a direct line between higher levels of interop and more
competitive situations. You can also have anti-competitive situations in that
context.
And I think you also can see instances in which innovation gets highly diffused
and where the relationship between higher levels of interoperability don't lead
directly to outcomes in the linear fashion that one might have hoped for.
Okay. Example number three I think makes another set of points about
interoperable systems. This is one that is now getting further afield from the
core IT zone, but which is the familiar area of credit cards. And so a recent
Pew study that helps us understand why people like credit cards and as you can
imagine, the primary thing is convenience.
This is, I think, a really good example of how we've gone from standalone
currencies to something that is extremely simple to use, and yet brings with it
some potential problems.
So if you think about credit card, they are fantastic in the sense of allowing
you to pay anywhere. As a great example of a deeply, deeply interoperable
system, you can be anywhere in the world and use a common payment mechanism
even if the underlying currencies haven't been made to be the same.
On the other hand, you have high concerns about things like privacy and
security. I think this is one of the key points about interop, no matter what
kind of context you're in, which is it often brings with it a series of new
concerns. The most common concerns that we've seen are privacy and security in
the IT context, but also diversity of systems.
So we make the argument that interop is about diversity. In fact, it's saying
not everything has to be the same in order for it to work together. On the
other hand, if things get incredibly interoperable, it often does become
homogenous. You get the opposite result from diversity.
On balance, though I think systems like credit cards show that it's worth the
11
risk. The fact that you can be more easily ripped off in some respects using
credit cards doesn't mean we don't continue to use them. It just means we have
to price that in and/or find new systems to be able to offset it.
But I think what it point to is at the outset, in an interop problem, you have
to assume that privacy and security, as well as things like diversity, may well
become a problem and you need to design for it at the outset. I think this is
one of the things that a company like Facebook and Google in particular, where
I think they have highly interoperable systems in many respects, Achilles heel,
their Achilles heel in both cases is consumer privacy and the fear that they
know too much about individuals and that's driving the way in which people are
starting to react against it.
So I think when you get to higher levels of interop, you need to presume that
some of these problems may come with it. Just to use a graphic illustration of
it, I think as we connect systems more completely, the point is not that it is
necessary less secure or less private. You can imagine a system in which you
have many, many -- you can think about a lab, phones. You can have a lab with
one door in that is extremely secure or not secure. You could have that same
lab with 100 doors to it, and it might be more or less secure. The fact of
having more points of contact doesn't make it more or less private or secure.
The point is just that you have to manage for higher level of complexity when
you do have interop.
So it's something that I think from the outset, as a design principle, needs to
be built in and I don't think it's inherently to say things that are
interoperable are less private or less secure. It's just that you know that
that's going to be a problem and one that you have to try to sort for.
Okay. Example number four. Mobile phone chargers. This is one that is less
for the technologists in the room but more just as kind of a way to talk about
it in a public sense. I don't know how many people have bags and bags of, you
know, different kind of mobile chargers. This one I bought earlier today for
the purpose of showing. It's the most ridiculous, like, Frankenstein thing
made by Duracell, and it says it's a five-in-one charger. And you can, you
know, I will throw out these other ones that don't work in my system and you
can use it in your car. You can use it in your, you know, whatever.
The notion that this is a product, right, that's sold at the Office Depot to me
is completely ridiculous, right. And we've got, you know, bags and bags of
12
them at home. How do we get to this point that there are so many different
kinds of chargers and we don't, in fact, do what's right for the environment
or, more simply, what's right for consumers. I think there's a really great
story behind these chargers.
Here are three silly examples. I don't know if you've seen these possible way
says to charge it. This is sort of a gas mask like thing that you wear, and
that will help charge your iPod. This one uses wind power. You can get the
wind to spin that around and that will charge it. And then this is my personal
favorite. This is the one that relies on your cat. If you get the cat to
chase that ball of yarn around, that will charge up your cell phone.
But it seems to me this is a really good example of the silliness of some of
the unfettered market in certain contexts. Achieving interoperability, even
though we can all laugh about why don't we have a relatively standardized mode
of charging our cell phones or other devices. But ultimately, I think it just
shows the difficulty of creating interoperability with nothing to do with
technology. This is not, obviously a technology story. It's not hard for us
to say okay, micro USB is the way to go. The issue is that there are a lot of
actors involved who each seem to have their own market incentives.
Second, which we see over and over again, these stories, there are legacy
providers who don't particularly want to make any adjustment to what they're
doing in any situation. And then third, the complexity solving the problem.
Given that there are so many different kind of cell phone chargers, what would
be the approach? How should we go about getting to a higher level of
interoperability?
And this is another one of the core findings of our work. Which is that there
isn't a single way to get to interoperability. We had a review of this book,
which came out the other day in Nature magazine, which I'm delighted about.
I'm grateful if anyone from Nature is watching, the fact this you spelled our
name right is fabulous. And we have a page in our great magazine about it.
But it was an overall positive review, but there were two criticisms. And one
criticism was that we didn't pay enough attention to the story of the web
itself and the importance of open standard and we do take this up and there's a
longer conversation there. We believe that open standards are a great way to
do it. But we don't believe that there is any single way to get to
interoperability.
13
And the second critique in this particular review, we were taken to task for
not giving a prescription for interoperability. How do you get to interop in
any given way, and the approach that we take in this book is to offer a
framework, a series of possible approaches in various different circumstances.
And I think ultimately that the example of cell phone chargers or others helps
to illustrate this point, which is there's not one way to make all cell phone
chargers, you know, more highly interoperable. The point is that there are a
range of options using the public sector and the private sector that can help
get there.
In the case of cell phone chargers, though we have a highly diverse, as we can
see from this nice Duracell product, array of ways to charge your cell phone in
the United States and still not a high degree of interoperability, in Europe
there's a much higher degree of interoperability around micro USB.
And the way that this worked was that the European commission said we are going
to legislate, if you guys don't get your act together. We actually see this as
an environmental problem. We see this as a market problem, and this was
legislation by threat or legislation by the form of a sword of Damocles held
above the companies. And telling them to get it done. This is much more
likely to happen in Europe, by the way, than in the U.S. from a regulatory
perspective.
But I think it's an example that shows there are multiple ways that we can get
there and, in fact, it's important to have them all on the table.
This is the most geeky slide that I will show, but this is, in some ways, the
heart of the argument of the book, which is looking at a very broad range of
possible ways to get at interoperability. On the top, you see generally going
in that direction are what we think of as unilateral approaches. The ones
going further down are more or less collaborative ones with multiple parties
participating.
And the chart goes in two other directions, left and right. To the left,
showing non-regulatory approaches, generally speaking, led by private actors.
And going to the right, ones that are more or less driven as regulatory
approaches by state actors.
14
And at the core of our argument is the notion that there are many ways to get
there, and in different circumstances, we should use different tools. And
there are benefits and costs of using each of these different approaches.
So in the bottom left are open standards initiatives, and I'm a big fan of open
standards initiatives. I actually think they can get to very stable outcomes
and have been terrific in the context of the web and the internet. But I think
they also are in play alongside something like IP licensing. You could have a
regime where the state is not involved and multiple parties come together and
say we're going to license technologies and make them work together.
I think it's implausible to argue that you can't get to a certain level of
higher interoperability by virtue of using this form of private ordering.
In the top right is the set of approaches that likewise could work, but that I
think we're most skeptical of in many instances, which is the state mandating a
particular standard. I think particularly in the case of information
technology, there aren't a lot of good instances where the state has done a
great job of saying this is the right standard and everybody should use it. On
the other hand, I should say there are some case studies, for instance, with
respect to emergency communication around boats, where I think it's a
reasonably good approach for the state to say, you know what? When you're in a
certain emergency situation, this is what you have to say. This is the rule
here.
There's not a lot at risk in terms of getting that wrong from an innovation
perspective, but there's a lot to be gained from saving people's lives by
virtue of the state stepping in.
So while I think that generally speaking, the kinds of approaches that are more
collaborative and more non-regulatory tend to work very well in the complex
systems like IT, I think we have to keep on the table that the fact that these
are all ways in which we can get ultimately to interop.
Okay. Last example. And then I'd love to get into a bit of dialogue, if
you're willing. This one is most near and dear in a way to my heart at the
moment. I'm working with some colleagues and friends in the room on this
topic, which is how libraries actually are an interop problem to some extent.
So this may seem not obvious. Take a little bit of time to spool it out. I
think there are two ways in which we can see a deeply embedded interop problem
15
in the preservation of knowledge. And I think there's one that's in the near
term and one that's in the longer term.
The topic for the near term is about the lending of books. So one of the
things that libraries are completely up in arms about today and very, very
worried, in particular public libraries but also academic libraries is the idea
that it is very hard, if not impossible, for them to get their hands on
electronic versions of books to be able to lend to patrons.
So just as we've seen in the market sense a knee in the curve, this huge uptick
in terms of people using and preferring e-books, libraries are having a hard
time getting them. So let me just out of curiosity if you were offered a
chance to read a new book, just take any old book, like this one or another
one, in an electronic format versus a print format, be curious, how many people
would read the e-book? How many people would take the hard copy book? So
almost exactly 50/50, which is interesting. It's trending, having done this a
lot for the last several years, trending very much more in this direction, that
it's more or less half.
But if you're a public library and you're saying, okay, I want to meet the
needs of our users, first of all, there's a problem of having to buy it in two
formats, because you end up paying twice, I'm sorry to say, to publishers.
This is a problem for libraries. They end up buying fewer titles in multiple
formats to meet the needs of their users.
But five of the six major publishers today will not sell a book to a library to
let them lend it as an e-book. Only Random House will let them do that on the
basis of you buy it, and you can lend it to one person at a time.
So five of six major publishers will not let any books be lent in this way.
And there are merging eco systems here that are not particularly interoperable.
For instance if you have a series of users, one has Nook, one has Kindle, one
has iPad and so forth, and you have very highly encumbered DRM systems for
these books, what's a library to do? How do you make a system that is, in
fact, free to all; that, in fact, is meeting the core job of libraries in the
digital era? It's sort of a perverse situation. It's actually worse in the
digital era than it is in the analog from the perspective of libraries.
And there's a version of this that is particularly worrisome over time, and I
think this is the other way in which libraries and books represent a really
16
good interop story. So sticking with the libraries for a second, one of the
things we fear is that as we spend our collection budgets, which are billions
of dollars a year around the world in terms of library collection budgets, we
are going from entities that buy books, like this, and put them in a storage
space and people can come and access them, which increasingly they don't want
to do, pulling them off the shelf in this way. But at least you have them.
You have them over time to ones who lease or rent those materials. And if you
stop paying the lease payment, you don't actually have the works, right.
This is a substantial problem over time for libraries, that they're really
struggling with. The other version of this problem is interoperability of the
formats over time. So if you think about three and a half inch floppy disks or
five and a quarter inch floppy disks, these things that change so quickly or
the little USB sticks today, think about the timeline over which we've had this
particular technology of a book, right. This has lasted for a thousand years
plus in some respects. Even micro forms, this is something that can last for
hundreds of years of format. But if our digital formats are lasting five years
or ten years, we're going to have potentially an issue if all publishers are
publishing in lots of different formats and then we get to a place in which
libraries don't have the materials themselves to bring forward. I think we
have a mess on our hands from the perspective of the presentation of knowledge
and again this weird, perverse situation that ultimately, it may be worse in a
digital era than in a physical era.
I think there's an interop solution to this interop problem as well, working
with several of the people in this room and many elsewhere on a project called
the digital public library of America and the idea would be, among other things
to create a place in which we would have deposits or repository of these works
in a digital format that, if the publishers didn't have it or otherwise, you
would have place you could do that reformatting in a common way other time. So
that if you have some way in which you can bring it forward, make it
interoperable over time, we'd be in a better space. Lily?
>>:
Do you have the same issue with music and videos and movies?
>> John Palfrey: You have almost exactly the same issue with music and with
video. In fact, the hardest case is the one that you are creating, Lily, in
your labs, which is interactivity. So to the extent that libraries
increasingly want to have, in their collection, things that are games or things
that are an interactive web space like social, is there some way in which one
17
could preserve that over time. That's
for libraries. There's a book about a
Double Fold, which takes librarians to
preserve interactive technologies over
actually one of the hardest cases of all
decade ago by Nicholas and Baker called
task for not figuring out how to
time.
And he's totally right. It has absolutely been unsolved by libraries up to
this point. So books is the simple case. It's you evocative because we love
books, right, and we want to be able to have them in some sense. But I think
it is, as you suggest, harder with the more engaging and sort of interactive
type technologies and it's hardest in the context of games.
>>:
Are you blaming this on technology or just business needs solving?
>> John Palfrey:
>>:
I'm not blaming anything on technology, I have to say.
You think it's all solvable?
>> John Palfrey: I think it's solvable. I think going back to our stack, I
think it's mostly an institutional problem and it's one that is a combination
of market drivers and the way in which things like copyright work which is I
think copyright is not flexible enough in this case to ensure that we have, you
know, a digital deposit copy somewhere that we could reformat in the public
interest should we need it, right. That just seems to me that's sort of an
institutional challenge.
So I think with most of these things, and this is not to diminish the work of
engineers who do huge, Herculean efforts to make things inter operate. I think
these are increasingly less technological and data type challenges and more
institutional ones, which is a big part of our book.
Okay. Back to a few hard questions and then I'll turn it over to you, because
you've already got great questions going. I think these are the kinds of
questions that to me are unresolved and come up in each of the hard interop
cases. But it's how much interoperability and for what purposes.
Fundamentally, I don't think it's about interoperability, per se. But it's
because we're trying to accomplish some other goal like the preservation of
knowledge or improving climate change.
How we get there, again, our thesis is that there are lots of different ways to
get there and it's a matter of trying to match the needs with the most
18
effective mechanisms for doing that. In particular, the role of government is,
I think, the most controversial and one where I think people disagree most
vehemently. Huge differences as we found between the U.S. and Europe and some
differences in Asia as well. Particularly around when should the governments
intervene. Should it intervene, in legal terms, ex-ante, before the fact, or
ex-post, after the fact.
Can it do so in a way that's legitimate and, in fact, appropriately. And can
they do it in a way that's, in fact, effective or efficient as compared to
various private solutions. I think the answer is in some cases yes and in many
cases not as effectively.
Near the end, how we think about the management of interoperability over time.
I think one of the reasons that certain solutions to interop work better than
others is because they may persist further over time. If you think about
something like small scale innovation within a single firm or where two firms
work together, that's a really, really good way to get to interoperability very
quickly. It may not be the most stable way to get to interoperability
ultimately over time.
And then last, to end with an academic challenge, it's actually a very hard
thing to make the case because there aren't great data. There aren't great,
for instance, empirical data across the board about what works so that we end
up having a methodological challenge and case study which means that on a
continuing basis, this is something that we have to keep working at and
continue to update the argument as time goes along.
Just as a very final note, and then to open it up, I think that for a company
like Microsoft or others in the IT space broadly, the core challenge from my
perspective is how to have the optimum level of interoperability across a bunch
of services where you are obviously able to compete and to charge for what
you're doing but also to create that ecosystem that ultimately is going to
serve everyone better than having a silent approach.
I think Microsoft's strategy in this respect is exemplary and we write a fair
amount about it in the book and how it's changed over time. I think also,
there's a huge challenge as we create these very interoperable systems to
ensure that things like privacy and security and diversity and lock-in don't
become bigger problems than the problem we had before and that we were solving
through the interoperability. So I think it's a crucial thing that you have
19
this interop team and that you're thinking about it at this really deep
intellectual level and I'm really grateful to have the chance to play out this
argument here in front of you and look forward to your hard questions. Thank
you so much. Yes, sir?
>>: So I was wondering if you could talk for a bit about the Oracle versus
Google litigation and how -- so just as sort of a case study, what did you
think about, and there's a lot of discussion in that case about embrace and
extend or embrace, extend, extinguish. What do you think about what Google did
from an interop perspective? They obviously are telling a good story, but
Oracle is saying bad interoperability in the sense of the ecosystem.
>> John Palfrey: I have read most about this from the court so this is a
lawyer's reaction, which is I've read court documents and I read the opinion
that came out yesterday. I don't know if you've read it, but I think it's a
wonderful opinion, actually, about 40 pages.
And ultimately, this was a big win for Google, as you may know, that the Court
said that across most of these claims, that Oracle may not persist with its
patent claims and its copyright claims. They found that there are nine lines
of code that were copied verbatim by Google engineers, which was a mistake.
There may or may not be statutory damages. And how those will play out, that
will still be discussed, I guess.
But ultimately, it was an exoneration for Google for how it's worked in this
particular context and it has mostly to do with java. I happen to side with
Google's argument on this one based on, again, the court documents and having
talked to a number of the lawyers involved. My sense is that with any of these
interoperability stories, there are two sides to it in the sense that one could
say this is an instance in which somebody is not paying appropriately for
intellectual property on the one hand or can say, you know, this was a
perfectly rational thing that somebody did in order to, you know, extend an
ecosystem because at these APIs and so forth, you have to be able to do this.
I think core to that matter and the reason why I think the judge got it right
is a little-known intellectual property thing called the merger doctrine, that
he mentions only twice, but I think there's something to it in this, which is
the judge said, among other things, if you can't get this work done but for
kind of in essence reverse engineering it and making it work, that there's not
a copy right that's protectable in this particular context. I don't think
20
that's the end all, be all to all these types of claims, but I think there's
something in it, which is in these highly interoperable systems, I don't think
we want a scenario in which we can't, in fact, do the kind of work that Google
did vis a vis java in that case.
Totally debatable as to whether or not that's good public policy, but I think
it ultimately was a great decision. I don't know if there are really fancy
lawyers in the room like Tom. I don't know if you'd disagree with that.
>>:
The floor is yours.
>> John Palfrey:
I would love to know if you think differently.
>>: I haven't read the decision yet, but there are certainly strong public
policy reasons why that kind of interoperability should be allowed.
>> John Palfrey:
Putting you in a hard spot.
Yes, ma'am?
>>: Yes. I would like the point you mentioned about privacy and security.
But there are other issues that I think [inaudible], because [indiscernible]
where censors are everywhere and things imposed upon people are not available.
So there is a security issue that's involved where you carry a phone. Some
people just say, okay, if I'm listening to talk over the phone or listen to a
friend talk, I got headaches. But there are other things more serious than
that. That is, say, you know, safeties that's not just the health issue, but
safety issue that is involved with [indiscernible].
It's the benefit that we know doctor can diagnose collaboratively just by, you
know, no matter where they are, where the patients are. They can do it. But
the [indiscernible]. It's almost like just described, you know. There are two
side of stories.
>> John Palfrey: Thank you. I don't know the research on whether having this
too close to my body is really going to be bad for me in 50 years or not. But
your point at its core is very well tone, which is that there are obvious
benefits, and we do rush to create interoperable systems. Part of our point,
of course, is to say let's also look at the outset at what the risks are and
see if we can design around them. If we can have interoperability that is
ultimately good and safe.
21
A simpler example may be of the safety concern is, you know, the texting in a
car or whatever else. We can be charging it in your phone, whatever, and be
effectively getting to a place more efficiently and communicating with friend.
But obviously, you may kill yourself by virtue of trying to text while you're
driving along. So I think there are lots of instances where whether or not, in
fact, the radiation from this is a safety issue. I think we need to be -- we
need to be concerned.
>>: Just on one of the things, I didn't hear a lot talked about, is the law on
intended consequences. Because usually, when we're developing, we're almost
like a car driving on a road. We're not like a plane looking at all the other
cars, all the other companies developing and doing everything. So later down
the road with he might realize, oh, we should have gone and done the following
things.
Even where we get to that point where we realize, oh, we should have put safety
lights here we should have done the following things and start to build the
system of interoperability, usually we've gone too far in our own journey and
we probably should have started from where we started.
And it gets more complicated, because now we've got to start talking to all
these different people.
>> John Palfrey:
Exactly right.
>>: And we immediately go to a base level, or I do anyway, where we go to the
law of kind of, you know, unintended consequences and edge cases and problems
that might arise and, you know, particularly when you're in a company, you
start to think about the legal consequences or compliance or censoring or
whatever. It gets more complicated.
Innovation is a horrible, icky business where you're not really seeing
everything until you're further down the road. And, you know, I see your whole
point about the problem of the four dimensions, but honestly, I don't know how
you devise a system that's forward thinking. Because most things are in the
rearview mirror.
>> John Palfrey: It's a great point, and I think it is intention with the way
in which we tend to innovate in this country, which is you try to just run like
hell and see what comes of it. And, in fact, I think that's a great way to
22
innovate in lots of labs. That's exactly what you do. I think there's only
one caveat I would put to this, which is I think it is worth having product
counsel around. I think the LCA model where you have some people who look
across the board at things like copyright and trade secret and trademark, and
you have some people who work with product groups and who at least just kind of
say, wait a minute, pay attention to this up front. And maybe if you do this
at the beginning, you'll save a huge amount down the road.
If you have smart people who understand the engineering and you understand the
law, I think there's more that can be done by very chew of that partnership and
I think it can be much cheaper. But your point is well taken, right. You
can't design for everything at the outset. You would never get the thing
going.
One of the really good examples that I like a lot from the interop stories is
about air traffic control. This is one that is, it's just an amazing
historical story. So you think about the Wright brothers take off and there
one plane and don't really need it. You start getting more planes. You need
to have more effective systems.
And what happens is you start having some rules that start to get made, and
start thinking about what language people need to talk to one another about and
you have radio helping to work that out. Ultimately, where we've gotten to is
a place where all of the people involved in air safety have to speak English.
Not only English, but a standardized form of English so there's no mistaking
it.
That's a form of interoperability at the linguistic layer that's developed over
time. It actually works pretty well. But one of the things we've found also
is that the interoperability has been locked in at a level from several decades
ago. So some people in the Obama administration really wanted to introduce
some things, pretty simple things like GPS into air traffic control. That
hasn't happened.
Some of the things that would be obvious reforms to air traffic control haven't
happened because we got to a place where it's kind of a locked-in level of
interoperability. It good enough interoperability, but it's not as good as it
could be, and there are lots of legacy reasons why we don't do that.
So your point is incredibly well taken.
I don't disagree.
23
>>: One thing about the legal part.
the publishers aren't playing.
That's the reason why five out of six of
>> John Palfrey: I think that's partly true and partly not true, having talked
to all those publishers about it. I think a lot of it is market risk. They
are fearful that if they start down a certain road, set aside what the law
says, that they will get locked into a version of selling books that is not as
good as other versions.
So just take for example one of the firms, you may know Harper Collins started
to sell books on a 26-lend basis. Does anybody know this story? They
basically said we will let a library lend. You can buy this book for
whatever -- what they were charging for it. What they said is you can lend it
26 times. I lend to it Lily and it gets lent to somebody else and so forth.
And then poof, okay, it goes away. DRM. And librarians went nuts over this,
because Harper Collins' theory was that the book would have been worn out after
26 lends. Because Lily reads it so hard. It's obviously stupid. But this was
sort of a market risk problem. They were so burned by this. They pull it
back. Obviously, the copyright law underlies a lot of this concern and lawyers
are definitely to blame. I think it's actually more the bis dev and the people
who figure out the big spreadsheet that are to blame in that case.
>>: Not picking on lawyers, but it's actually a bunch of people who are your
counsel of the business plus law. They're the people which decide, you know,
we're north going to go down this road. There's an unintended consequence here
that will boomerang back on us.
>> John Palfrey:
>>:
Did not work well, that's true.
I think that's true.
So Basic Books, do they have a different kind of policy?
>> John Palfrey: Basic Books sent a person to the meeting we held about this,
but I actually don't know what they've changed their policy.
>>: So we
understand
internally
difference
got in this whole thing about interoperability. I actually like
your definition of interoperability in its purest state, because
on the interop team, I was to go back and debate what's the
between interoperability, compatibility, 43 companies developed like
24
the DVD standard, the fact that you could take a DVD disk and put it in the
player and it's got the same logo, and it works, is that compatibility?
Because they're both following the same spec, or is that actually
interoperability?
So understand, like, written the book on it, what does interoperability mean to
you?
>> John Palfrey: So I put up the short definition that we had, which is about
rendering data usefully across systems. I think that the NIST definition, the
sort of longer technical one is pretty good. Ultimately, we're seeing
interoperability, though, in this much broader context of saying that true
interoperability is, in fact, about the thing being able to work across
different contexts and in a way that humans can understand it and interact with
it.
So we're actually, I think, having a relatively high bar for it. Is the
difference in compatibility? Sure, it's a richer and harder thing. Is it
different than standardization? Sure. I'm not positive how to answer exactly
the question you're asking me.
>>: Is there a super set up, or compatibility part of interoperability, or are
they just completely separate things?
>> John Palfrey: I think it's a subset of interoperability. I think
standardization and compatibility are subsets of the broader thing of
interoperability. Again, I think it's a higher bar than that. Yes, sir?
>>: Your section on credit cards. I can see I lose privacy when I pay with a
credit card. But as for security, I am most secure when I pay with George
Washington. It's a lot easier to dispute a credit card transaction than a cash
transaction.
>> John Palfrey: I think that's a very good point. I think across the system,
one could make the argument, though, that security is lower in the credit card
context, that the ability, for instance, of anonymous or somebody else to bring
down a system at a much higher level is greater than the small scale risk that
you run as George Washington. But I think that's something that we could
certainly debate. At which level do we care more about the security.
25
I guess my point in looking at privacy and security is it's not the
interoperability per se that leads to higher or lower levels of security or
privacy. It's what we do with it. Again, I go back to that lab example. You
could have a much more secure lab with one entrance or one that has 100
entrances. It depends on lots of other factors.
>>: I relate it to the comment about unintended consequences and innovation.
In the case studies you've looked at, are you seeing a trend in the heightened
awareness of interoperability and thinking about in advance of designing
interoperability versus it growing and accidentally getting there? So with the
exception, maybe, of some business model or products that are platform based in
an example, are we reaching an era, because of the nature of the interconnected
things today where there's jut a heightened awareness as also exemplified by
your book and more people are thinking about it initially versus trying to
catch up after the fact?
>> John Palfrey: I don't think so. I think in very specific instances of the
platform type businesses and lots of things you guys do, I think there is a
heightened awareness. And obviously, it's an important competitive question.
I don't think systemically we think about it particularly well. I actually
think things like virus, whether they're like SARS or like the flame virus. I
don't think we're thinking enough about what those fire breaks look like across
complex systems.
So, you know, again, there's no empirical data to say we are or are not paying
enough attention to it. But I think as we create these much more
interconnected, interdependent systems across cultures, I think we need to be
much more cognizant about creating those protections as part of the purpose of
writing a book that's not just for developers is to say that this actually may
matter across a broader spectrum of topics.
>>: So I love the library example. So when you think about education and
digital youth and interoperability, are there certain problems that you think
would be really fun to look at? I think the library one is a great example
because it's not that obvious unless you're [inaudible] thought about education
and kids.
>> John Palfrey: You're so nice. If I abstract up one level, which a lot of
this is an exercise of abstracting and being academic about it, I'm really
interested in the concept of connected learning, the extent to which kids are
26
learning in so many different ways and so many different environments and that
it's much less about the given classroom and this sort of contained space that
really is happening on the kinds of social networks you're studying and
creating and that we haven't, as educators, thought enough about that set of
connections.
And some of the stuff they're learning is bad, right. There's not all good and
there are things that have to be unlearned in that environment just as there
are in the classroom. So I think of it as an interop story in the sense of
thinking about how all of these different learning environments interoperate in
a way that gets us to our pedagogical goals recognizing that it's not so much
about just that one teacher who is at the front of the room able to guide a
conversation or to, you know, help inform a kid about a given topic. It's
much, much, much more distributed and complex a learning environment today.
And I think that puts more pressure on learning institution to doing a better
job in seeing it as a complex system and then seeing where the points of
intervention could be. That's not a precise answer, but it's an inspired one
in the sense that I'm really excited to work on it.
So seems like maybe we have exhausted our questions, but I'm really grateful
for the chance to have this consideration and thank you for having me here at
MSR.
>>:
Thank you.