Speaker 1: Welcome to tech Stuff, a production from iHeartRadio. Hey there,
Speaker 1: and welcome to tech Stuff. I'm your host, Jonathan Strickland.
Speaker 1: I'm an executive producer with iHeartRadio. And how the tech
Speaker 1: are you? You know, when I was a kid, we
Speaker 1: called applications programs, or sometimes we called them software, but
Speaker 1: mainly we called them programs. Heck, it's what the digital
Speaker 1: characters in the film Tron referred to one another, as
Speaker 1: they would say, greetings, program. But then again, when I
Speaker 1: was a kid, hardly anyone even had a computer. If
Speaker 1: you did have a computer, you know, it was its
Speaker 1: own device. It was air gapped because there was no
Speaker 1: such thing as a public internet yet. I mean maybe
Speaker 1: if you were working with you know, arpinnet or something,
Speaker 1: you had a system that was connected, but most of
Speaker 1: us didn't. Also, when I was a kid, the movie
Speaker 1: ticket was four bucks and Disney World was just the
Speaker 1: Magic Kingdom. Also had to walk to school and it
Speaker 1: was uphill both ways, and you know, you get the drift.
Speaker 1: But then things change, right, For instance, Disney went ahead
Speaker 1: and built three other theme parks at Disney World, and
Speaker 1: movie tickets got way more expensive, and we also started
Speaker 1: calling programs applications and something else would emerge that would
Speaker 1: change programming, the rise of the Application programming interface or API.
Speaker 1: So we're doing a tech stuff tidbits about what APIs
Speaker 1: are and where they come from. Now. To be clear,
Speaker 1: the actual concept of the API is quite old. It
Speaker 1: comes from way before my time. So arguably you could
Speaker 1: say the earliest work that would evolve into what we
Speaker 1: would later be called an API actually started back in
Speaker 1: the nineteen forties. But the reason is because you had
Speaker 1: all these different teams around the world making computer systems.
Speaker 1: These systems were kind of you know, they were independent,
Speaker 1: they weren't interoperable, they weren't compatible. So there were people
Speaker 1: who saw the need to create tools that would allow
Speaker 1: for at least some interoperability. Otherwise you're really limiting innovation,
Speaker 1: right If you've got a brilliant programmer, a brilliant developer
Speaker 1: who has come up with this great idea for a
Speaker 1: computer program, but they're only familiar with one computer system,
Speaker 1: you've really limited the utility of that program, at least
Speaker 1: until someone who is familiar with a different computer system
Speaker 1: can come along and then perhaps port that program to
Speaker 1: other systems. So there was the recognition of a need
Speaker 1: to create sort of a common ground that could work
Speaker 1: across different computer systems. The actual term for API, at
Speaker 1: least a version of this term, because back then it
Speaker 1: was called application program interface rather than programming, shows up
Speaker 1: in a paper that was titled Data Structures and Techniques
Speaker 1: for Remote Computer Graphics. It was written by Ira W.
Speaker 1: Cotton and Frank S. Great Rex, which might be the
Speaker 1: best surname I've ever seen great Res Anyway, the paper
Speaker 1: describes the technology needed to allow for a quote, providing
Speaker 1: a remotely accessed interactive computer graphics system end quote. So
Speaker 1: not an API as we would understand it today, at
Speaker 1: least not the kind of API we typically talk about
Speaker 1: when you see something about APIs in the tech news
Speaker 1: these days. The authors were seeking to create a sort
Speaker 1: of common ground that programmers could depend upon so they
Speaker 1: wouldn't have to worry about the underlying hardware, because, like
Speaker 1: I said, the underlying hardware was often unique to a
Speaker 1: specific system. Sometimes even the same computer company might make
Speaker 1: different models that are in aherently incompatible with one another,
Speaker 1: which means you would have to relearn everything in order
Speaker 1: to develop for the new platform. So yeah, an application
Speaker 1: programming interface was kind of an approach to sort of
Speaker 1: create almost like a universal translator just for computer systems,
Speaker 1: not for people, but for computer systems, so that programmers
Speaker 1: wouldn't have to specialize in something and potentially end up
Speaker 1: becoming obsolete themselves. Right if you were a programmer and
Speaker 1: you tied yourself down to a specific type of computer,
Speaker 1: and let's say that that computer company goes out of business,
Speaker 1: you would have all this knowledge and expertise that was
Speaker 1: sunk into something that no longer was relevant. That would
Speaker 1: be disastrous on your part. You would have to start
Speaker 1: all over again. So APIs could help create a method
Speaker 1: for creating bridging material between computer systems. In nineteen seventy four,
Speaker 1: which is still technically before my time, only by a
Speaker 1: little bit, a paper by CJ. Date titled the Relational
Speaker 1: and Network Approaches Comparison of the Application Programming Interface would
Speaker 1: not only add ing to programs, and now we got
Speaker 1: application program Ming interface. This paper also expanded the concept
Speaker 1: of an API, in this case involving databases. So not
Speaker 1: just computer systems. Now now we're talking about databases and
Speaker 1: ways to be able to create a bridging material so
Speaker 1: that you could access different databases through the same application.
Speaker 1: This led to the American National Standards Institute as well
Speaker 1: as the Standards Planning and Requirements Committee to define and
Speaker 1: adopt API for database management systems. What happened next was
Speaker 1: that programmers and computer scientists began to develop APIs for
Speaker 1: all sorts of computational tasks. We had seen it for
Speaker 1: database management, and we would see it for other stuff too.
Speaker 1: These APIs would support different programming languages, so that programmers
Speaker 1: could make use of the API without worrying about which
Speaker 1: programming language they needed to use when they were creating
Speaker 1: the program because not all programmers are fluent in every
Speaker 1: programming language, they typically specialize in a couple. In turn,
Speaker 1: the API would become, as Carl Malamud put it, a
Speaker 1: way to make quote a set of services available to
Speaker 1: a programmer for performing certain tasks end quote. Which seems
Speaker 1: vague in general, but that was on purpose, right. It
Speaker 1: wasn't meant to pigeonhole API for specific uses, but rather
Speaker 1: making it an umbrella term for a way of allowing
Speaker 1: developers to access a set of services that were well
Speaker 1: suited for performing certain tasks. It was all about kind
Speaker 1: of removing some of the challenges to programming right That
Speaker 1: whole thing about let's not reinvent the wheel. That's kind
Speaker 1: of what API was all about, was creating these sort
Speaker 1: of standardized approaches so that programmers could really focus on
Speaker 1: making better programs with a shorter development process that and
Speaker 1: not have to worry about reinvention all the time. Now,
Speaker 1: I would argue that the types of APIs that we
Speaker 1: typically talk about today really originate from a dissertation that
Speaker 1: was made by a guy named Roy Fielding while he
Speaker 1: was pursuing his PhD. He called his dissertation Architectural Styles
Speaker 1: and the Design of Network Based Software Architectures. Now that
Speaker 1: title doesn't scream API, right. If I just saw that
Speaker 1: title listed on a citation list, I wouldn't immediately think, oh,
Speaker 1: that that's a paper about APIs. But it is actually,
Speaker 1: and Fielding also presented ideas about how APIs work in
Speaker 1: the age of the Internet. So he wrote this dissertation
Speaker 1: in two thousand. At that time, there was an emerging
Speaker 1: technology that would shape the Web and later the mobile Internet,
Speaker 1: and that was the Web API or the web AP
Speaker 1: as I would prefer to call it, But then no
Speaker 1: one would know what I was talking about, so I
Speaker 1: won't do that again. But in two thousand, and that
Speaker 1: same year, Salesforce would release what a lot of folks
Speaker 1: would point to as the first modern API. In fact,
Speaker 1: we even have a precise date for this, which is
Speaker 1: unusual when I'm talking about the history of stuff. Often
Speaker 1: you can't nail it down to even a specific year.
Speaker 1: But in this case, we have a specific date February seventh,
Speaker 1: two thousand. That's because Salesforce actually unveiled this API during
Speaker 1: the IDG Demo two thousand conference. The Salesforce API allowed
Speaker 1: its customers and Salesforce's customers or other companies. Right, Like,
Speaker 1: you typically have small businesses that are customers of Salesforce
Speaker 1: and they are essentially offloading certain business needs to Salesforce. Well,
Speaker 1: in this case, the API would allow these businesses to
Speaker 1: create an ecosystem in which the businesses could share data
Speaker 1: across their different applications. So you know, a business can
Speaker 1: be really really complicated, right. You can have all these
Speaker 1: different departments. You can have each department having its own
Speaker 1: systems you dedicated for that department, which is cool, but
Speaker 1: it also means that you have the danger of each
Speaker 1: department becoming a silo so that you can't easily share
Speaker 1: information from department to department, and that can really end
Speaker 1: up inhibiting innovation and advancements, and it can be a
Speaker 1: big hit on efficiency. So what Salesforce was doing was
Speaker 1: releasing this API where its customers could make use of
Speaker 1: this and be able to share across different applications all
Speaker 1: the same information and make better tools. That would allow
Speaker 1: for these businesses to operate more efficiently and effectively, and
Speaker 1: that would be a better end experience for the user,
Speaker 1: and that philosophy would become sort of an underlying element,
Speaker 1: a foundational element for APIs moving forward. We're going to
Speaker 1: take a quick break. When we come back, i'll explain
Speaker 1: a bit more about how this would develop over the
Speaker 1: following years. Okay, we're back, So not too long after
Speaker 1: Salesforce launched its API, like you know, half a year later,
Speaker 1: a little more than half a year, eBay would follow suit.
Speaker 1: It launched its API in November of two thousand. This
Speaker 1: would let licensed eBay partners access a framework that would
Speaker 1: allow the developers to incorporate eBay services into other websites,
Speaker 1: and technically it would also allow for applications as well.
Speaker 1: So now like if you were a licensed eBay partner,
Speaker 1: you could incorporate some of ebase functionality into your own website.
Speaker 1: This was a pretty limited version of the API in
Speaker 1: the sense that you had to be a licensed partner first,
Speaker 1: and that was not the easiest thing to do, so
Speaker 1: it was limited in the number of organizations that can
Speaker 1: make use of the API, but the concept was a
Speaker 1: strong one. Amazon would follow behind in two thousand and
Speaker 1: two and it launched its own API as well as
Speaker 1: it launched Amazon Web Services. Now this was not the
Speaker 1: fully fledged Amazon Web Services we would talk about today.
Speaker 1: That would happen a few years later when we would
Speaker 1: get introduction of a couple of other big tools, but
Speaker 1: it was the beginning of a massive move for Amazon,
Speaker 1: one of the most profitable moves that Amazon would ever make.
Speaker 1: If you were a developer, this meant you could actually
Speaker 1: include Amazon functionality on say your web page, and this
Speaker 1: mud give people a chance to search for products and
Speaker 1: do some window shopping right from the comfort of your
Speaker 1: web page. Maybe you even have your web page dimn't
Speaker 1: you know, show off products that you're talking about or
Speaker 1: that are related to whatever the web page is focused on,
Speaker 1: that kind of thing. And it meant that by incorporating
Speaker 1: that directly into your web page. People could access that
Speaker 1: stuff without leaving your site, you know, and your bounce
Speaker 1: rate would go down and your engagement rate would go
Speaker 1: way up. Now, it would take a couple more years
Speaker 1: for other companies to really push into API development. It
Speaker 1: was a little slow. These companies were pioneers and others
Speaker 1: took a bit of time to kind of catch up.
Speaker 1: For one thing, you have to remember, like two thousand,
Speaker 1: two thousand and one, that's when we're talking about the
Speaker 1: dot com bubble bursting, especially in the wake of nine
Speaker 1: to eleven and here in the United States, and so
Speaker 1: that would end up taking a lot of the wind
Speaker 1: out of the sales of companies that otherwise were innovating
Speaker 1: in the web space. So that I think slowed down
Speaker 1: API development. But one of the things we did see
Speaker 1: in the mid two thousands was the emergence of widgets,
Speaker 1: which were largely possible because of APIs. Do you all
Speaker 1: remember widgets? I mean, there's still technically a thing. It's
Speaker 1: not like they went away, it's just they were really
Speaker 1: being pushed really hard in the mid to late two
Speaker 1: thousands on everything from early social media platforms to really
Speaker 1: like I remember seeing them everywhere at cees. Right, you
Speaker 1: would see a refrigerator and it would have widgets, or
Speaker 1: a television and it had widgets. Everything had widgets on them,
Speaker 1: and they were always these little icons that linked to
Speaker 1: some sort of basic functionality. Right. It was usually very specific,
Speaker 1: like it might be a weather report widget, so you
Speaker 1: could get a very quick run down on what current
Speaker 1: and predicted whether conditions are or we're going to be.
Speaker 1: Or it might be a stock ticker, or it could
Speaker 1: be a news headline ticker. You get the idea. It
Speaker 1: was very specific and purpose built, and it was largely
Speaker 1: thanks to APIs that it was possible. Right. The widgets
Speaker 1: were typically tapping into some other platforms information and then
Speaker 1: presenting that information to you in the form of the widget.
Speaker 1: In two thousand and four, Flicker introduced It's API that
Speaker 1: gave people the chance to embed their images that they
Speaker 1: had been storing on Flicker on other platforms, including things
Speaker 1: like web pages or social media. That was incredible, Right,
Speaker 1: You could have Flicker act as your repository of images,
Speaker 1: and then you could use the embed feature to share
Speaker 1: those images on other platforms without having to upload the
Speaker 1: same picture to all the different places you wanted. And
Speaker 1: it really streamlined things, and it really pushed Flicker into
Speaker 1: becoming a leader for online images for quite some time
Speaker 1: because they really got ahead of things. In two thousand
Speaker 1: and six, we had a couple of big APIs that emerged.
Speaker 1: One came from Twitter, you know, Rest in Peace. I guess,
Speaker 1: you know, we could refer to it as X now,
Speaker 1: but it was Twitter back then and Facebook they both
Speaker 1: introduced APIs in two thousand and six, and this gave
Speaker 1: developers a chance to tap into the functionality of those
Speaker 1: platforms in new ways, and that's kind of what led
Speaker 1: to third party Twitter feed readers, for example, like tweet deck.
Speaker 1: In fact, tweet deck became so useful and popular that
Speaker 1: Twitter actually acquired it and now it belongs to X
Speaker 1: And honestly, I'm curious now what it's called, because I
Speaker 1: imagine it's not called tweet deck within X anymore since
Speaker 1: they got rid of all the Twitter and tweet stuff
Speaker 1: and I didn't look it up, so I don't know.
Speaker 1: I no longer access tweet deck because it's behind a paywall.
Speaker 1: But yeah, so developers were able to add in new
Speaker 1: functions in these new services that tapped into these platforms,
Speaker 1: and they were functions that you wouldn't find on the
Speaker 1: vanilla version of the service. So, for example, let's talk
Speaker 1: about Twitter and tweet Deck. With tweet Deck, a user
Speaker 1: could create a single view that would incorporate multiple Twitter accounts,
Speaker 1: separated by columns. So if you were someone like me,
Speaker 1: you would have one column that would just show you
Speaker 1: the incoming Twitter feed, like all the posts from the
Speaker 1: folks that you follow. You could have a column that
Speaker 1: shows your own personal Twitter messages as well as the
Speaker 1: replies and quotes and that kind of stuff, so all
Speaker 1: the engagement with your own Twitter messages. A third column
Speaker 1: might show, say, your podcasts tweets and replies and stuff,
Speaker 1: so it's the same thing as your own personal account,
Speaker 1: but for your podcast account and so on. Like, you
Speaker 1: could have multiple columns stretching across the screen, each one
Speaker 1: focusing on something separate on Twitter, but all incorporated into
Speaker 1: a single so you have a very easy way to
Speaker 1: monitor this. This was really useful for social media managers,
Speaker 1: right who might be monitoring multiple accounts. Let's say that
Speaker 1: you're a manager and you have several clients. You could
Speaker 1: have a tweet deck set up with all the different
Speaker 1: client columns there and in a one view you can
Speaker 1: quickly see what's going on. It's such a useful suite
Speaker 1: of features that Twitter would buy it, and now Elon
Speaker 1: Musk has locked it behind a paywall. You have to
Speaker 1: be a subscriber to access those features. So yeah, bumber.
Speaker 1: It's why I don't really check tech Stuff's Twitter feed anymore,
Speaker 1: because I had it incorporated into tweet Deck, and now
Speaker 1: I can't access tweet Deck because I'm not a subscriber,
Speaker 1: So yeah, it's kind of lost. I could technically log
Speaker 1: into x and tech Stuff's account and check it that way,
Speaker 1: but y'all, it's just the mental energy needed for me
Speaker 1: to do that just doesn't exist in me anyway. Facebook's
Speaker 1: API would let developers create all sorts of stuff that
Speaker 1: could be built on top of Facebook, including things like
Speaker 1: games and surveys and all that sort of stuff. This
Speaker 1: is what eventually led to the Cambridge Analytica scandal, in fact,
Speaker 1: because a developer created a survey tool that was paying
Speaker 1: people to take the survey. But what the people didn't
Speaker 1: know is that by agreeing to the survey, which was
Speaker 1: all based integrated into Facebook using Facebook's API, then the
Speaker 1: actual survey could gather information not just about the person
Speaker 1: taking the survey in the first place, but all the
Speaker 1: people they connected to through Facebook, like if their friends
Speaker 1: had public Facebook profiles, the app could then access all
Speaker 1: of that information as well. So that's what led to
Speaker 1: a big scandal, because it meant that the app developer
Speaker 1: was able to access information from people who never consented
Speaker 1: to share that information in the first place. Facebook ultimately
Speaker 1: changed its API to restrict apps so that they could
Speaker 1: only request access to info that was relevant to whatever
Speaker 1: the app was doing. So that way, if you were
Speaker 1: to download or install an app that was like a
Speaker 1: fun horoscope app, it wasn't for some reason getting access
Speaker 1: to all your messages and stuff like that. That would
Speaker 1: not be necessary for that particular app. But back in
Speaker 1: the old days there were fewer restrictions, and we saw
Speaker 1: what happened as a result of that. In two thousand
Speaker 1: and seven, we had another huge development that would have
Speaker 1: a big push on APIs, and that was the introduction
Speaker 1: of the iPhone. So I've said this before, the iPhone
Speaker 1: was not the world's first smartphone. It had followed behind
Speaker 1: lots of other smartphones. But before the iPhone, particularly here
Speaker 1: in the United States, smartphones were not really a consumer product.
Speaker 1: They were sort of a prosumer product. It was the
Speaker 1: kind of thing you would expect a business executive to own,
Speaker 1: like a BlackBerry, something like those types of smartphones. But
Speaker 1: your average person didn't have a smartphone. That's not how
Speaker 1: they accessed the web. If they were accessing the web
Speaker 1: at all, they were doing so on a desktop or
Speaker 1: laptop computer, maybe a web TV if they were one
Speaker 1: of those folks, but otherwise you were accessing it on
Speaker 1: like a computer. The iPhone would change that, right, and
Speaker 1: that would mark the beginning of what would become a
Speaker 1: massive shift in web development and web design, this migration
Speaker 1: to the mobile web. As more people adopted smartphones, there
Speaker 1: was this need to make it easier for those folks
Speaker 1: to view and interact with online content. Right, Like, you
Speaker 1: couldn't just present a web page to a smartphone the
Speaker 1: same way you would to a PC or laptop because
Speaker 1: the landscape was to different, right, the size of the
Speaker 1: screen was different. It would make it very challenging to
Speaker 1: read or interact with stuff that was on a web page.
Speaker 1: You had to come about it in a different way.
Speaker 1: But that also meant that there were new opportunities to
Speaker 1: develop applications that were built on top of APIs that
Speaker 1: could work specifically for smartphones, that could lay things out
Speaker 1: in a way that made it easier to interact with
Speaker 1: the content that was on the web. So the mobile
Speaker 1: web really created a huge, huge change in the approach
Speaker 1: to APIs. And there was another one that was going
Speaker 1: on at the same time, and that was the shift
Speaker 1: to the cloud. This was happening more in the background,
Speaker 1: but you had more and more companies that were taking
Speaker 1: advantage of cloud services in order to offload things that
Speaker 1: traditionally would have to all happen in house. Right, So
Speaker 1: in the old days, if you had a company that
Speaker 1: had its own databases and computer systems and stuff, you
Speaker 1: had to keep all of that stuff on premises. You
Speaker 1: were responsible for keeping up with all the hardware, maintaining
Speaker 1: the software, updating features, that sort of stuff. That's a
Speaker 1: lot of work. But cloud services offloaded a lot of
Speaker 1: that and really made it possible for software as a
Speaker 1: service to emerge. I'll talk a little bit more about
Speaker 1: that in just a second. We're going to take another
Speaker 1: quick break and we'll be right back. So, yeah, I
Speaker 1: mentioned before the break the emergence of cloud services. Now,
Speaker 1: they did exist before the mid two thousands, but it
Speaker 1: was right around that time where they started to really
Speaker 1: take off, and in fact, we could point to two
Speaker 1: thousand and six as being a huge year for that
Speaker 1: because that's again when Amazon would introduce some new features
Speaker 1: in the cloud, like Amazon Compute and Amazon Storage services
Speaker 1: that would become hugely influential in the space. In fact,
Speaker 1: it made Amazon become the dominant player in the cloud
Speaker 1: computing space in many ways. So now you had the
Speaker 1: ability for businesses to tap into functionalities that otherwise they
Speaker 1: would have to develop all in house and it might
Speaker 1: take them years to do or it might be such
Speaker 1: a big investment that they never would be able to
Speaker 1: do it. Now, by becoming customers of these cloud computing companies,
Speaker 1: they could end up offloading the compute and storage stuff
Speaker 1: to another company and get their developers to create new
Speaker 1: applications that tapped into that ability and leverage the information
Speaker 1: that the business was gathering. So it became possible to
Speaker 1: create entirely new services. And this is really when we
Speaker 1: started to see software as a service explode as a
Speaker 1: business model, because developers could create a tool that would
Speaker 1: meet the needs of their customers and then charge their customers,
Speaker 1: maybe even setting up a subscription service for their software,
Speaker 1: and that would turn an application into an ongoing revenue generator.
Speaker 1: Like in the old days. Let's say you made a
Speaker 1: word processing program. You would sell that in stores and
Speaker 1: you would get a portion of every sale that was made.
Speaker 1: Right that was the old day of days of programming.
Speaker 1: You'd make a program, people would buy a copy of
Speaker 1: the program, you hope that not too many people pirated
Speaker 1: your stuff, and you made money. Software as a service
Speaker 1: is totally different. You would make an application and you
Speaker 1: would sell access to that application, which would be based
Speaker 1: in the cloud, built on APIs, tapping into all these
Speaker 1: powerful other platforms, and your customers would pay you an
Speaker 1: on going subscription fee to access that tool, and you
Speaker 1: would be able to make money off the same application
Speaker 1: with the same customer over and over again, as opposed
Speaker 1: to doing it that one time and that one point
Speaker 1: of sale. So it really was a truly enormous change
Speaker 1: in business. These days, APIs allow developers to make tons
Speaker 1: of new products and services by building on various foundations. Typically,
Speaker 1: the developers are also paying for the use of APIs.
Speaker 1: I mean it depends. The platform may have a tiered
Speaker 1: list of API access with a free tier at the bottom,
Speaker 1: which might limit the features that developers can tap into,
Speaker 1: or maybe a charge based upon how frequently the app
Speaker 1: that the developers working on is going to reference the
Speaker 1: underlying platform. So when we say reference, what we're talking
Speaker 1: about is the app itself, the end app how frequently
Speaker 1: does it have to access the underlying platform. So if
Speaker 1: you've built a Twitter based app, for example, or X,
Speaker 1: I guess we should say an X based app. How
Speaker 1: frequently is that app referencing X? How quick? How many
Speaker 1: times does it have to pull information from or post
Speaker 1: information to the underlying platform? That would be a reference.
Speaker 1: And one way that companies will charge developers is by
Speaker 1: adding up the number of times their apps are referencing
Speaker 1: the underlying platform and saying, all right, you are putting
Speaker 1: X demand on this platform. Shouldn't use X since that
Speaker 1: is a platform. You're putting this specific amount of demand
Speaker 1: upon our platform. In turn, we are going to charge
Speaker 1: you this amount because you are putting this load on
Speaker 1: us in order to power your application. So this has
Speaker 1: actually led to some issues recently which I've td about
Speaker 1: on this show, but you've probably also just heard out
Speaker 1: and about which is that A couple of different companies,
Speaker 1: specifically x formerly known as Twitter and Reddit, have alienated
Speaker 1: some developers by changing up their API. So by doing
Speaker 1: things like getting rid of free tiers of service and
Speaker 1: hiking up the cost of other tiers, these companies have
Speaker 1: really upset a lot of developers and users. So these
Speaker 1: companies are charging developers based on essentially how frequently the
Speaker 1: apps are referencing those underlying platforms. So Reddit is a
Speaker 1: great example. Reddit did this thing where they changed how
Speaker 1: much they were charging developers for really popular apps. So
Speaker 1: let's say that you've made a Reddit app, and really
Speaker 1: this let's just say, this app is just a way
Speaker 1: to browse and post to Reddit. Right, we're not reinventing
Speaker 1: the wheel. We're not making anything spectacular. What we're making
Speaker 1: is a Reddit tool that lets you, you know, access subreddits,
Speaker 1: read posts, and make posts. And that's it. But it's
Speaker 1: got a really good user interface, it's really well organized,
Speaker 1: easy to use, its attractive. Uh, it's got you know,
Speaker 1: things in places that make a lot of sense, and
Speaker 1: a lot of users see it as being superior to
Speaker 1: the official Reddit app, So they gravitate toward this third
Speaker 1: party app that you have developed because they just like
Speaker 1: the way that you've approached this, but your app has
Speaker 1: become really really popular and people are using it a lot.
Speaker 1: It's not just that a ton of people have downloaded
Speaker 1: and installed your app, it's that they're on the app
Speaker 1: all the time, and so your app is referencing Reddit
Speaker 1: a lot. Every single day. Reddit is tallying up those references,
Speaker 1: and then it sends you a bill, and that bill
Speaker 1: is truly massive, like we're talking like millions of dollars
Speaker 1: a year massive, And meanwhile, your app is not really
Speaker 1: generating that much revived Like maybe you built this app
Speaker 1: and maybe you are making some money off of it,
Speaker 1: but it's nothing compared to the bill that's coming in.
Speaker 1: So you literally cannot afford to stay in business because
Speaker 1: the bill you have to pay to Reddit is greater
Speaker 1: than what you're making in revenue, so you have to
Speaker 1: shut down. This is what happened over at Reddit. Some
Speaker 1: very popular Reddit third party apps had to close up
Speaker 1: shop because they couldn't afford to stay in business, and
Speaker 1: a lot of the Reddit community got extremely upset about
Speaker 1: this and felt that Reddit was pricing out third party
Speaker 1: developers and trying to force people into using the actual
Speaker 1: Reddit app, which a lot of people did not like,
Speaker 1: and as a result, we saw lots of protests on Reddit.
Speaker 1: Subreddits went dark for a couple of days, some longer
Speaker 1: than just a couple of days. Now there's this ugly
Speaker 1: business of Reddit coming in and removing moderators of certain
Speaker 1: subreddits who were refusing to give up on protesting this change,
Speaker 1: and it's continuing to this day. It's still ugly. There
Speaker 1: are still some subreddits that are feeling the effects of this.
Speaker 1: The leadership at Reddit haven't really budged on the issue,
Speaker 1: and meanwhile, the users are just as angry now as
Speaker 1: they were earlier this summer when the changes were first
Speaker 1: kind of coming to light. So APIs can be a big,
Speaker 1: big deal, right. They can be a big revenue generator,
Speaker 1: They can be a big way to build loyalty in
Speaker 1: a customer base. But they can also be at the
Speaker 1: heart of great controversy if a company decides to make
Speaker 1: changes to its policies and at least in the eyes
Speaker 1: of the public, disproportionately hurt the developers who are making
Speaker 1: use of those APIs. So I hope this episode helps
Speaker 1: clear up what APIs are, what they're for, and why
Speaker 1: they are important. They are the thing the gateway that
Speaker 1: allows into developers to tap into the massive features that
Speaker 1: are found in really important platforms and to create new
Speaker 1: experiences for people that we have. If I were to
Speaker 1: do an episode just on a list of apps that
Speaker 1: companies bought because the apps that were developed by third
Speaker 1: parties were better than the stuff that was coming directly
Speaker 1: out of the company itself, that would be an epic
Speaker 1: episode because there are countless versions of that, and it
Speaker 1: really just shows that, you know, innovation is not something
Speaker 1: that you can just contain within four walls. Innovation comes
Speaker 1: from entire communities and people who are only tangentially connected
Speaker 1: to the actual underlying you know thing, and it's much
Speaker 1: better to allow that kind of innovation to flourish because
Speaker 1: we get the best tools and best experiences that way.
Speaker 1: And I don't think it really profits anyone for love
Speaker 1: that down too much. I mean, I get the need
Speaker 1: to generate revenue to an extent, but I feel like
Speaker 1: the extent we have seen has far outstretched creduelty, let's say.
Speaker 1: In other words, I don't necessarily believe it when Reddit
Speaker 1: says that they have to put in these exorbitant fees
Speaker 1: in order to pay their Internet bills. I don't know
Speaker 1: that that's really that. I'm sure there's some truth to that,
Speaker 1: but I don't know that it necessitates charging a developer
Speaker 1: millions of dollars a year because their app is so popular.
Speaker 1: I hope you are all well. I hope you enjoyed
Speaker 1: this tech Stuff Tidbits episode, and I will talk to
Speaker 1: you again really soon. Tech Stuff is an iHeartRadio production.
Speaker 1: For more podcasts from iHeartRadio, visit the iHeartRadio app, Apple Podcasts,
Speaker 1: or wherever you listen to your favorite chops