6 ms·

I agree. We ran into this issue all of the time at a past employer with a lot of tech enthusiasts in the customer base: We’d make harmless changes to our own co

I agree. We ran into this issue all of the time at a past employer with a lot of tech enthusiasts in the customer base: We’d make harmless changes to our own code that broke someone’s community software that relied on undocumented APIs from time to time. Without fail, someone from the community would jump to conclusions and start stirring up controversy with claims that we were deliberately breaking 3rd-party applications. The strange thing was that people from all over the internet wanted to get in on the controversy and anger, even when they didn’t use the software that broke. This created a weird incentive for software authors to complain loud and wide about any breaking changes because it became free advertising for their software. We tried quietly helping some of them fix their software with hints, but that quickly became an avenue for “<company> caves to pressure from angry customers” stories that only made our problem worse.

ssivark 5y ago
Fascinating. I’m curious what were the landscape of MOs you/company evaluated. Eg: would it have been possible to encourage a slightly more organized relationship with the enthusiasts by communicating the challenges to them?
- PragmaticPulp 5y ago
  It’s tough. I engaged with the community a lot at first and we made efforts to give them what they wanted. Over time this created a weird, unhealthy dynamic where parts of the community felt entitled to special treatment from the company. Some of them felt like they were stakeholders in the company and that we were obligated to incorporate them into the development process. At worst, it reminded me of some of the “parasocial” relationships described in social media situations, where the followers start to feel like they were owed much more than regular customers due to their dedication as super customers. Even worse, some of them had their own YouTube channels, newsletters, or Discord communities for our products and would often threaten to turn them against us if we didn’t do what they wanted. That part was especially saddening.
  - ssivark 5y ago
    Hmmm, that’s interesting in an unfortunate way that can only be learned from experience. I have wondered about why companies don’t better engage with enthusiasts / power users, and now I have a better appreciation for the challenges. Thanks for sharing.
semi-extrinsic 5y ago
https://xkcd.com/1172/ https://xkcd.com/1172/
- vertis 5y ago
  We could save everyone a lot of time commenting on HN just by auto categorizing by XKCD.
devwastaken 5y ago
That's the problem, the company didn't publicly engage with their users that needed it. A simple intent to ship with a list of changes related to API's is a great start. The employees should be using the most popular of the user made software. That's how organic communities function. The problems occur when company thinks theyre God and their software is controllable - it's not. People are going to use it as they see fit, and if you don't Shepard it that community will find their owns reasons for why the company ignores it.
- wdb 5y ago
  There is typically a reason when APIs are not documented. There are no guarantees given it will keep working etc
  - devwastaken 5y ago
    Many times undocumented API's become a lot more permanent and 3rd party documented. If you don't do it, other people will, it's better to handle that problem from the company itself and put bit fat "can break any time" stickers on it.
- parineum 5y ago
  >A simple intent to ship with a list of changes related to API's is a great start. So the controversy can start sooner? >The problems occur when company thinks theyre God and their software is controllable - it's not. This isn't some github project. This is proprietary software owned by Netflix. This isn't "the community" getting upset, this is a small group of people using closed source software in a way that wasn't intended. Most people using Netflix just use it the way Netflix wants them to.
  - devwastaken 5y ago
    You would be apart of the problem, not the solution. Attitudes like that are exactly how that happens.
    - 5y ago
bob1029 5y ago
> that only made our problem worse. This is the part of PR that I fail to grasp. At a certain point, couldn't you just post "fuck you" on twitter and disregard the noisy mess? Would 100% of everyones' customer base actually walk away from them if they don't play "the game" on social media just right?
- fighterpilot 5y ago
  What I'd be afraid of is fake review brigading causing lasting damage to brand.
- toast0 5y ago
  Been there. Basically, ignoring twitter and press pretty much works. If you have a working customer service mechanism, you need to be ready to respond there with a brief note of something like 'this use is not supported by us, bye', and once you have that note, you might consider responding to press with that. You might want to engage with 3rd party developers, but it's clear that it would quickly become much more work than supporting in-house clients. When the server team unintentionally breaks an in-house client, they don't start a big distracting PR war about it; and when an in-house client unintentionally breaks the server, there's leverage to fix the client (or the server) and insight into how the fixed client deployment is going. It can also be difficult to fix sensitive or just complex issues in a coordinated way when there's unequal access as happens with in-house and 3rd party development. Being non-transparent is easier; although certainly less desirable to many. If you have a compelling product, people often don't follow through on their plans to drop it.
