Video At Home with Tim O'Reilly (Videos 3 and 4 of 6) 6
Tim O'Reilly: DRM, when I look at the publishing industry, the insistence on DRM has played into the hands of turning Amazon into a monopoly because effectively Amazon has a proprietary file format, which effectively is DRM and you can only run it on Amazon devices. And if publishers – yeah I guess they could have done a DRM, a lightweight DRM solution, that was industry standard, offered from multiple providers, but they didn't. And I do think that at this point, when I look at say the Amazon/Hachette conflict, if Hachette were saying well we're going to make our e-books available in an industry standard format that were DRM-free, I think they would have a real leg to stand on because they'd get a lot of users who would do good things for it. And I guess I would say, I've always felt that when people value what you do, they don't mind paying you. And the people who don't wanna pay you wouldn't have paid you anyway and that's sort of been our driving force for a lot of things that we've done.
When we used to get back stickered books from Barnes & Noble because they were shuffling around their inventory and they return it from store A and then it's like you can't resell the stickered ones it's too much work. We would send them off to Africa and this is effectively the same thing, somebody who wants to get a DRM-free book and they're going to pirate it, they probably wouldn't have paid us anyway but a lot of people actually do pay and it's a competitive advantage, people say you've given me more rights than if I buy it from Amazon. I can look at it on my device, I can do all kinds of things with it I couldn't do, it's worth it to me to pay more, right? And so it's a competitive advantage.
Timothy Lord: Yeah, when they buy their next book, they're probably going to think a little bit more about it.
Tim O'Reilly: That's right and all I know is we have a very good business and we're probably one of the only publishers who can say that Amazon is our third largest digital channel after our direct sales on Safari. And you kind of go, that's kind of a testament to what happens if you put the actual customer first instead of saying: well what do we need to do to preserve our business model.
Timothy Lord: Now Tim let me ask you one more question about your book publishing, one of our readers asked: Of all the books you've published which one do you keep in a prominent place on your bookshelf and why?
Tim O'Reilly: Well, I have to say that I probably don't have any of them in a prominent place on my physical bookshelf because I'm travelling around so much and I have stuff in my office.
Timothy Lord: We'll take figurative.
Tim O'Reilly: Figuratively I have UNIX Power Tools, it still sort of looms large in my consciousness, mainly because it was probably the most fun book I ever worked on and it was this early attempt. We did it in 1992. The web was just out there and I was kind of going, "What would the web look like if we tried to do it in print?" We'd have all these little bits of knowledge that were cross linked, we sucked it in from Newsnet and it was just this wonderful crowd-sourced. We took things out of a lot of our other books. There were like 500 authors in that book, I mean there were three of us who put it together and we probably wrote about a third of the content but really it was this curated book and while we did a couple of updates, we never really created a corresponding work for the internet era. All the little hacks and tips and tricks and cool programs that make up the life of somebody who knows what they're doing today and I've always thought, given enough time I would like to do that. And if anybody wants to work with me on it, I'd be happy to hear proposals because what are the power tools of today's users?
Timothy Lord: Hopefully someone will leave that comment below this video.
Tim O'Reilly: And I've been thinking, again I mentioned earlier, I've been thinking about what would the equivalent be of a speech shell and so I've been kind of looking again at some of the shell programming stuff that we've done, just thinking about what aspects of shell programming would you want to bring over into that speech environment?
Timothy Lord: Well, a short hand would really make dealing with something like a smart watch far more useful because now we've got the tools for interacting the inputs: you can use speech, you can use touch, but actually getting a personalised useful result, that's something still being worked on.
Tim O'Reilly: Well, the thing that I'm already thinking about here is – what I'm looking for is an extensibility mechanism, because right now there's some verbs that my watch and my phone understand when I talk to them but I can't make new verbs. I can identify new nouns for it to act on and I think it would be revolutionary, the first player that does that, it can be a bunch of geeks who do that but what they're gonna do is they're gonna at the end show the vendor, what are all the things that are possible that they can then encode into, well this just comes with the platform for users who aren't so adventurous, so I'd love to see somebody take that up and I've toyed with, I should just go and get a whole team together and build it. But anyway those are two areas that I've been thinking about quite a bit.
In terms of other areas, I'm spending a lot of time reading some of our stuff on DevOps and user experience because I'm really – my fiancé was at the Whitehouse when the healthcare.gov thing came down and I got a – not a bird’s eye view but certainly a second-hand view of some of the goings on. I met some of the people who were involved in that and what really struck me and also through the work we've done at Code for America. It really struck me how much of what went wrong in healthcare.gov and how much of what goes wrong in a lot of enterprise software and government software is really how do we actually think through the correct role of humans in this process? And it's so user centred design, DevOps as they increasingly talk about it, it's really about – somebody wrote a post called 'Empathy, the essence of DevOps'. It's like how do you get the people who are developing over here to understand what the constraints the operations people are going to be under. How do you actually get them working together and that's what Mikey Dickerson did at healthcare.gov.
It was like: okay you said you'd do this thing, why weren't you able to do it? Okay, you need this thing, what happened? And it was debugging the human processes and making them line up. And then you go look at some of the work that Code for America did for example in San Francisco last year, debugging the food stamp system, why were people falling off the rolls? It's like, oh they got this letter they didn't understand, now how about we send them a text message that says: there's a problem with your benefits, call the office, instead of this legal letter that makes your eyes glaze over. It's like user experience, it's all about humans and understanding how they interact with technology and then you go all the way out to something like Uber. The fact is, this great tweet that I saw from Erin Levy and Box where he said "Uber is a lesson in building for the way the world ought to work rather than just copying the way it does work".
And that notion of: okay, we have these new technological capabilities, what are we going to do with them to put people back in the process in the right way? And it strikes me that everything from DevOps to Lean Startup are really about refactoring the human machine interface. And that's this huge opportunity for us all to think about and where I think a lot of the breakthroughs are going to come because we are still building the equivalent of the taxi app that replicates all the steps that you did before rather than saying, well what steps can we take out of the process now because of the new capabilities and how do we make this a totally different experience. And there were so many cases where we're just still duplicating what went before.
Timothy Lord: Right. That ties really well into a question that a reader asked about discoverability for programmers, not from the up looking down at, how the system works, but how does a programmer figure out sometimes just the one thing? He writes 'So much of a coder’s time is spent searching through stacks of code books just to find how to do one thing that he knows the language can do' and his question is, how do we make categorically better coding instruction tools? How do we improve the education that programmers have to make this complex of language? Languages can do so much these days and it's a big library to enter into and how do they find most efficiently how to do particular tasks that they really want to do?
Tim O'Reilly: Yeah, no I agree. That's a real challenge and there's two answers. One is I do think we need to have more modular content. If you look at what we did years ago with UNIX Power Tools and then with our cook books, it's like: okay, here's a problem, here's a solution. But once you have that, it really strikes me that you eventually want to be able to have much more of that Google Now like functionality that says: okay you're probably looking for this, you know, and...
Timothy Lord: How do we do that without it becoming Microsoft Bob is the problem.
Tim O'Reilly: Well you know...
Timothy Lord: How do we make the tools smart enough that...
Tim O'Reilly: Yeah. I think it's probably a long way off, but if you look at a lot of domains, we are seeing machine learning make real progress. And so, for example, in medical diagnostics it's like: okay, we're gonna look at a thousand images and we're gonna tell you: take a closer look at these six, rather than you go look through the thousand and maybe miss something, right? We have the whole notion of Watson in healthcare is, it’s read all over the scientific literature, you're presenting a bunch of stuff and it's in a position: 'hey! have you looked at this paper?'. We thought about this.
So I do think that there's starting to be some proof points that we are going to have AI like assistance on some of these things. Now I don't see anybody actually working on this for programming yet and I'm sure it's a very, very hard problem because everything's always being updated, you have lots and lots of news. It's not like – yes there are new diseases but there's a big enough body of things that you can start to say: okay we can work from this one to that one. But anyway somebody will do something one day and we'll go "Holy shit, why didn't we think of that!?" It's something I think about a bunch. I don't have any easy answers. I do know that one thing that probably a lot of people do wrong is they focus on what they have to offer, here's all the things that this language does and that's the organising principle as opposed to: what we try to do in at least some of our content is, here's what people want to do and here are all the ways to do it.
Because I was just talking to somebody at Google recently, I was saying there's so much documentation, how do we get better at _____34:14. Well, try triage on what are people trying to accomplish? And again it comes back to a user-centred design. And they're very influenced by these UK government design principles and the first one is start with needs and then parenthesis says “user needs not government needs” and the same thing, just substitute some other word for government, like this person from Google saying, “We've got thousands of pages of API documentation, how do we get people to find it? I go, well don't start with how do we get people to find our wonderful new feature, start with what are they trying to accomplish and work back from there.
And, one of the things that you find is, in the case of the UK government, they got rid of something like 2000 government websites and replaced them with one that was focused on: okay what do you want to do? And they looked at the data and said: okay here's most of what people want to do, so there's a way, like if I think about that, now that you're raising that question I haven't really thought about it that much, but we should be kind of doing a lot more analysis on what are people trying to accomplish? And doing an organization of all the content we have that's totally driven by: okay, here's most of what people want, okay here's the next most common thing that they want to figure out. Now obviously if it's super easy, if you do that too far, then all the stuff you leave with is the stuff that doesn't need any, if you will, any help with. So you have to kind of prioritize that.
Timothy Lord: There's a problem with recreating voice trees where it's always that our menu options have recently changed and it's never the one that you want.
Tim O'Reilly: Yeah, but we got to be...
Timothy Lord: It's hard to...
Tim O'Reilly: And you certainly can do a lot more adaptive stuff.
Timothy Lord: Right.
Tim O'Reilly: And I do think that, again I'm going back to this UK government thing and we copied that in a project we did at Code for America, working with the city of Honolulu where it was like: okay what are the things that people look for answers for most often? Let’s organize the site around that.
Timothy Lord: Right.
Tim O'Reilly: And you have that data in the search logs and so it was like: okay, it's like they literally went from this huge section on drivers licenses that had everything from, 'here's our new scanning machine, our digital machine at City Hall to' it's like: ‘and here's what you have to do if you're returning a service member', it was like all kinds of crazy ass shit and literally how do I get a driver’s license for the first time was number 22 or 23 on the FAQ. I was like, okay, that's the most common question, why isn't the answer at front and center? And if you kind of think through user experience I think there really are some interesting opportunities and like there would be a really interesting service now that you mention it.
It's like, okay, here's a common task let's not organize the answer by –it's like I think about like we have the Pro Cookbook, the Python Cookbook, we got the Java Cookbook, but you know, it’s just on and on and you well what if it was just like: I want to do this thing and here's a hundred ways to do it, here's the most popular, we've actually scanned all the code on GitHub and we're finding that where we've done performance analysis and there's like six ways to do it and this one actually clearly out performs. You can easily imagine a machine learning assisted set of tools. And again if I were in the programming tools business, I would definitely be thinking about something that was much more data driven and less: Oh yeah we're going to make a slick UI, because that again kind of goes back to like what's one of the fundamental arcs in computers? And it really is towards the machines doing more of the work.
And one of the things that I still remember very vividly, it sort of shaped my thinking about big data and machine learning. I was once watching the book buyer at Borders, when I was at Borders, reordering. And it looked like somebody playing a game of Tetris, she'd flash up a screen, it would show – they had these five layers of stores, the A stores, the B stores, whatever and for each title it would be here's how it's sold in each of the level of stores. Well this one we only had in A and B stores, this one we had at all five levels and she'd make this quick decision of and it automatically allocated between the five levels but she would go okay based on that sell-through, I'm going to take a hundred more, based on the sell-through I'm going to take five hundred more and she'd just flash the screen, flash, flash, flash. And it sort of struck me and then you hear later about how Walmart automatically reorders that somebody scans, you go that's the automated way and the visualization part I'm sure in the Walmart process is somebody working on the algorithm. They're doing that Borders Tetris thing, to kind of look at the data, all the visualizations in support of them tuning the algorithm not in supporting of them actually making the decision.
And that sort of struck me as – that's why I once said and got some flak for 'visualization is a halfway house'. At the end of the day, we're still in this thing where we're going to visualise this data, we're going to show it to you and then you're going to make a decision. No. We're going to visualize that data, we're going to show it to a programmer who's going to make a decision, embody in some software algorithm and then it will just happen.
Re: (Score:1)
There's no video.
Dice = -1 troll every comment in this story
Everyone else = +1 informative