This week, Derrick Schultz shares a tale of two cultures: publishers with their rich history vs. the talented digital employees who have come to “disrupt” everything. This talk is a sometimes humorous, sometimes frustrating, but ultimately optimistic look at the future of the people behind the books.
You can find Derrick’s presentation slides here.
To make sure you never miss an episode, you can also subscribe to the podcast for free on iTunes, Stitcher, Pocket Casts, TuneIn, or SoundCloud.
(Scroll down for a transcript of the conversation.)
Transcript
Derrick Schultz: There's a rich history that already exists in publishing that a developer can just come in and say, "I love books, too. And I bet we can maybe make some of this stuff a little better."
Zalina Alvi: Welcome to the seventh episode in our series of Tech Forum talks. I'm Zalina Alvi the community manager here at BookNet Canada, and that was Derrick Schultz, the director of developer experience at Atavist. As a designer and developer working at the many edges of digital books, Derrick has a unique take on the storied history of collaboration between the book industry and its technological saviours/disruptors. In this talk, Derrick examines this clash of cultures and how we can all learn to forge ahead together. I should note that Derrick's presentation slides are definitely worth a look and you can find those at slideshare.net/booknetcanada. And now here's Derrick.
Derrick: I worked for two different publishers that were working essentially in the digital space. First one was this place called Open Air Publishing. We were the first company to license Inkling's platform and use it for adult how-to nonfiction. We produced books about cocktails, parenting, photography all these different things. And we actually won a couple Apple awards very early on, on the iPad app days, saw some decent success but in the end, it wasn't really enough of a success. And I can get into some of that stuff a little bit later on. Ended up selling the company back to Inkling. And actually, a lot of Canadians were working with these, our CEO was from McGill. And just to point out, this was such a startupy company that I was actually the only person with publishing experience and that was having done random art books as a designer. And now about half the team works at Uber. So I don't know, take that to be whatever you want from there.
After Open Air, I moved on to this company called Atavist Books and yes, those dates are correct. It lived from 2014 to 2014. Atavist Books was a really great idea. It was founded by a wonderful editor, Frances Coady, Barry Diller. So it was actually an IAC company. They owned Vimeo, they owned CollegeHumor, a bunch of other big media things. And the idea was just to really take Frances's ability to work with amazing fiction authors and find a way to get them to create things in the digital space.
But as sometimes what happens with big companies, like IAC they were unhappy with where it ended up being and thought that the space wasn't exactly where they thought it was going to be. And they ended up closing us down. So our first title was in March with Karen Russell's "Sleep Donation" and our last title was a print title called "Dear Thief," which came from the UK, but we did some really cool things in the middle of that. And actually just this week one of the Gawker properties wrote about our book called "The New World" and said, "If you're gonna read any digital ebook, this is the digital ebook to read." So, still cool.
Now I work for a company called Atavist and, yes, I realize that's really confusing. Atavist is a separate company from Atavist Books, but we had a partnership, Atavist Books was using the Creatavist platform. Yes, Creatavist is another thing that Atavist owns in addition to this thing called "Atavist," which is a magazine. So believe me, I'm as confused as you are about all that. A lot of people have come up to me and said, "Oh, I'm really sorry to hear Atavist closed. Where are you working now?" And I was like, "Atavist." But anyway, I digress. So yeah. So I'm sure probably a lot of you are thinking like, "All right, this guy's worked for some failed companies. Why the hell do we have him up here?" And the best I can give you is this, when I started doing all this, I was reading about five books a year in total.
And those are mostly big design tones, beautifully richly designed books. And just a couple weeks ago, I did this art project for a friend and I ended up going back and looking at all the books I read last year and I read over 40 books. And that was almost entirely on my iPhone, either in bed, on a subway, in an airplane. So, I feel like, what's the hair club for men? I'm not just the CEO, I'm a proud user. That's how I feel. And I'm now a little self-conscious about my hair, but I actually do believe in this stuff. And I think that it's a slower process than I think any of us expected, but I really feel like there are people who are really die-hard into ebooks and digital books. And I think the digital book space has this great opportunity to become something that is a part of publishing but isn't the only thing in publishing.
How do I start from there? I'll start with some facts, real, real facts. Startups are stupid. They're such a terrible idea. The basics of them are this great idea, right? Let's start up a new company, but the culture that's surrounded it has just made it feel really icky. And icky is a real term. I swear. So when we talk about, like I wanna talk about developer culture, but realize developer culture has basically just become startup culture. Ten years ago, I could talk about techno hippies that had weird servers in San Francisco and were trying to change the world. And now we have companies that are trying to help you do social mobile, like share a photo of your cat, which is great. I love those apps, but not necessarily the same thing as world-changing.
And I think that got me summed up with this idea of this was Facebook's motto up until six months ago, and the ideas move fast and break things. And in the startup world, that sounds great. Like, yes, we're gonna break a bunch of stuff, but that's actually terrible. I don't want anyone coming into my home and running around and breaking stuff. That's actually like... It's rather insidious to actually do this. Now Facebook's motto is moved fast with stable infra. I'm sure Mark Zuckerberg understands that better than I do, but yeah.
But there's also this other thing that I hear a ton of startups talk about, and it's this idea of ask for forgiveness, not permission, and I don't know about you, but if someone came up and punched me and then said, "Oh, I'm sorry. I would've asked, but I just really wanna do it ahead of time." I don't know. But this is what's become a part of developer culture and it's because of VCs, it's because of other things, and it's made me less interested in working with startups and more interested in moving with publishers, but I also have to be really fair and balanced. Publishing is stupid, too. We all love what we're doing, but at the same time as a business, it's a really weird model. I literally just Googled publishing industry is stupid and this quote came up, and I'm sure Thomas Wolfe is...
I'm sure this is a 50-year-old quote, but it actually still holds, we're all sitting here looking at cobos and we're like, "Oh my God, there's actual data about how people are reading our books." And we're still in this weird world of like, "We don't know why that book sold a lot. We don't know why certain things are taking off and not. We have guesses. We don't really have a whole bunch of data backing that up." And as a business, that's rather strange. So, yeah, but here's the other side of this again. "Throw out most, bet on a few and win with one or two." That's a VC idea, right? Spread out your bets, and a couple of them will win, but the honest truth is that's how books work, too. A lot of publishers work on this model of like, we're gonna buy a bunch of books and we're gonna have a couple bestsellers and that's how we're gonna make a business out of this.
So, in this weird way, there are a lot of overlaps. And there are some interesting things that you realize, "Oh, yeah. When I was working for this startup, it was weird. And we had some strange things go on, but now I'm working a publisher and the other strange things are going on." All right. So thank you. I really just... I needed to just vent a little bit, because sometimes I get together with my friends and they're like, "God, will you just shut the fuck up about this already?" All right. So let me... Let's just start over here and we can actually look at this like it's a real problem.
This is this tweet that I found from my friend, Boris, who is starting his own little publishing startup. And I just love this graphic. It might be a little hard to read up there, but it's basically a breakdown of all the different pieces of a workflow within a publisher. From not just the production, but to the distribution, and to the consumption side. And his point was basically like, you could stick a team of developers on any one of these areas and they would help fix or at least make some things more efficient. Maybe change a couple of other things. It's a really interesting idea that publishing has these huge webs of all these different pieces that they connect to. And if you, as a developer or something could, say, jump into the distribution chain and say, "Well actually if we digitize this or made an API for this, we could save you a little bit of time, probably some money and maybe get people more access to books." That's an amazing thing.
Sometimes startups just come outta nowhere and we're like, "I think people want to tweet 140 characters and I just think people wanna do that." Here there's something wonderful. There's a rich history that already exists in publishing that a developer can just come in and say, "I love books, too, and I bet we can maybe make some of this stuff a little better. Maybe save people some headaches." That sort of thing. But what I think is actually really interesting about this is it helps me see how a startup works versus how a publisher works.
So for example, this is how a startup would work. They would look at that chain and say, where do we disrupt something? And they'd start with something really small, right? So they might say like, people have a problem with highlighting in books and people have a problem with sharing those highlights. So why don't I make an app where all you do is share highlights, or all you do is you can share a screenshot of what the text looks like and make publishers freak out about DRM all over again. But it's a very interesting little project. They start with something so small and try to build up a mass around it. And that's the first year is just trying to create this one little thing that everyone loves.
And then year two and three is expanding from that. So they're sort of working backwards, right? They're, instead of looking at how do we change the whole production supply chain? They're like, "How do we fix highlighting? How do we turn that into something like being able to add a review with a highlight? Or being able to share your review in a highlight." So it's a really interesting little thing that startups work backwards. They start very small and they do a lot of little things to see if this is a good area, see if this is gonna work. If they get bored or they don't work, they can always sell their company to Facebook and go work for them. So it's pretty safe. It's a good little model to work with.
But publishers, on the other hand, whenever someone says like, "Oh yeah, we're gonna make a CMS that redoes the production workflow." This is what they're trying to change. They're trying to change everything at once. It takes five years, three CTOs, put themselves into a mental institution because it's impossible. And the day that it launches, everyone's like, "This thing is terrible. What did we do? Why did we make this again?" And I think that this exposes some sort of underlying problem that it's sometimes about viewpoint, sometimes it's about how much we're trying to take on at once. But it's a hard problem because, from a publisher's perspective, this is really important. These things all matter to them. But to a startup, they're sort of just looking for a way for a VC to keep giving them free beer. And I know that sounds mean, but in some ways, they're having fun, they're enjoying it and they are solving a problem. They're just solving one that is a little bit smaller than a big publisher would have to.
So, like I said, I think that actually does really explain the difference in cultures. And with all that being said, I've worked at a bunch of startups prior to being in publishing, I've worked at a publishing startup and I've worked at a much more traditional publisher that was being started up. Even though we wouldn't necessarily call it a startup. And all that's given me some time to just see some things, see some perspective.
I now work for a platform where we actually can allow publishers to use our tools to publish their own things. So it's sort of given me a meta-level view to begin to say, "Well, look, I learned a lot of these things and I found out that this was a bad idea. So maybe if you're just jumping into this, I can offer some insights. It might not actually be true for you, but I can at least offer some thoughts." So here are literally a bunch of random thoughts. Some of them are sequenced, but for the most part, it's just gonna be all over the place. This is just a life thought, but it also applies to publishing.
I can't tell you...so Atavist Books as a production facility was open for about nine months and there wasn't a day where I didn't go in and change something drastically. And I think that that's sometimes hard for an industry that has, in relative terms been very stable that to now understand that like, wait, we need to market on Facebook and then, oh, wait, actually we need to market on this thing called Snapchat. Or I don't know, we need to set up a Tinder profile for our books. That seems weird. I would totally use a Tinder for books, by the way. I don't know, whatever. So, I'm gonna go find a VC after this. Yeah, so obviously, I think this is the same thing. Everyone here who is listening is like, "Yeah, yeah, yeah." But it's kind of true. And this is something I actually take some excitement away from.
The fact is the ebook that I made six months ago is gonna be different than the ebook I make today. And the way that our editorial team at Atavist Books worked on day one was very different than the way they worked on day, I can't do math today. So 250, let's just say. So I think that this is actually something you can embrace. You can embrace this idea of constant change. And really what you need to do is find a framework that works better to accept change, find a solution to it that doesn't require 10 meetings and people flying across the globe, but can work a little bit more flexibly. Maybe I'll talk about that a little bit later. Let's see.
All right. Thought two. Every time we talk about digital publishing or publishing with digital developers, eventually people talk about Amazon, they talk about ebooks, but I haven't heard anyone talk about this. People lost their jobs through that Sony hack. And I think that this is still something that, okay, you can hire a developer to work on an ebook. You can hire a developer to help build out your production workflow, but maybe you should also make sure you hire a developer that is making your email secure, or making sure that your contracts aren't being stolen and then being published somewhere. So this is another thing is, don't just think about the developer as this little guy that, he works in this other office and therefore, he builds our ebooks, but we don't really ever have to talk to him.
You should be thinking about using developers on a much larger scale. And maybe you can outsource this to someone, maybe you can't. But digital is actually influencing every little bit of our workflow now from emails to faxes or whatever it is it, it's now a bigger thing to have a developer on your team than it is to just have a developer that makes your ebooks for you.
I was asking, I was begging for help basically at some point, my friend, Alan, said the only rule is only the paranoid survive. He works at "The New York Times." I don't know if that actually correlates or if there's a reason he learned that there, or if that's just his own personal mantra, but I think there's some truth to it. And I think this's actually the one thing that publishers are really, really good at. Maybe with DRM, maybe? I think there's some truth to the fact that you should be cautious about jumping into new things. You should be considerate of like, "Well, what does this do to our... We don't wanna cannibalize our current business." But you should also be paranoid on the other side, you should be paranoid that like, what if Readmill actually took off? Or what if 10 years ago someone had said, "Hey, that Amazon thing, that might be a problem for us?" So I think it's worthwhile to consider being both paranoid about your current business, but also paranoid about what your future business is gonna be. And I don't know why a developer is telling you this, but that's my idea. I stole it from Alan actually.
Speaking of "The Times," this is something I've just noticed in general is that newspapers' digital strategies are 10 years ahead of what publishers have to worry about. Some of that has to do with the fact that the web really hit them a lot harder and a lot quicker because of length of articles, the way news gets spread versus books get spread. But I think it's really valuable to think about what a publisher is doing now versus what maybe a book publisher should be doing.
So, for example, if you think about paywalls, paywalls are essentially a subscription plan. And "The New York Times" big paywall subscription thing was five years ago and that was a big hullabaloo. And now we're hitting this thing where Amazon is jumping the subscriptions, Oyster exists, Scribd exists. So you could have sort of seen these things coming because of what was happening to newspapers. There's no direct correlation, but there's at least something there that says, well, maybe we can look at people who have already faced this business model as. I think we talk a lot about the music industry because of copyrights and other things. And we say, well, look at what happened to them as some fear-mongering system. But I also think newspapers are a great model to look at as a way to figure out, well, what did they do? How are they thriving? And some of them are thriving.
Some of them aren't, and there's some other new journalism things like "Gawker," "The Verge," well, "Vox Media" that are coming up and they're doing amazingly well for themselves by adapting to what the web needs as a model for journalism.
I'm gonna quickly jump here because I think this is the thing that I can actually talk about with some knowledge which is building tools for your team whether it's building a CMS that generates an ebook or building something that helps your editors do their work a little bit faster. And this is the one thing that I will say startups have actually figured out and is something that we should really look at adopting within publishing, which is start small, then build your crazy tools on top of that. So like, don't try to build that nuclear rocket day one, especially if you've never built a rocket before, start by learning how to light a match. So yeah, I think this is the same thing. This is something that we actually saw a lot at Atavist Books. One of the big things with Atavist Books was that we decided we weren't going to adopt a lot of the traditional publishing outsourced tools, which meant we were doing our own direct to retailer submissions, which is a total pain in the ass. I can see why everyone uses a different system now. And here's the thing is we decided, okay, we need our own metadata storage system.
So I was telling people yesterday that I made my junior developer sit down and literally write down every field that every etailer requires and put it all on Excel spreadsheet with what the field is, what the field type is. And I think he had like a thousand fields by the end of this thing. So we sat down and we built a very simple tool that covered 80% of those. We knew that some of those things were outliers and if we tried to build a system that actually worked for everything, we were gonna be stuck in development and QA for three months. But we, instead, gave the editorial team something that they could use, would solve a bunch of their problems, and then those weird outliers, they only had to spend a little bit of time on. So this is really my next point as well. It's not about the perfect tool, it's about an optimal tool.
I'm just gonna quickly show you, I don't know if there's actually a really name for this law or this idea, but there's this really wonderful XKCD, let's see if the internet's working here. It is, cool. This is a wonderful little chart that basically said, and this is a developer mantra, do I automate this or do I not? And here's this funky little chart that says, how often do I do this? How much time does it save me? Should I automate or should I not? It's a really interesting little tool and I try to apply it, not just to work at my publishing groups, but even into life things.
So again, this isn't necessarily to disrespect publishers, but it is to point out some things. Almost all of us are trying to solve the same things. We're all trying to solve the fact that most ebook rendering is shit. And yet, we're all doing it by ourselves and we're not sharing code with each other and we're making all of our lives hell. Whereas instead, we could all be working together on these things. For example, I created this thing on GitHub, which I'll talk about later. Okay? Don't worry if I said GitHub. It's okay. We're gonna get there. I'll also say command-line, so don't worry. I said this thing on GitHub that is just like a list of rendering issues.
So anytime anyone says, that is an ebook developer has a problem with their device and figures out what the problem is, they just list it there, and then other people from the ebook production world, jump on there and say, "Oh, you can fix that by doing this hack." "You can fix that by doing this." "Yeah, this is completely unfixable. We should try to reach out to someone and try to solve it." And honestly, I kept that from my bosses at Atavist Books, because I was sure that was gonna create a problem. And I'm saying that now, and they're gonna see that video feed in a month. So we'll see, we'll see, if I get a fun email. But yeah, this is one of the problems is that a lot of traditionally entrenched publishers are afraid to share how they work, but the truth is most of us developers know how each other is working, but we just don't have the time to actually make things.
The great thing about development resources is they're all online. I can Google search how to fix a bunch of ebook things. Maybe someone has solved it, maybe someone hasn't, but this stuff is all out there. And most of these things are built on open-source tools, so you don't own the IP to them. Sorry to say. So, this is a problem, but the thing is and we start to see this with IDPF, if we all get together in a room and say, "As a big publishing group of people, what are our biggest concerns? How can we split up our time across all of our development teams? How do we make this all happen?" And also, I get a lot of small publishers that ask me like, "I'm a small publisher. I can't hire my own developer. What do I do?" I actually just saw that Verso Books was hiring a developer to work on both Verso Books and on "New Inquiry," which is a magazine founded by Verso Books, editor in chief now, or something. They're finding a way to collaboratively hire an individual developer to do a bunch of work across a number of things. And I think that alone could be an interesting model.
So yeah, just give that some thought. Okay. I said I was gonna talk about GitHub, and it's time. Everyone can grab the table. Open source tools are actually really amazing from a developer perspective. Not because they're free and not even necessarily because they're open, but because they create a community around things.
And the best thing that you find with development is that we all talk to each other and we all solve each other's problems. And one day I'll be begging for some resource on how to fix this. And someone shoots me an email and says, "You can fix that with this. This guy wrote a blog post about it." And the next day they're begging me for something that I can help them with. So think about development, not just as these final projects that need to be made, but as building a community. And one of the things that I found a lot was my friends were telling people to buy Atavist Books titles in part because I'm their friends and I would guilt trip them if they didn't. But also because I said like, "Look, Atavist Books is paying me to solve a lot of your problems, too." And they said, "Oh, that's great. Yeah, you're right. This book looks great and you helped me out a lot with it." So it's this weird potential marketing thing. Maybe not, I don't know.
Alright. So, I had the same slide in yesterday's presentation. I'm gonna have it, here again, if you're a publisher and you have a website and you're not selling your own books, I don't know what to tell you, but please stop and start selling your own books. The world opens up when you have your own dedicated place. I think Brian earlier was talking about the fact that now you can get news, you can get people's email addresses, you can get data about what are people buying?
You just have this ability to create your own environment that people can come to you for and begin to build your own brand or whatever. There's this article here by this guy, Frank Chimero, who I probably have two or three links in here. He talks about building your own porch in the world of social media where basically Twitter is a street and you've got a big Facebook store on the corner and you've got LinkedIn basically trying to buy out the entire block with weird popup ads. You at least have your own porch and your own porch is where you can invite your friends in to have a drink. You can decide how big that porch is. But I think it's one of these things that everyone that works in the web knows like, oh yeah, you have your own web place where you can do your own thing and you don't have to stand by the rules of Twitter or Facebook or whatever it is. All right, off my soapbox.
I assume everyone knows what dogfooding is. Is that true? Okay. Maybe not. Eating your own dog food or dogfooding is the idea that you use your own products. And basically that if you don't like your own product, it's very likely other people will not their own product. So for publishing, I'm gonna call this ebooking, in part, because I think a lot of people feel ebooks are like the dog food of books. It probably doesn't taste that great, but some people will eat it just for the sustenance. So I did this thing, actually, Atavist Books was the first place where I was actually working on ebooks.
I don't know if I've ever admitted that to anyone in this room. But anyway. So I did this thing where I actually because we had a nice source of funding I bought a stack of devices and every weekend I would take home a different device and I would force myself to read a book on that device. And honestly, I liked some of those devices. I might have hated Nuke's rendering, but I actually really enjoyed using that device. And I think what it helps you do is it helps put in perspective, this is the environment that various people are reading on. Like yeah, 75% of people, at least in the US are reading on Kindles. But not everyone is. And not everyone has the latest model, those sort of things. It really teaches you, this is the user experience of someone.
And I don't think this is just a thing for developers. This is a thing that editors need to do, too. I had a lot of editors who were like, "I can't read on a Kindle. I have to read on paper." And I was always a little hurt by that because I think if we were doing a digital-only book and they didn't realize what the reading experience was, they were really missing out on an opportunity to say, "Oh, maybe this thing doesn't work in a paging mode. maybe we should really think about how this looks." So please go out and ebooking tomorrow. I don't know, whatever or however you wanna call that.
Institutional knowledge. This is another weird soapbox thing for me, but something I feel I really need to say here.
I am always surprised that publishers are willing to throw large sums of money at tools that they don't own and they have never experienced. I think you guys can decide what you do, but you're losing out on so much institutional knowledge. I have a lot of freelance ebook friends and they might get mad at me when I say this, but you should at least try building ebooks in house. You should at least know the problems you're gonna be facing. You should at least know, this thing actually really is hard, so we really should hire a quality freelancer to do this the next time. There's so much to be gained from keeping knowledge in house and using it. If you have an outside marketing firm that outside marketing firm knows more about your company than you do, they know more about your audience than you do, you should be afraid of that. Again, you should be paranoid of the fact that other people know more about your business than you do.
You can't realistically keep all of it. You can't hire your own marketing person; you can't hire your own social person. You just realistically can't, especially if you're a smaller company, but you should be able to figure out like, what is core to this business that I need to know about and you should fight to keep it. And I'll talk a little bit about some of these things in a minute.
Oh, yeah, here we go. Okay. If you decide you do wanna hire developers or you do need to build some tech products here are just some random thoughts I have on experiencing that.
It's worth the shot. Okay. I said be paranoid about institutional knowledge and what you keep and what you don't keep. And this hurts because I have a lot of friends who are really smart and work at agencies and consultancies, but I think you have to be wary about, what are you paying for? Are you really paying for this tool? Are you paying just upcharges? Do they care enough about your business to build a tool that you actually need? I can't tell you how often I've worked with outside agencies where the thing is they wanna make something cool, but they do not give a shit about what we actually need. And I didn't realize I'm swearing a lot. That's another developer culture thing, I think, maybe, but I think it's really key that you understand that sometimes a consultancy...
Well, a consultancy is their own business. Their job is to make money by continually making products. And sometimes the best way to make a product is to make it fast and hand it off. But sometimes it's not to sit with you for a year, which again, don't do a project of that scale, but sometimes it happens. Their job isn't to make sure that it's exactly what you need a lot of times. So just keep that in mind and maybe you should hire someone in-house. Maybe you should bring someone in for a short duration of time to really sit with you and understand how it works because I can tell you as a developer, getting an email from someone that says, "I really wish this tool did X, Y, and Z," is not the same as me sitting down next to my editorial assistant and saying, "What are you trying to do?" And she shows me and I say, "Wow, that's really hard. I bet I could solve that for you." They're so different. They're so vastly different, but I think you really have to understand that the human connection there still matters a lot.
Here, I'm gonna give you guys a good one. You can definitely tell a developer to fuck off. Because, here's the thing, in startup culture, we've deified developers, they're now the cool guys that they know how to write no, they know how to write rails. They know front end, they know backend, they're the full stack developer. They're a god, but in publishing, it's not the same thing. Your job isn't to make sure Twitter is running 24/7. Your job is to make sure that you make a great book that is readable in all devices or to help the editorial team. You're really a part of a team and I think that's great, but I think it's also, sometimes it's weird when I read stuff, that's like, "We're looking for a ninja." And I'm like, "Well, that's cool. But you don't want a ninja, a ninja is hiding and they're always hiding. You wanna see that person.
Here's another soapbox thing. I don't believe writers need to be coders. I vehemently do not agree with that. I learned that from Frances Coady, Atavist Books. I used to have this feeling like, "Man, if a writer knew how to write HTML, my job would be easier." But that's the thing, it's not their job to make my job easier. So, there's a group of people out there that say, writers need to learn markdown, writers need to learn HTML. I just don't buy it. As a developer, I can very easily convert your word document to another format. I can easily work with whatever you're working with.
Sometimes I'm gonna grumble if I have to use an InDesign file and it's gonna take me a week to write some scripts to get it outta there, but I can do it. And the thing is, especially at Atavist Books, when I read something that was beautiful and great, and this amazing piece of work, I was like, "I'll peel that dude's grapes if he just keeps writing, whatever he wants, I'll find a way to support that."
Last little thing, please let us take pride in our work and talk about it. Again, you would gladly send an author to a conference and talk about their book if it meant they sold more books, right? So as a developer, if I go somewhere and say like, "We built this great tool, here's all the things that we learned about it, and it produced this beautiful book." At least someone in the audience is gonna buy a copy of that.
And you saying like, "Actually, I don't want you talking about that, because that's private internal work." Again, it's probably not, we're all using the same codebases and stuff. We can probably figure it out. I could probably reverse engineer someone else's ebook if I really felt it. So let us talk about it. Let us take pride in the work that we do because it makes you look better, too.
And then this last little thing, I'm just gonna talk a little bit about the web and how it applies to publishing because I've been talking a lot recently about how I want publishers to publish more on the web. Whether that's through things like content marketing or actually publishing your book on the web, which I really believe you should do.
So anyway, publishing has a 500-year history, it's vast, it's huge and the web's is just 30, but if you actually look at the speed that we've been moving at, that we're probably at the same scale of how much data and how much history is involved. And all you have to do is ask someone about, like ask a developer like, "Hey, do you remember the EPA or the HTML 3.2 spec?" And most of us will be like, "No, when was that?" That's basically the same as asking someone today in production if they remember doing letterpress on a woodblock printing machine. So, it's worth acknowledging that, yes, publishing has this huge and vast history, but so does the web. And that means that some of the things that you think are insane about the web, the lack of DRM or the lack of...
Someone can just copy and paste my entire book and what can I do about it? There's a history behind that. And some of that history is ideological. Some of it's technical, there's a lot of stuff involved in this and I think it's worth, again, if you're going to go dog food in ebook, if you have a website, it's not a bad idea to also learn a little bit about the history of the web. So that's basically this point.
Every once in a while, very rarely I will say at Atavist Books, they were all really great. Someone would say to me, "You don't understand book publishing." And they were absolutely right. I really don't understand a lot of book publishing stuff, but here we are trying to publish a book on the web and they don't know how the web works. They don't know... And not even necessarily, they don't know the technical infrastructure of how web works. Most editors probably don't know how a production work, how a book gets printed and produced ad those sort of things. But there's an underlying ideology to the web.
And again, there's a Frank Chimero link down here called "The Grain of the Web," that he just recently wrote. And it basically explains how design has adapted to the way the web works. So we're not trying to reproduce print on the web, we're taking the inherent constraints and the very McLuhan ideas of medium and media that the web is a different medium than print, and we're applying design and experience strategies to the web. And while the ebooks are slightly different than the web, I think it's still a parallel that's worth talking about and worth investigating more than just my 30 seconds of talking about a slide here.
I promised myself that I wouldn't show any work, I would just show trippy photos, but turns out chip kids' cover for this "Twice Upon A Time" book is actually somewhat trippy. So I'm gonna count it. I worked on this title with Atavist Books I'll just quickly talk about there's a link here. It was this great immersive interactive story. There was a soundtrack that loops over everything. I would encourage you to check it out, but the big thing I learned about it is that it's just as similar as an editor-author, an editor and a developer, an editor and a designer, they're very similar processes. And I think it would do us all well to learn how to combine those two, or how to work together better.
Last thought I think I brought this up when I was talking about the startups versus publishers. It's better to do a lot of small tests than it is to do a big failure which I'm hoping was not this talk. So, yeah, again, feel free to find me afterward and we'll talk more about it. Thank you, guys.
Zalina: Next week, we've got Keith Fretz from Scholastic talking about kids' books and how publishers can use transmedia properties to build online communities. If you want to learn more about what we do, you can find us at booknetcanada.ca. Thanks to Derrick for speaking at Tech Forum and to everyone who attended or helped put it together. We gratefully acknowledge the financial support of the government of Canada through the Canada Book Fund. And of course, thanks to you for listening.
