3 ms·

Disagree. Code is leverage, and leveraging valuable property is a great passtime, and smart for people in tech. If one percent of SONOS owners use the code, a

Disagree. Code is leverage, and leveraging valuable property is a great passtime, and smart for people in tech. If one percent of SONOS owners use the code, and a fraction of one percent contribute to code, the sky is the limit for all present and future SONOS owners.

PragmaticPulp 6y ago
> If one percent of SONOS owners use the code I've worked at companies that added APIs for enthusiasts to use for home automation and other projects. I can tell you from experience that the number of customers who use those APIs is far less than 1%. The number of people who might actually compile code and run it on their device, if given the chance, is vanishingly small. The real problem, though, is that no matter how hard you try to tell your customers that customizations and custom integrations won't be supported, your customer support channels will be flooded with obscure requests from these customers. As soon as something goes wrong, they want you to fix it. It doesn't take long before they start taking to Amazon reviews to vent their frustrations. It doesn't matter how many warnings you add, how many times you insist that aftermarket modifications won't be supported, or how much you plead with the enthusiasts to take responsibility for their own modifications. A subset of the hackers will make things miserable for your support and RMA teams, and that's enough to sink these initiatives. Finally: Once you advertise an API or support for customer modifications, you're on the hook for supporting it forever. Need to re-architect the software for some new features or upcoming products? If it breaks compatibility with customer hacks or integrations then prepare for some of the most vile, angry feedback you've ever received. The hacker community has zero tolerance for losing features or access, so once it's out there you'd better be prepared to support if forever. This might not sound bad at first, but it doesn't take long until you're making choices between advancing the product line and not upsetting the <0.1% of vocal customers who use the APIs/integrations.
- seg_lol 6y ago
  I think numbers obscure the rational, what you have outlined is position that eventually puts us in a world where everything is glued shut and the only way in is via someone's walled garden. Most systems could use an RS-232 port and simple text protocol to do everything the keypad and the display screen could do. Many systems use SQLite for instance, at least expose a RO version of that database. There are lots of ways to expose access w/o having to support v0.0.1 of the API forever. But what you are advocating for is basically locking everyone out of your products so that the rest of the org is affected. Rather than view the wackos who file support requests on an API that only 1:50e3 customers use, find out why they need those extensions and cater to their needs. Often it is for a whole new market.
- jpetso 6y ago
  Breaking internal APIs is also what Linux does. Nvidia and other out-of-tree modules must have a rather hard time with adapting their code to an ever-changing kernel. Sure there are people who argue for stable APIs. It works for Linux though, and I think that's due to two reasons: 1. There is real value in breaking changes allowing the kernel to move faster. 2. People are not forcibly upgraded to a new kernel. They can do it at their own leisure, when their distro (with manual updates) or personal testing deems it working well enough. Sonos has recently had some bad publicity for trying to force breaking updates onto people, not in terms of APIs but in terms of actual basic functionality. Their recovery move was to allow people to keep their original functionality, but users accept as a trade-off that doing so will not be compatible with devices running the newer and better software. As far as I can see, this approach resonated much better with the public than the original forced one. I believe that embedded hackers will have much less of an issue with breakages if the trade-offs are clearly communicated and control over updates remains in users' hands, including a way to revert to a previous version if things go wrong. It doesn't have to be company vs. users necessarily. But yeah, whether it's worth in business terms to accommodate this exceedingly tiny and understandably demanding minority, that's a different question.

PragmaticPulp 6y ago

> If one percent of SONOS owners use the code I've worked at companies that added APIs for enthusiasts to use for home automation and other projects. I can tell you from experience that the number of customers who use those APIs is far less than 1%. The number of people who might actually compile code and run it on their device, if given the chance, is vanishingly small. The real problem, though, is that no matter how hard you try to tell your customers that customizations and custom integrations won't be supported, your customer support channels will be flooded with obscure requests from these customers. As soon as something goes wrong, they want you to fix it. It doesn't take long before they start taking to Amazon reviews to vent their frustrations. It doesn't matter how many warnings you add, how many times you insist that aftermarket modifications won't be supported, or how much you plead with the enthusiasts to take responsibility for their own modifications. A subset of the hackers will make things miserable for your support and RMA teams, and that's enough to sink these initiatives. Finally: Once you advertise an API or support for customer modifications, you're on the hook for supporting it forever. Need to re-architect the software for some new features or upcoming products? If it breaks compatibility with customer hacks or integrations then prepare for some of the most vile, angry feedback you've ever received. The hacker community has zero tolerance for losing features or access, so once it's out there you'd better be prepared to support if forever. This might not sound bad at first, but it doesn't take long until you're making choices between advancing the product line and not upsetting the <0.1% of vocal customers who use the APIs/integrations.

seg_lol 6y ago
I think numbers obscure the rational, what you have outlined is position that eventually puts us in a world where everything is glued shut and the only way in is via someone's walled garden. Most systems could use an RS-232 port and simple text protocol to do everything the keypad and the display screen could do. Many systems use SQLite for instance, at least expose a RO version of that database. There are lots of ways to expose access w/o having to support v0.0.1 of the API forever. But what you are advocating for is basically locking everyone out of your products so that the rest of the org is affected. Rather than view the wackos who file support requests on an API that only 1:50e3 customers use, find out why they need those extensions and cater to their needs. Often it is for a whole new market.
jpetso 6y ago
Breaking internal APIs is also what Linux does. Nvidia and other out-of-tree modules must have a rather hard time with adapting their code to an ever-changing kernel. Sure there are people who argue for stable APIs. It works for Linux though, and I think that's due to two reasons: 1. There is real value in breaking changes allowing the kernel to move faster. 2. People are not forcibly upgraded to a new kernel. They can do it at their own leisure, when their distro (with manual updates) or personal testing deems it working well enough. Sonos has recently had some bad publicity for trying to force breaking updates onto people, not in terms of APIs but in terms of actual basic functionality. Their recovery move was to allow people to keep their original functionality, but users accept as a trade-off that doing so will not be compatible with devices running the newer and better software. As far as I can see, this approach resonated much better with the public than the original forced one. I believe that embedded hackers will have much less of an issue with breakages if the trade-offs are clearly communicated and control over updates remains in users' hands, including a way to revert to a previous version if things go wrong. It doesn't have to be company vs. users necessarily. But yeah, whether it's worth in business terms to accommodate this exceedingly tiny and understandably demanding minority, that's a different question.