ferdowsi 5y ago
At a previous company we had someone angrily call in with a bug. We had moved a button several pixels and this broke some automation they had built which relied on the pixel coordinates of the button. It was exactly as dumb as it sounded. So I don't see much reason for Netflix have a deprecation cycle for undocumented functionality that a third party extension relies on. If you want to rely on internals, don't be surprised when they change.
- spaceribs 5y ago
  I'm specifically trying to avoid a bad integration though, the API for <video> is quite clear for how to interact with a <video> element hosted on a page, as defined by the HTML5 spec. This is the issue I have with this change, I'm following all the rules here and those rules apply to every video provider on the web for rendering video. While I don't think it was purposeful, it certainly needs to be called out that crashing the entire page is certainly nonstandard behavior for a <video> element.
  - bredren 5y ago
    Fwiw, you can’t even trust the browsers to handle HTML5 media spec behavior the same way. I just dealt with cross-browser issues in how setting currentTime on <audio> is handled because I needed a player to resume from a preset time. On WebKit browsers, including desktop safari and all iOS browsers, you must wait for the ‘dataloadded’ or ‘canplay’ events to fire before trying to set currentTime. On desktop Firefox / Chrome, you must set currentTime immediately prior to .play() or it won’t pick it up.
    - deleted 5y ago
      [deleted]
- syshum 5y ago
  At my company humans will complain if you move a button because most people operate on their own muscle memory, any time Microsoft, or some other software vendors moves a button, no matter how small, we get ends less complains, automation is not needed. For automation, this is likely because you company did not provide proper official API do to proper automation. Many companies do not, nexflix does not. So people have to hack around internals to make the things do what they want. I am still at a loose why companies, and devs are such control freaks they only want people to use their software / hardware in the exact way they want them do, offering no other control options, automation API;s or any other "power" features". It is their way or the highway... and screw you if you do not like it
azinman2 5y ago
You’re touching on a wider huge problem for society now: people make assumptions that ascribe malice when there is none (and/or vastly misunderstand something), and the internet lets this amplify and morph into bigger issues than should exist. When social networking was nascent, there was this assumption that decentralized voices would help get truth out faster than could ever happen, and the principals of democracy would flourish. While that sometimes happens, it seems more often than not public opinion falls victim to conspiracy theories aided by cognitive biases (especially confirmation bias) and those who purposefully wish to distort. What’s saddest to me is that I’ve come to the conclusion that the genie cannot be put back in the bottle. We cannot expect that technology will go backwards, and the only viable option is the China one of absolute information control, which itself is scary. Those who do not adopt this will be vulnerable to outside control and inside dark forces, and those who do will create a censorship authoritarian state.
- AnthonyMouse 5y ago
  > We cannot expect that technology will go backwards, and the only viable option is the China one of absolute information control, which itself is scary. There is an obviously better alternative, which is non-centralized moderation. This is HN. It's moderated. It's not moderated by a government or Mark Zuckerberg and it has no monopoly on the dissemination of information, so if you don't like the moderation here you can go somewhere else and there are in actual fact other places to go. That works. The real problem right now is that the biggest platforms are too big/centralized, which means you get chokepoints that attract hamfisted bureaucratic censorship instead of vigorous competition for high quality moderation.
  - azinman2 5y ago
    Except it doesn’t. It falls victim to all the same things. I’ve seen things posted with all kinds of conspiracy theories that I happen to have intimate knowledge of from where I’ve worked, and those theories are dead wrong. They’re a combination of not knowing about public information, not being able to understand it (outside of skill set), not bothering to do research before stating opinions and amplifying (upvoting) things that sound right but are in fact not, incorrectly connecting dots that are unrelated, bringing in false “facts”, stating opinions as facts that others assume are then facts, and a host of other issues. If all you’re depending on is others to upvote and downvote, then you information bubbles are easy to form. Facebook is notoriously bad for exactly this reason, as are forums that attract certain demographics / ideologies.
SahAssar 5y ago
I tag those commits with "spacebar heating": https://xkcd.com/1172/ https://xkcd.com/1172/
AnthonyMouse 5y ago
The cause of the problem here is generally that you didn't provide (or adequately document) a reasonable API to do that thing. If you did, and the third party was fishing through your internals to do it instead, they're the assholes. That's generally more work than reading API documentation so if the API exists people are likely to use it, which should make this rare. But if fishing through your internals was the only way to do it, maybe change that if your goal is to not hear from so many angry people after you move things around. Expect people to use the undocumented unstable interface if the documented stable interface doesn't exist or doesn't work.
- phist_mcgee 5y ago
  But how do you do that with the web? If someone is digging into the actual source of the site, that's on them. But that doesn't mean our team has time to provide and support an API for 3rd parties.
  - AnthonyMouse 5y ago
    There is nothing actually preventing a web page from having a documented API. Many of them do.
