Reflecting on the Internet: 10 Years Ago, 10 Years From Today
I’ve enjoyed software architect Jeff Lindsay’s musings on a new organization called Megalith.
Recently, Jeff and Timothy Fitz discussed Megalith on Episode 51 of their podcast, Systems Live. While the whole episode is worth listening to, the first 30 minutes revisit what the Web was like in 2005, and how it might look 10 years from today. As we enter 2016, it’s a great time to reflect on how rapidly our industry has changed.
I transcribed the podcast because I’m terrible at absorbing anything in audio format. I’m sharing it here because I think it does a good job of breaking down some of the problems with how things are built on the Web today, and why it matters, even if you’re not an engineer.
Sometimes, we talk about the Internet as “done”. The conversation around innovation has shifted to areas like biotech, artificial intelligence and space travel. From a social standpoint, tech wants to solve problems like urbanization, food systems, government and health care.
Software doesn’t seem to fit into either category, but it should. It’s the foundation for everything we do.
We (in the startup and venture world) think the Internet is “done” because it’s gotten so gosh darn easy to use. We don’t see what’s going on in the deep end of engineering anymore, so we assume it‘s long been taken care of.
The Internet is not done. If anything, now is a critical time to pay attention, because we need software like never before. Nearly every moment of our day-to-day depends on it.
As Jeff points out in the following transcript, there’s no business model to incentivize funding further development of the Internet. If you’ve ever wondered how the Internet first got off the ground, we have DARPA, a U.S. Department of Defense Agency, to thank. Who supports that innovation now?
Building a prosperous, tech-enabled future also means investing back into our underlying infrastructure to make sure things don’t fall apart. This is going to be a major focus for me this year, so expect to hear more on the topic.
For now, I’ll ease you in with a transcript of Jeff and Tim’s talk about the Internet: 10 years ago, 10 years ahead. If you want a quick skim, I’ve highlighted the parts I found most interesting.
(If you’d prefer to listen to the podcast, it’s available here. Note that this was manually transcribed by me: please blame any inaccuracies below wrt to the audio version on me, not Jeff or Tim.)
Timothy Fitz: Hi. I’m Timothy Fitz.
Jeff Lindsay: It’s like you go into this different mode, it’s like -
TF: Mr. Rogers, taking the jacket off?
JL: Yeah. You also got a lot quieter. But anyway that’s fine, we can do that, so, that’s the beginning, that’s the intro, you’re Timothy Fitz, I’m Jeff Lindsay, and this is (both) Systems Live. So that worked out really well.
TF: Keep telling yourself that, coffee’s working really well. So, Megalith. Not Monolith.
JL: Don’t even bring that — a lot of people accidentally call it Monolith, they might not even be aware. Because you say Monolith a lot.
TF: I’ve never said Megalith before.
JL: Megalith, so, just the story of discovering that word. I was kind of thinking about the project and all the pieces coming together, and there was this idea of them being separate, and at some point, collapsing them down into one monolithic thing. And it turns out there’s an opposite of monolith which is polylith. And then the, sort of, generalized version of both of those is megalith. So a megalith could be a monolith or a polylith. But it has the same properties of a monolith, so a lot of connotations you have with monolith apply to megalith.
TF: So, what is a lith?
JL: I don’t know. Stone structure. I mean it’s all kind of abstract, because the actual meaning is like, stone…structure. It’s not like -
TF: So Stonehenge would be a polylith?
JL: I believe so. I mean as far as I know.
TF: Okay. So you’re making a mega — large — lith — stone. You’re making a large stone structure. So that’s what Megalith is.
JL: Yeah, it’s a large stone structure. Everyone’s been asking me what Megalith is, I’m not able to explain it, it’s actually very simple. It’s a very large stone structure.
TF: This is why you’re looking for more of a house with a backyard, is because you’ve run out of space in your apartment. This is very Austin.
JL: Yeah. So that’s not true, at all. And one of the reasons I wanted to do a podcast is it’s actually really hard thing to explain. And everybody expects this very consumable description, and at the same time I’m also very bad at explaining things that are very new, that I haven’t, like, spent a year trying to figure out the best way to try to explain it.
TF: And the beauty of this podcast is I’m going to try to explain it, knowing only slightly more than the listeners. But also having known you forever. And so I see part of your struggle to define it is on one hand, it’s a very new and high-level concept, and so it’s hard to put into consumable form, but on the other it’s a 10 year project with like, a direction, more than an end goal state.
JL: Right. I mean it started as, I’ve been doing — and I wanted to get to the story, because it’s a story of development, and all the projects I’ve worked on, because it’s really about all that, that body of work.
TF: So it’s like Megalith: The Jeff Lindsay Story.
JL: Uh… (sigh) yeah? I think somebody suggested something like that.
TF: A Lifetime Original.
JL: Jeff University or something like that. It was weird. Because part of the process, I’ve been working on projects that fall under this umbrella since like 2005. And it’s kind of this thing that I’m compelled to do, and there’s a way I think about it and a direction and a place I’m trying to get to. And the only way I’ve been able to get help with it so far is on individual projects. Because that’s a tangible thing, I can be like, here’s a project, I had it to people, maybe it’s Dokku or whatever, and people are like oh, I get it. And then they contribute to that. But nobody really helps with the overall, the major arc, right. And so that was really the inspiration for me saying oh, I’ll just call that kind of career arc — it’s not a career, I don’t get paid to do most of these projects — but this work that I’m doing, give it a name. The trouble with that is there’s 10 or more years of lots of deep knowledge that goes into all of this stuff, and these different projects, and it’s so wide and huge, that to put that into, and to boil it down into a single name, and now describe it, right.
So what I’m trying to achieve is to externalize my thought process and the way I work on these projects, and help kind of both share the knowledge that I’ve gotten as well as the way I think about designing software, writing software, building software, getting software out there, getting people to use it. All the knowledge I have in doing these other projects, and share that knowledge, and get people to use that, to contribute to more than just individual projects. So for example, I have a bunch of projects on GitHub. I have a huge backlog of projects, right. At home I have a bunch of Post-It notes that were under the Glider Labs umbrella. There’s about thirty Post-Its. And about half of them exist in some form on GitHub. And about half of those, people know about. And then there’s a bunch of projects that I don’t have Post-Its written down for. And so, not all these projects are going to be huge game-changers. But a couple of them are, but the point is TOGETHER they are.
TF: And so that’s one of the problems with Megalith, is that people expect, they want you to say something like “Oh, it’s Jeff Lindsay’s competitor to Kubernetes. Here’s the website, here’s how you install it.” And while it may end up being something like that, while that may be a component of it, the way you get there is not by top-down, here’s all the things, here’s the basic version, they don’t do enough. It’s bottom-up, here’s the vertical slice and it works and it’s great, and here’s another vertical slice and it works but they work with other stuff, too. It’s an open ecosystem by default, instead of a closed ecosystem that slowly opens up.
JL: Right. And that’s one of the problems, which is part of my process is, a couple people know about this process, we’ve mentioned it on the show a couple of times, is idealized design. And this is a thought process that isn’t, some people kind of use it implicitly, it’s kind of built into a lot of new projects when you start something new. It’s most useful when you have an existing system and you’re trying to make a significant improvement. But the idea is basically, given everything you have now that exists, that you’ve implemented, whatever it is, everything you have, ignore it. Throw it all away. And reimagine what your ideal situation is. And within some constraints, like, it needs to be technically feasible now, and operationally viable, depending on whether you’re talking about like an organization, or a product, or a project or whatever. But just thinking about like, what does it look like? What are the properties of that system? You think about the problems that you’ve solved so far, and you just kind of list either manifestations of ways to solve those, or just that you want that problem solved.
And the first example of this was the Bell Labs story, and we’ve talked about a long time ago, with the telephone system. And we actually applied this process at Twilio, on the platform team I helped start, and there’s where a lot of — it’s kind of funny, Bell Labs, when they did this in like 1952, they had kind of plateaued in terms of, I mean they were still doing great inventions, obviously there’s a whole bunch of interesting things that came out of Bell Labs at that point, but, the main directors had read something that the major developments that came out of the lab, the top three or whatever, the coaxial, multiplexing, there’s a handful of things. But they were all things that had been done twenty years before. So they were like, well, what have you guys been doing? And his insight, which was a very systems way of looking at it, was, we’ve now developed a system, you’ve all specialized in working on these individual subsystems without thinking about the bigger picture. So um, so there’s this whole dramatic thing where he’s like, the American telephone system is destroyed, now let’s reimagine it, what does it look like.
TF: And this was a closed door meeting, where people were like, wait, what? It’s destroyed? And he’s like no no no. But figuratively. Imagine that it’s destroyed. Imagine that we have to rebuild it from scratch.
JL: And so they broke into teams, and they kind of like imagined each subsystem at a high level, and they didn’t have to implement it then, they were just imagining it. And from that — it’s kind of like a brainstorm — it’s a brainstorm given, if you were to start over, what would it look like? And I think a lot of software people find that taboo, because there’s sort of like, you shouldn’t rewrite systems, you should always evolve it. And that’s, this isn’t saying you shouldn’t do that, it’s saying separately, on a piece of paper, what does the ideal look like? Because you are going to evolve your system, but you need to know where you’re going.
TF: And that’s a problem. A lot of people miss that with evolutionary design, is that they’re only looking one evolutionary step forward -
JL: They’re solving problems as they come, they’re thinking fairly short-term, right.
TF: You get stuck in a local maximum, right. Where you say hey, we’re trying to evolve in every direction from here and it didn’t go great, and it’s like yeah, because you need to look waaaay higher-level and way further out. And it had often a new direction.
JL: So this is one of the core ways that I operate that’s behind a lot of the projects. I think this is the way the world should be. And then I think well, how do I get there? What pieces do I need? And so if you go back to like 2005, and it’s kind of funny because I did a lot of research, because I planned to explain all this in either a talk or something like that, but I actually went back to, what was 2005 like? And it’s funny because 2005 was really an interesting kind of time. This is right at the beginning of the whole Web 2.0 thing. In 2005 Gmail was still invite-only, Google Maps just came out, right around then Rails and Django just came out, which, you know, there were frameworks before, but nothing as transformative as those things. 2004 is when Web 2.0 was still coming out, 37signals released Basecamp in 2004. The whole thing about software as a service and Creative Commons and Wikipedia and all this new stuff was just a couple years before then. There was no GitHub, there was no EC2 for another year or so. Facebook was still private. All this crazy stuff, totally different time. But all these things were about to change the next year. 2006, Intel MacBook came out, and that’s when everybody got a MacBook. And Flickr was coming out, and that was sort of, to me, that was when we started, Cal’s book, Building Scalable Web Sites, was based on building Flickr, which was one of the first sort of like Web 2.0 things. It was also developed in a modern way. And it was one of the first devops examples.
TF: That was a weird book for me. Like, it could’ve been transformative if I had read it a year before, and instead it was, like, conformative. Like everything that they did, I had independently arrived at. Like we had similar stacks -
JL: Yeah, but that’s kind of the point. Everybody was kind of coming to this new way of doing things.
TF: Yeah, it was just interesting how everyone was co-evolving in the same way. And Flickr, Flickr was actually, like, sort of early in continuous deployment as well. They didn’t do it with the rigor or call it that, but they were deploying like thirty times a day, really early in the start of the company.
JL: So given this context, and really, we felt at the heart of it, given DevHouse and some of the people listening are familiar with the SuperHappyDevHouse event, and those days were really interesting, because you had people from WordPress and Flickr and Digg and Wikipedia and Apple and Yelp and OpenDNS and Firefox and NASA, all the kind of new cool companies, people from them were actually coming to DevHouse and sharing ideas in a very sort of casual, informal way. And we were just sort of collectively getting best practices and seeing what a lot of the latest, what were the cutting edge things people were doing. And DevHouse has all kinds of really interesting things that came out of it. And that’s what I spent a lot of time doing, organizing those events, and doing a lot of random projects. And those random projects, web projects, inspired by all the crazy conversations we were having, turned into, hey, I need to like, make version control for these, and so I started DevjaVu, and that was a startup, it was pre-GitHub, like, here’s a project site, here’s SVN, here’s a wiki.
TF: It was surprisingly like GitHub without the social aspect. It’s a little hard to understand, but back then, one click and you immediately have subversion, and an issue tracker and a wiki, was not a thing.
JL: Right. It was actually a trend, I think Adam’s listening, we called it Peanutbutterization, because at the first DevHouse David Weekly had built PBwiki, which is now PBworks, and it was one of the first sort of like, software as a service wiki services. And until then, you had wikis, but they were all open source, and you had to like, find a host, and follow the instructions, and they were all open source, and all this work, and you had to kind of configure stuff. And here you can just go to a website, put in your name and email, hit a button and now you have a wiki. And that had never, that didn’t really exist before for that kind of thing. And so, it took off really quickly. And then a lot of people started, in our group, making other things, like I made one for forums, and it just started this whole idea — like within this group, it was also happening on a larger scale, like people doing software as a service. But the idea was, track as a service, was basically what it was. And I had some cool people using it, like, we had a deal with EngineYard, and Ezra, the author of Merb that got merged into Rails, was using it for Merb, um, dotCloud, creators of Docker, were using it back then before they had even figured out what they were.
But the most valuable thing that came out of DevjaVu was webhooks. And this is kind of where I got the first sort of idea about what this ideal is, and what I spent the next couple of years talking about. I gave these talks at random places, talking about first, the idea of webhooks is, oh, it’s really simple, it’s just the idea of HTTP callbacks, right, what does that mean. How do you implement that? But I was more interested in the greater ramifications. And so I later framed it as the Evented Web. We have APIs, but if we want to actually have, if we want to wire these things together, you need to kind of have them trigger each other, as opposed to like, at the time we talked about mashups, where it’s like, you would aggregate APIs, you had to create a third thing. You couldn’t wire two things together. GitHub was really small at the time, and they just started a couple of years after DevjaVu which is why I eventually shut it down, because I just wasn’t interested and GitHub was doing a really good job, but they took the webhooks idea to heart, and are one of the best ideas of webhooks that people use on a daily basis. Even if they don’t realize it, a lot of the integrations and stuff that make GitHub so great are because of webhooks.
And so, it wasn’t just about those integrations. The whole idea was I wanted to make the web more programmable, right. This idea that programmer literacy is an important thing, society, it’s a great, and I’m happy to see that everybody can learn how to code now, it’s really accessible, but, uh, and then you have all these great APIs and resources, like Twilio, that are really accessible, like before Twilio we were trying to figure out how to build ways to do something that would do SMS, and for awhile we were like “Well Twitter’s based on SMS”, so we would just kind of reuse the Twitter API as an SMS gateway, and then, you know, Twilio came out, and it’s just like “oh, use Twilio”, right. And so, we’ve got all these cool like, toys, to you know, do phone stuff, or there’s stuff like science as a service kind of things now, you can do like, DNA sequencing, all kinds of crazy stuff like, as a service, through an API.
JL: Right. So this is all part of a system, right. Webhooks was one piece of it, you trigger it, and then what’s on the other end. And so a lot of people came up with systems, like if this then that ways of, you know, I figured that the most expressive bang for buck thing was, just write little scripts. And so, PHP hosting was accessible, but I wanted it to be even easier, so I started a little project called Scriptlets. And the whole idea there was, it was like a pastebin site, but the code that you saved would actually run. And this sort of thing isn’t that uncommon now, probably one of the best examples is by the Auth0 guys, they have a thing called Webtask, and there’s a couple of other ones. There’s been a handful of things that started like this, I remember AppJet was one, it started as a company, and flopped. There’s all these great things and this comes back to one of the philosophical ideas which is that, there’s a lot of great technology services that should exist, because it will allow and open up all these other possibilities, but because there isn’t a market to sustain them, these technologies and services will not -
TF: It’s not even that there’s not a market, but there’s like, no valid monetization strategy.
TF: If I use pastebin I don’t want to pay them any money, I see an ad, I guess that works?
JL: Right, it’s like the market for free services is, you know, there’s not a lot of money in that. Like for VC funded startups.
TF: Right, there’s no way to get VC funding for that. But there’s also like, it would be worth ten cents to me, but there’s no easy way to charge you ten cents right now.
JL: Sure. And I actually remember looking into things, like I looked into a project called DevPay, and all these ways of trying to think about, which I think they use in Amazon for trying to work on stuff, um, or the idea and the name, but uh, so, so the idea was to make the web more programmable, for anybody, not just a startup. Like, I was an individual, I want to improve my productivity, I’m using these two apps, I’m using maybe a modern example is like Asana, and, um, I’m trying to remember, and another project management tool. Let’s say GitHub. Actually, what was I trying to do recently, um -
TF: I mean you just want to do workflow automation.
JL: Yeah. And there’s a lot of people who are doing these kinds of integrations, uh, IFTTT, and others, and the idea was if you laid the infrastructure, and you had webhooks, and you had, like, ways to modify those requests, and make other requests and them easy, you could build stuff on top of that that would make it more accessible, and make it look more like IFTTT, but, the problem is, there isn’t as much of a business — I’m still not even sure what the business model is for IFTTT, and it would be a real shame if at some point, they’ll probably figure it out, but just imagine, it would be a shame if IFTTT had to shut down at some point, right.
JL: And so, that to me was a real problem, eventually, that was something I was working on, I eventually called it Autosustainable Services, which is basically like, how can you have, um, how can you build something that exists on the internet, and not have to worry about starting a company for it to exist?
TF: Yeah and, so this comes back to Megalith, so, when someone asks you what Megalith is, they expect it to fit into one of the current boxes: is this an open source project, is it a venture-backed startup, is it a personal company, and, like, part of it is the idea, of how do you build open source services that live, and fund themselves, and it just works, because that’s an absolutely critical piece of the infrastructure moving forward. Services are really really important and awesome and open source is really really important and awesome and right now the two don’t work together very well.
JL: Yeah. And that’s actually sofuture was talking about, bigger organizations, they’ll, they’ll have a main, and actually this was a term that was used a lot, one of my mentors, who’s an investor, would talk, he would a lot about um, is it a vitamin or a pill? Or another way of talking about it: is it a feature or a product? You need a product to build a company around. A feature isn’t enough to build a company around. But, if there is a product at a company that has a sustainable system, it can be a feature of that.
TF: Right. Or, is this something that the customers want, or is this something that the customers need? Because a lot of people will be like, oh, that’s so cool, I really really want that, and, that doesn’t matter, you know. I really really want a Ferrari but I’m not spending my money on a Ferrari, I’m spending my money on a house, because I need a house.
JL: There’s another great example, and there’s a lot of other factors -
TF: Well, so sofuture was talking about a more interesting specific point which is that um, practically speaking, these venture backed companies find the one thing that monetizes really well, and then make a bunch of money off of that, and then they build a bunch of services around it, that sort of get them a halo effect of “I like gist. Gist is cool. GitHub does gist, I don’t have to pay anything for it, no one does, but because of it I like GitHub and will probably use their services more”, so GitHub can build some services that are — I don’t know if they’re loss leaders, I doubt GitHub is even looking at those numbers, they’re simple, and they’re easy, and that’s fine, because for GitHub it doesn’t matter. They’re making enough money otherwise. They’re also crazy venture-backed. And so, in some sense, twenty years down the road, when they run out of venture money, and they are owned by some evil greedy M&A company that decides to pool a — (sigh) I’m just really sad about SourceForge I guess (laughs) — they try to pull a SourceForge and all of a sudden, every time you read a gist you have to watch a 30 second ad. This could happen, you know. That’s a dystopian future.
JL: Or, you know, Google’s been mentioned, and they do try out wacky ideas, but a lot of the time they’ll shut them down, right. But, a lot of the time it’s -
TF: None of these are models that you can use. You can’t say “I wanna build the IFTTT, so I’m going to build GitHub first to pay for it”.
JL: Right. Or, “I’m going to work at Google so I can work on this thing that has nothing to do with Google”.
TF: (laughing) No, but Google funds it. Yeah.
JL: You kinda have to have some sort of value proposition for them, um, that isn’t this thing that doesn’t make money. So anyway, the reason why I think these ways is we’re so close. It’s like, I can see it, we’re almost there, but there’s a couple of these bottlenecks to have a more programmable world, or this kind of, you know, being able to do these sort of things with the infrastructure that we have — as an individual, not as a company, that has a huge budget. And to me that’s important because that’s what, one of the important things for education, I think, is motivation and inspiration. And one of the coolest things that happens when you’re learning to program is you get some kind of instant feedback of “Oh my god that’s so awesome”, and back in the day it was just like, you know, getting to print something and “I just got the computer to DO something, oh my god”, and then you’re hooked, you know, this device that I’m able to play games on, I just made it do something, exactly what I wanted. And it’s kind of the same feeling, different but on a grander scale, but with things like Twilio. And say you’re learning to program and you use this Twilio library that is a Twilio service, and it’s like “I just made everybody’s phone ring. And then I had a computer say something.” And you just start getting all crazy ideas like whoa, if I can do this, you know, and sometimes it might turn into practical businesses, or something like that, but it doesn’t matter, it’s just tools for solving problems. Maybe you figure out how to solve a problem with like, maybe you’re a parent and your kids are going to school, and there’s a huge problem with the efficiency of homework assignments or something, and you’re like oh, I can just rig this up, and boom, you just solved a problem. Or whatever.
TF: I still get that, ooh, what can I do with it, like, when the Amazon Button came out. And I’m like oh, I can have a button that just orders something from the Internet? Like, okay, where do I put these? What do I want? And now of course it’s locked down and it’s tied to a specific subset of products. Or like, when lightbulbs came out, you could remotely change the hue of, immediately in my head I’m like that’s the coolest thing ever, I want to play with that. I don’t own them, because -
JL: Modern home automation is a really cool thing. That was another example of like -
TF: It’s not actually that useful, but it’s SO cool, you just want to play with it. You just want to affect the world around you.
JL: It’s a gateway. And as things are getting like, we’re talking about the Internet of Things and all, and yeah it’s interesting, yeah, technical problems and all this stuff, but the fact that these things are becoming programmable, it’s like you’re now able to repurpose things. And so to me it’s, you know, that gets at the whole hacker ethos. It’s just like, making things, and trying things, and doing cool things, and repurposing things, and using this to do this, oh, that’s really cool and clever. And I just think that’s a really great way to look at the world, and to inspire more people to do that.
So anyway, a lot of this is about me, and me being like man, if I were a kid and had this, or whatever, that would be amazing, or, if it’s 2005, and I’m having all these cool ideas, because you would, if you were hanging out at DevHouse, you would have all these crazy random ideas of oh, maybe it’s a joke, maybe it’s actually useful, maybe it actually turns into a company, but like, the fact you can just do it, and get that instant feedback, right. Right now, there’s too many hoops to jump through, even just for like local development environments. So there’s just like, a huge systemic problem with a lot of different things in terms of tooling and infrastructure, and so this gets to, like, eventually, because of the webhooks way of thinking, I ended up working at Twilio. And that was the first company, like a big startup, that I worked with. I had worked with NASA, but that was a small sort of thing, working on proto-OpenStack, um, and I was working with a lot of people who were prototyping startup ideas, it was all small type stuff. Twilio was ten people, but it quickly grew into a hundred, and then two hundred, and now it’s like this big thing, but it was the first time I had to deal with the actual problems most startups have to deal with, which is running a distributed, highly available system. And it’s a very different, like, there’s a lot of commonalities, in terms of thinking about systems. In terms of system architecture and all that stuff. It’s a very different set of problems. First of all, they’re problems that people care about, right. Problems about making things highly available, more fault tolerant, these are things that people are willing to pay money for. Whereas webhooks, and like, making things more programmable, it’s like, there’s no market for that. That was one of the things that bothered me, is there are these two levels, like these macro ecosystem level stuff, and there’s nobody that’s really incentivized to really think about improving that at a systemic level.
TF: It’s funny too, because we’ve seen time and again, startups, the API is a side effect, or an engineer pushed it, and said hey, we need an API, and then the API ends up being super important to the business, um, but almost never is a businessperson sitting down and going “Oh, like, an API is a core part of our value proposition and how we’re going to make money, etcetera”. And so, it’s just not getting the resources, ever. It’s not getting the level of attention.
JL: There’s two parts to that. One is, and another great example is just AWS. I remember when AWS stuff first started coming out, they were still a book retailer, and one of the guys behind AWS was like, we’re like a bookstore that’s selling crack out of the back door, because that’s what was getting a lot of growth, and it’s still not their biggest moneymaker -
TF: The profit margins are so much better though. So it is probably going to be the dominant business.
JL: Right. So anyway, there’s people that are incentivized to improve their product. Twilio is incentivized to make Twilio better, Amazon is incentivized to make Amazon better. But who’s incentivized to make them all work together better, and allow you to do more things with them together? There’s nobody that’s really incentivized to do that.
TF: Right, and there’s the big fear that with interoperability, you become a commodity, and you become exchangeable with something else. And that’s not necessarily true, and that’s not strictly true, but the fear there stops people from going down that route a lot of the time.
JL: Well and the biggest thing is there just isn’t money. You want to build your market, your customer base, right. So, so it’s interesting. I think IFTTT is one of the closest things where it’s kind of trying to be this glue, but it’s highly dependent on all these other parties. Very platform-y.
TF: Bruce Schneier described this sort of thing as serfdom. So, we’re in a world where Google is a city-state, and Apple is a city-state, and if you live within their walls you have great benefits. Everything works together. I mean, I have an Android phone because I sign into Google and everything works. And that’s worth it to me, even though iOS has better apps in many cases. But its interoperability with Google is crap. So, in that sense, if I just continue to use Google products, and I stay within their walls, I get this great benefit. Versus if you’re in Apple world, you’re going to put up with a lot of crap, because they’re really bad at web services, but, it all interoperates, and now I’m an Apple serf instead of a Google serf. And you can switch from one to the other, but the switching cost is high. And living in a mixed world is almost impossible, and very painful, and everything has bugs, and no one of these companies really wants to support you. And so we’re in this weird world where, and if you look at a city-state world, one of the big problems was interstate commerce, if you have a tariff because you’re trying to export something from Austin and sell it to Dallas, that is not a good economy. You’re going to suffer from a lack of innovation and a lack of idea sharing. And that’s where we are right now. We’re in super super early days of the web, and again, even though we had open standards before. We’ve regressed a lot when we went mobile, and when we went sort of 2.0, with service as a software.