3 ms·

The rule that you shouldn’t build your business on someone else’s API obviously applies here and in the end Reddit is of course justified in choosing to shut ou

by fwlr 3y ago

The rule that you shouldn’t build your business on someone else’s API obviously applies here and in the end Reddit is of course justified in choosing to shut out third party apps. But I must say it is simply hilarious that their exorbitant new price was so absurd that when devs quoted it back to them as a buyout rate, Reddit felt like they were being blackmailed. I mean that’s literally getting offended at your own number.

unshavedyak 3y ago
> The rule that you shouldn’t build your business on someone else’s API obviously applies here Is there an alternative? If your business is an app around someone elses API, as it is in this case, Tweetbot, etc - it seems super reasonable no? Yea the API could change at any moment. So maybe don't over leverage yourself. Play it safe, knowing any day could be the apps last.. but beyond that "building your business around someone else's API" isn't bad here is it? I'd happily do it if it was going to make some money. So i'm kinda unsure where the distinction is for that phrase. When is it not a good idea? Seems a better phrase would be one that includes knowing what type of business you have.
- vinyl7 3y ago
  It just depends on what your timeline is. Tech is very ephemeral, so anything that exists today will be gone eventually. So build an app using an api, but i would not rely on it to be a viable product for more than a couple of years. So its fine if you want beer money, but it wont be a career.
- tensor 3y ago
  Personally, I think it's reasonable for a small 1-2 person shop, but if you are planning a larger company it's pretty irresponsible to build it around someone's API like this. If you can't feasibly replace a given API, then you're business is incredibly fragile, and I think it's unfair to employ a large number of people in a fragile business without clearly stating to them that they could all be unemployed in an instant.
- fwlr 3y ago
  If you have good reasons to build on a third party API and you do it responsibly (not over-leveraging yourself, not annoying the API provider) then it’s fine, sure. Perhaps the real value of that rule is that it makes you conscious of the risks and pushes you to mitigate them.
- 6510 3y ago
  Reddit is dead, Twitter is dead, RSS lives on. RSS is an API first, there is no CEO, there are no investors, the peasants tried to stage a revolt against it many times. Everyone on HN should probably watch this clip from Aaron Swartz again. (who deserves blame for the creation of RSS and Reddit) https://commons.wikimedia.org/wiki/File:Aaron_Swartz_-_The_Network_Transformation.webm https://commons.wikimedia.org/wiki/File:Aaron_Swartz_-_The_N... It is odd we are to stupid to understand while he explains things so wonderfully?
- willis936 3y ago
  The alternative is to pursue safer business. It makes sense from a risk mitigation perspective, but it doesn't sound like the reddit third party app devs were unaware or incorrectly weighing this. It sounded like they took on personal and financial risk to do something they wanted to do and add something to the world that they wanted to. Rather than foolish, I find it admirable to abandon profit and security for principles. Especially in the context of reddit being founded on principles. Regardless of what happens to the site and the shareholders: it is safe to say that the true reddit is already dead.
- Izkata 3y ago
  > > The rule that you shouldn’t build your business on someone else’s API obviously applies here > Is there an alternative? Scraping. They're joking on some subreddits about how reddit is about to see costs skyrocket when third-party tools start requesting and parsing whole pages instead of using a lightweight API.
dabluecaboose 3y ago
>But I must say it is simply hilarious that their exorbitant new price was so absurd that when devs quoted it back to them as a buyout rate, Reddit felt like they were being blackmailed. I mean that’s literally getting offended at your own number. It was even worse, from what I remember. It was half their number that outraged them.
- sunbum 3y ago
  It was half 1 year of their number.