- bastawhiz 5y ago
  Especially if the service is free, it's not reasonable for companies to bend over backwards to build, support, and maintain an API. One can expect users to build on undocumented and unstable interfaces, but they shouldn't expect the care one might receive if they had a contract to support that functionality.
  - AnthonyMouse 5y ago
    It's not about that. If you make a service with popular third party extensions and then you make a change that breaks those popular third party extensions, the users are gonna be mad. At you. The obvious way to reduce the likelihood of that is to publish an API for the third parties to use that won't break. You can say you have no obligation to provide that, and that's fine, but then it's going to break and the users are gonna be mad. At you.

ssivark 5y ago

Fascinating. I’m curious what were the landscape of MOs you/company evaluated. Eg: would it have been possible to encourage a slightly more organized relationship with the enthusiasts by communicating the challenges to them?

PragmaticPulp 5y ago
It’s tough. I engaged with the community a lot at first and we made efforts to give them what they wanted. Over time this created a weird, unhealthy dynamic where parts of the community felt entitled to special treatment from the company. Some of them felt like they were stakeholders in the company and that we were obligated to incorporate them into the development process. At worst, it reminded me of some of the “parasocial” relationships described in social media situations, where the followers start to feel like they were owed much more than regular customers due to their dedication as super customers. Even worse, some of them had their own YouTube channels, newsletters, or Discord communities for our products and would often threaten to turn them against us if we didn’t do what they wanted. That part was especially saddening.
- ssivark 5y ago
  Hmmm, that’s interesting in an unfortunate way that can only be learned from experience. I have wondered about why companies don’t better engage with enthusiasts / power users, and now I have a better appreciation for the challenges. Thanks for sharing.

semi-extrinsic 5y ago

https://xkcd.com/1172/ https://xkcd.com/1172/

vertis 5y ago
We could save everyone a lot of time commenting on HN just by auto categorizing by XKCD.

devwastaken 5y ago

That's the problem, the company didn't publicly engage with their users that needed it. A simple intent to ship with a list of changes related to API's is a great start. The employees should be using the most popular of the user made software. That's how organic communities function. The problems occur when company thinks theyre God and their software is controllable - it's not. People are going to use it as they see fit, and if you don't Shepard it that community will find their owns reasons for why the company ignores it.

wdb 5y ago
There is typically a reason when APIs are not documented. There are no guarantees given it will keep working etc
- devwastaken 5y ago
  Many times undocumented API's become a lot more permanent and 3rd party documented. If you don't do it, other people will, it's better to handle that problem from the company itself and put bit fat "can break any time" stickers on it.
parineum 5y ago
>A simple intent to ship with a list of changes related to API's is a great start. So the controversy can start sooner? >The problems occur when company thinks theyre God and their software is controllable - it's not. This isn't some github project. This is proprietary software owned by Netflix. This isn't "the community" getting upset, this is a small group of people using closed source software in a way that wasn't intended. Most people using Netflix just use it the way Netflix wants them to.
- devwastaken 5y ago
  You would be apart of the problem, not the solution. Attitudes like that are exactly how that happens.
  - 5y ago

bob1029 5y ago

> that only made our problem worse. This is the part of PR that I fail to grasp. At a certain point, couldn't you just post "fuck you" on twitter and disregard the noisy mess? Would 100% of everyones' customer base actually walk away from them if they don't play "the game" on social media just right?

fighterpilot 5y ago
What I'd be afraid of is fake review brigading causing lasting damage to brand.
toast0 5y ago
Been there. Basically, ignoring twitter and press pretty much works. If you have a working customer service mechanism, you need to be ready to respond there with a brief note of something like 'this use is not supported by us, bye', and once you have that note, you might consider responding to press with that. You might want to engage with 3rd party developers, but it's clear that it would quickly become much more work than supporting in-house clients. When the server team unintentionally breaks an in-house client, they don't start a big distracting PR war about it; and when an in-house client unintentionally breaks the server, there's leverage to fix the client (or the server) and insight into how the fixed client deployment is going. It can also be difficult to fix sensitive or just complex issues in a coordinated way when there's unequal access as happens with in-house and 3rd party development. Being non-transparent is easier; although certainly less desirable to many. If you have a compelling product, people often don't follow through on their plans to drop it.

ferdowsi 5y ago

At a previous company we had someone angrily call in with a bug. We had moved a button several pixels and this broke some automation they had built which relied on the pixel coordinates of the button. It was exactly as dumb as it sounded. So I don't see much reason for Netflix have a deprecation cycle for undocumented functionality that a third party extension relies on. If you want to rely on internals, don't be surprised when they change.

