5 ms·

If they were to give me access to the Linux system running on my Sonos devices, I'd be rather more inclined to buy the idea that Sonos is a supporter of open so

by corbet 6y ago

If they were to give me access to the Linux system running on my Sonos devices, I'd be rather more inclined to buy the idea that Sonos is a supporter of open source. There are many things in need of fixing there, and their customers would be most inclined to help, but no such luck.

mav3rick 6y ago
No customers want to write code for the devices they buy. They just want them to work. HN is such a bubble
- detaro 6y ago
  What's the point of a comment like this? Do you really think parent doesn't know that this is a niche interest? Custom integrations etc basically always are only done by a very small number of people, used by a lot larger (but typically still small number), that doesn't make them worthless. There's even an obvious example in the same niche, see the ecosystem around what was the Logitech squeezebox.
- stblack 6y ago
  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.
- threeqhan 6y ago
  Customers haven't been given the choice
- saagarjha 6y ago
  Hacker News users are customers.
- hsbauauvhabzb 6y ago
  I, for one, would probably-rage build hacky stream integration with my Linux desktop if source was available.
- breakfastduck 6y ago
  Missing the point completely. Yes, I agree, most people just want them to work. But there will be a much smaller number of super technical users who want to pitch in and fix issues or be allowed to develop their own solutions. Giving those people access is only a benefit to everyone, it doesn't detriment the average users.
  - PragmaticPulp 6y ago
    > Giving those people access is only a benefit to everyone From past experience at hardware companies that tried engaging enthusiasts and open source communities, I can tell you that these features benefit <0.1% of the customer base but come at a huge expense to developer productivity. Once you start down the path of releasing and supporting things publicly, it's a totally different ballgame than simply handling changes and releases internally.
- cbsks 6y ago
  Counter point: The Linksys WRT54GL wireless router was incredibly popular, in part because 3rd party firmware could be loaded to it https://en.m.wikipedia.org/wiki/Linksys_WRT54G_series https://en.m.wikipedia.org/wiki/Linksys_WRT54G_series
  - mav3rick 6y ago
    Correlation is not causation. You have no data to back this assertion.
    - detaro 6y ago
      Linksys gave it as a reason for why they still made lots of money with it and thus continued production after they released cheaper and faster followup models.
    - cbsks 6y ago
      The first bullet point on the Amazon listing for the WRT54GL is “Linux-based, open-source firmware allows you to customize your device”. The original WRT54G supported loading third party firmware, until Linksys removed that ability in V5 by switching from Linux to VxWorks. After the backlash, Linksys released the WRT54GL which was able to use third party firmware again. https://www.smallnetbuilder.com/wireless/wireless-reviews/26843-linksyswrt54gv5reallyisalousyrouter https://www.smallnetbuilder.com/wireless/wireless-reviews/26... Anecdotally, the only reason I bought a WRT54GL was because I could run DR-WRT on it.
- tclancy 6y ago
  Intriguing that you’re inside it. Or that it exists at all.
  - tclancy 6y ago
    If I need some boba fides, I was part of a company that wrote code for Sonos about 15 years ago, so somebody has to do it.
- gpm 6y ago
  I mean, they mostly want to run code third parties wrote not themselves and not just what the manufacturer decided to write. As you see in the router example someone game. As you see in the giant example of android/ios ("There's an app for that"). Even when there isn't an appstore like with desktop operating systems. Even when it's a pain in the ass to install third party apps like remarkable tablets. Even when the "thing" isn't hardware but a base layer of software like minecraft. In fact, I can't think of a single example of a device that was popular, made it legal and not overly difficult to write and distribute third party code, and didn't have a thriving ecosystem.

by corbet 6y ago

mav3rick 6y ago

No customers want to write code for the devices they buy. They just want them to work. HN is such a bubble

detaro 6y ago
What's the point of a comment like this? Do you really think parent doesn't know that this is a niche interest? Custom integrations etc basically always are only done by a very small number of people, used by a lot larger (but typically still small number), that doesn't make them worthless. There's even an obvious example in the same niche, see the ecosystem around what was the Logitech squeezebox.
stblack 6y ago
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.
threeqhan 6y ago
Customers haven't been given the choice
saagarjha 6y ago
Hacker News users are customers.
hsbauauvhabzb 6y ago
I, for one, would probably-rage build hacky stream integration with my Linux desktop if source was available.
breakfastduck 6y ago
Missing the point completely. Yes, I agree, most people just want them to work. But there will be a much smaller number of super technical users who want to pitch in and fix issues or be allowed to develop their own solutions. Giving those people access is only a benefit to everyone, it doesn't detriment the average users.
- PragmaticPulp 6y ago
  > Giving those people access is only a benefit to everyone From past experience at hardware companies that tried engaging enthusiasts and open source communities, I can tell you that these features benefit <0.1% of the customer base but come at a huge expense to developer productivity. Once you start down the path of releasing and supporting things publicly, it's a totally different ballgame than simply handling changes and releases internally.
cbsks 6y ago
Counter point: The Linksys WRT54GL wireless router was incredibly popular, in part because 3rd party firmware could be loaded to it https://en.m.wikipedia.org/wiki/Linksys_WRT54G_series https://en.m.wikipedia.org/wiki/Linksys_WRT54G_series
- mav3rick 6y ago
  Correlation is not causation. You have no data to back this assertion.
  - detaro 6y ago
    Linksys gave it as a reason for why they still made lots of money with it and thus continued production after they released cheaper and faster followup models.
  - cbsks 6y ago
    The first bullet point on the Amazon listing for the WRT54GL is “Linux-based, open-source firmware allows you to customize your device”. The original WRT54G supported loading third party firmware, until Linksys removed that ability in V5 by switching from Linux to VxWorks. After the backlash, Linksys released the WRT54GL which was able to use third party firmware again. https://www.smallnetbuilder.com/wireless/wireless-reviews/26843-linksyswrt54gv5reallyisalousyrouter https://www.smallnetbuilder.com/wireless/wireless-reviews/26... Anecdotally, the only reason I bought a WRT54GL was because I could run DR-WRT on it.
tclancy 6y ago
Intriguing that you’re inside it. Or that it exists at all.
- tclancy 6y ago
  If I need some boba fides, I was part of a company that wrote code for Sonos about 15 years ago, so somebody has to do it.
gpm 6y ago
I mean, they mostly want to run code third parties wrote not themselves and not just what the manufacturer decided to write. As you see in the router example someone game. As you see in the giant example of android/ios ("There's an app for that"). Even when there isn't an appstore like with desktop operating systems. Even when it's a pain in the ass to install third party apps like remarkable tablets. Even when the "thing" isn't hardware but a base layer of software like minecraft. In fact, I can't think of a single example of a device that was popular, made it legal and not overly difficult to write and distribute third party code, and didn't have a thriving ecosystem.