deely3 3y ago
So, you should never use Google, Amazon, Apple, banking system API. What the alternative?
- fwlr 3y ago
  The rule isn’t “never use an API”. If you’re a search company you shouldn’t build your business on the Google search API, if you’re a compute provider you shouldn’t build your business on the AWS API, if you’re a payment provider you shouldn’t build your business on the Stripe API, etc. So the pedantic version of the rule is like, don’t build your business on just repackaging another company’s API, I guess?
  - Dudester230602 3y ago
    If you are a game development company you shouldn't build your business on someone else's gaming API (aka game engine)?
    - callalex 3y ago
      That’s not quite equivalent, but there was a huge developer community upset when Unity switched to their freemium revenue sharing model.
    - fwlr 3y ago
      Probably, yeah. Game development is a bit of an exception to many “rules” of the software business, since creative and artistic expression are significant motivating factors substituting in for a portion of the usual profit motive, in a way you generally don’t see in other software (look for the phrase ‘labour of love’ for examples). Game engines are also not quite APIs imo, they are more like (massive) libraries that you vendor (bundle with your game and install as dependency). This inures you against some issues with building on a third party API, but not all (e.g. price changes are still an issue, but at a different granularity: “licensing fees per game” rather than “usage fees per call”). These minor caveats aside, your example is good and worth investigating. Off the top of my head, I believe big game development companies are indeed pretty diversified when it comes to game engines, reflecting the wisdom of not building on someone else’s API. Riot Games uses their own engine for League of Legends, but uses Unreal for Valorant and Unity for Runeterra and Wild Rift. Blizzard uses their own engine(s) for StarCraft/Warcraft/WoW/Overwatch/Diablo, but uses Unity for Hearthstone. They did license Unreal Engine at some point but I’m not sure if they have used it. Activision uses their own engine (IW) for all of their Call of Duty games. EA uses Unreal and Unity for a few games, but largely uses their own engine (Frostbite). Ubisoft used to use Unreal for their Tom Clancy series (e.g. Ghost Recon and Splinter Cell) but in fact moved that series to their own engines (Ghost Recon is now on Ubi’s Anvil engine while The Division is on their Snowdrop engine), specifically citing concerns over control and licensing fees as the reason for the move. Their Assassin’s Creed series has always been on their Anvil engine. I believe Ubisoft has another handful of their own engines as well, not quite “one engine per game series” but maybe close to that - an extreme example where they aren’t even willing to build one department’s business on another department’s API! Valve uses their own engine, Source, for their games. (They have worked with both Unity and Unreal, but I believe this was for their VR and console hardware?) Nintendo also uses their own engines for their games. (Like Valve, they have worked with both Unreal and Unity for their Switch handheld hardware.) Epic Games is the only big game developer I can think of that is not diversified, they use Unreal exclusively. Being as they are also the developers of Unreal engine, this isn’t a case of relying on a third party. So overall I would say yes, even in game development it’s clear that companies go to significant expense to not rely on someone else’s gaming API, and with Ubisoft there’s at least one example of a company publicly learning this exact lesson.
sodality2 3y ago
This is missing the context that the Reddit staff member immediately apologized for interpreting it as a threat several times, and spez still chose to regurgitate the same claim. https://gist.github.com/christianselig/fda7e8bc5a25aec9824f915e6a5c7014 https://gist.github.com/christianselig/fda7e8bc5a25aec9824f9...
- deleted 3y ago
  [deleted]
- ChocMontePy 3y ago
  I don't think that's a good argument. If someone says something sexually harassing to me at work and I politely say "Oh, I guess I misunderstood" to defuse the situation, it would be specious for them to later claim that my statement of misunderstanding means that no sexual harassment could have taken place.
  - Niksko 3y ago
    The dev recorded things. You can hear it for yourself. To me it's pretty clear that he's saying 'my API is loud in terms of API calls, it would be quiet if it went away' not 'I will go away quietly if you pay me hush money'

by fwlr 3y ago

unshavedyak 3y ago

> The rule that you shouldn’t build your business on someone else’s API obviously applies here Is there an alternative? If your business is an app around someone elses API, as it is in this case, Tweetbot, etc - it seems super reasonable no? Yea the API could change at any moment. So maybe don't over leverage yourself. Play it safe, knowing any day could be the apps last.. but beyond that "building your business around someone else's API" isn't bad here is it? I'd happily do it if it was going to make some money. So i'm kinda unsure where the distinction is for that phrase. When is it not a good idea? Seems a better phrase would be one that includes knowing what type of business you have.

vinyl7 3y ago
It just depends on what your timeline is. Tech is very ephemeral, so anything that exists today will be gone eventually. So build an app using an api, but i would not rely on it to be a viable product for more than a couple of years. So its fine if you want beer money, but it wont be a career.
tensor 3y ago
Personally, I think it's reasonable for a small 1-2 person shop, but if you are planning a larger company it's pretty irresponsible to build it around someone's API like this. If you can't feasibly replace a given API, then you're business is incredibly fragile, and I think it's unfair to employ a large number of people in a fragile business without clearly stating to them that they could all be unemployed in an instant.
fwlr 3y ago
If you have good reasons to build on a third party API and you do it responsibly (not over-leveraging yourself, not annoying the API provider) then it’s fine, sure. Perhaps the real value of that rule is that it makes you conscious of the risks and pushes you to mitigate them.
6510 3y ago
Reddit is dead, Twitter is dead, RSS lives on. RSS is an API first, there is no CEO, there are no investors, the peasants tried to stage a revolt against it many times. Everyone on HN should probably watch this clip from Aaron Swartz again. (who deserves blame for the creation of RSS and Reddit) https://commons.wikimedia.org/wiki/File:Aaron_Swartz_-_The_Network_Transformation.webm https://commons.wikimedia.org/wiki/File:Aaron_Swartz_-_The_N... It is odd we are to stupid to understand while he explains things so wonderfully?
willis936 3y ago
The alternative is to pursue safer business. It makes sense from a risk mitigation perspective, but it doesn't sound like the reddit third party app devs were unaware or incorrectly weighing this. It sounded like they took on personal and financial risk to do something they wanted to do and add something to the world that they wanted to. Rather than foolish, I find it admirable to abandon profit and security for principles. Especially in the context of reddit being founded on principles. Regardless of what happens to the site and the shareholders: it is safe to say that the true reddit is already dead.
Izkata 3y ago
> > The rule that you shouldn’t build your business on someone else’s API obviously applies here > Is there an alternative? Scraping. They're joking on some subreddits about how reddit is about to see costs skyrocket when third-party tools start requesting and parsing whole pages instead of using a lightweight API.