spaceribs 5y ago
I'm specifically trying to avoid a bad integration though, the API for <video> is quite clear for how to interact with a <video> element hosted on a page, as defined by the HTML5 spec. This is the issue I have with this change, I'm following all the rules here and those rules apply to every video provider on the web for rendering video. While I don't think it was purposeful, it certainly needs to be called out that crashing the entire page is certainly nonstandard behavior for a <video> element.
- bredren 5y ago
  Fwiw, you can’t even trust the browsers to handle HTML5 media spec behavior the same way. I just dealt with cross-browser issues in how setting currentTime on <audio> is handled because I needed a player to resume from a preset time. On WebKit browsers, including desktop safari and all iOS browsers, you must wait for the ‘dataloadded’ or ‘canplay’ events to fire before trying to set currentTime. On desktop Firefox / Chrome, you must set currentTime immediately prior to .play() or it won’t pick it up.
  - deleted 5y ago
    [deleted]
syshum 5y ago
At my company humans will complain if you move a button because most people operate on their own muscle memory, any time Microsoft, or some other software vendors moves a button, no matter how small, we get ends less complains, automation is not needed. For automation, this is likely because you company did not provide proper official API do to proper automation. Many companies do not, nexflix does not. So people have to hack around internals to make the things do what they want. I am still at a loose why companies, and devs are such control freaks they only want people to use their software / hardware in the exact way they want them do, offering no other control options, automation API;s or any other "power" features". It is their way or the highway... and screw you if you do not like it

azinman2 5y ago

You’re touching on a wider huge problem for society now: people make assumptions that ascribe malice when there is none (and/or vastly misunderstand something), and the internet lets this amplify and morph into bigger issues than should exist. When social networking was nascent, there was this assumption that decentralized voices would help get truth out faster than could ever happen, and the principals of democracy would flourish. While that sometimes happens, it seems more often than not public opinion falls victim to conspiracy theories aided by cognitive biases (especially confirmation bias) and those who purposefully wish to distort. What’s saddest to me is that I’ve come to the conclusion that the genie cannot be put back in the bottle. We cannot expect that technology will go backwards, and the only viable option is the China one of absolute information control, which itself is scary. Those who do not adopt this will be vulnerable to outside control and inside dark forces, and those who do will create a censorship authoritarian state.

AnthonyMouse 5y ago
> We cannot expect that technology will go backwards, and the only viable option is the China one of absolute information control, which itself is scary. There is an obviously better alternative, which is non-centralized moderation. This is HN. It's moderated. It's not moderated by a government or Mark Zuckerberg and it has no monopoly on the dissemination of information, so if you don't like the moderation here you can go somewhere else and there are in actual fact other places to go. That works. The real problem right now is that the biggest platforms are too big/centralized, which means you get chokepoints that attract hamfisted bureaucratic censorship instead of vigorous competition for high quality moderation.
- azinman2 5y ago
  Except it doesn’t. It falls victim to all the same things. I’ve seen things posted with all kinds of conspiracy theories that I happen to have intimate knowledge of from where I’ve worked, and those theories are dead wrong. They’re a combination of not knowing about public information, not being able to understand it (outside of skill set), not bothering to do research before stating opinions and amplifying (upvoting) things that sound right but are in fact not, incorrectly connecting dots that are unrelated, bringing in false “facts”, stating opinions as facts that others assume are then facts, and a host of other issues. If all you’re depending on is others to upvote and downvote, then you information bubbles are easy to form. Facebook is notoriously bad for exactly this reason, as are forums that attract certain demographics / ideologies.

SahAssar 5y ago

I tag those commits with "spacebar heating": https://xkcd.com/1172/ https://xkcd.com/1172/

AnthonyMouse 5y ago

The cause of the problem here is generally that you didn't provide (or adequately document) a reasonable API to do that thing. If you did, and the third party was fishing through your internals to do it instead, they're the assholes. That's generally more work than reading API documentation so if the API exists people are likely to use it, which should make this rare. But if fishing through your internals was the only way to do it, maybe change that if your goal is to not hear from so many angry people after you move things around. Expect people to use the undocumented unstable interface if the documented stable interface doesn't exist or doesn't work.

phist_mcgee 5y ago
But how do you do that with the web? If someone is digging into the actual source of the site, that's on them. But that doesn't mean our team has time to provide and support an API for 3rd parties.
- AnthonyMouse 5y ago
  There is nothing actually preventing a web page from having a documented API. Many of them do.
bastawhiz 5y ago
Especially if the service is free, it's not reasonable for companies to bend over backwards to build, support, and maintain an API. One can expect users to build on undocumented and unstable interfaces, but they shouldn't expect the care one might receive if they had a contract to support that functionality.
- AnthonyMouse 5y ago
  It's not about that. If you make a service with popular third party extensions and then you make a change that breaks those popular third party extensions, the users are gonna be mad. At you. The obvious way to reduce the likelihood of that is to publish an API for the third parties to use that won't break. You can say you have no obligation to provide that, and that's fine, but then it's going to break and the users are gonna be mad. At you.