dabluecaboose 3y ago

>But I must say it is simply hilarious that their exorbitant new price was so absurd that when devs quoted it back to them as a buyout rate, Reddit felt like they were being blackmailed. I mean that’s literally getting offended at your own number. It was even worse, from what I remember. It was half their number that outraged them.

sunbum 3y ago
It was half 1 year of their number.

deely3 3y ago

So, you should never use Google, Amazon, Apple, banking system API. What the alternative?

fwlr 3y ago
The rule isn’t “never use an API”. If you’re a search company you shouldn’t build your business on the Google search API, if you’re a compute provider you shouldn’t build your business on the AWS API, if you’re a payment provider you shouldn’t build your business on the Stripe API, etc. So the pedantic version of the rule is like, don’t build your business on just repackaging another company’s API, I guess?
- Dudester230602 3y ago
  If you are a game development company you shouldn't build your business on someone else's gaming API (aka game engine)?
  - callalex 3y ago
    That’s not quite equivalent, but there was a huge developer community upset when Unity switched to their freemium revenue sharing model.
  - fwlr 3y ago
    Probably, yeah. Game development is a bit of an exception to many “rules” of the software business, since creative and artistic expression are significant motivating factors substituting in for a portion of the usual profit motive, in a way you generally don’t see in other software (look for the phrase ‘labour of love’ for examples). Game engines are also not quite APIs imo, they are more like (massive) libraries that you vendor (bundle with your game and install as dependency). This inures you against some issues with building on a third party API, but not all (e.g. price changes are still an issue, but at a different granularity: “licensing fees per game” rather than “usage fees per call”). These minor caveats aside, your example is good and worth investigating. Off the top of my head, I believe big game development companies are indeed pretty diversified when it comes to game engines, reflecting the wisdom of not building on someone else’s API. Riot Games uses their own engine for League of Legends, but uses Unreal for Valorant and Unity for Runeterra and Wild Rift. Blizzard uses their own engine(s) for StarCraft/Warcraft/WoW/Overwatch/Diablo, but uses Unity for Hearthstone. They did license Unreal Engine at some point but I’m not sure if they have used it. Activision uses their own engine (IW) for all of their Call of Duty games. EA uses Unreal and Unity for a few games, but largely uses their own engine (Frostbite). Ubisoft used to use Unreal for their Tom Clancy series (e.g. Ghost Recon and Splinter Cell) but in fact moved that series to their own engines (Ghost Recon is now on Ubi’s Anvil engine while The Division is on their Snowdrop engine), specifically citing concerns over control and licensing fees as the reason for the move. Their Assassin’s Creed series has always been on their Anvil engine. I believe Ubisoft has another handful of their own engines as well, not quite “one engine per game series” but maybe close to that - an extreme example where they aren’t even willing to build one department’s business on another department’s API! Valve uses their own engine, Source, for their games. (They have worked with both Unity and Unreal, but I believe this was for their VR and console hardware?) Nintendo also uses their own engines for their games. (Like Valve, they have worked with both Unreal and Unity for their Switch handheld hardware.) Epic Games is the only big game developer I can think of that is not diversified, they use Unreal exclusively. Being as they are also the developers of Unreal engine, this isn’t a case of relying on a third party. So overall I would say yes, even in game development it’s clear that companies go to significant expense to not rely on someone else’s gaming API, and with Ubisoft there’s at least one example of a company publicly learning this exact lesson.

sodality2 3y ago

This is missing the context that the Reddit staff member immediately apologized for interpreting it as a threat several times, and spez still chose to regurgitate the same claim. https://gist.github.com/christianselig/fda7e8bc5a25aec9824f915e6a5c7014 https://gist.github.com/christianselig/fda7e8bc5a25aec9824f9...

deleted 3y ago
[deleted]
ChocMontePy 3y ago
I don't think that's a good argument. If someone says something sexually harassing to me at work and I politely say "Oh, I guess I misunderstood" to defuse the situation, it would be specious for them to later claim that my statement of misunderstanding means that no sexual harassment could have taken place.
- Niksko 3y ago
  The dev recorded things. You can hear it for yourself. To me it's pretty clear that he's saying 'my API is loud in terms of API calls, it would be quiet if it went away' not 'I will go away quietly if you pay me hush money'