Skip to main content

I wasn’t one of the customers who complained about Sonos’ earlier communication this week. However, I initially had the same reaction as many others who wrote in anger or disappointment in this customer community. 

I commend Patrick Spence for his quick reaction, for correcting course, and for the tone of his letter to customers today. I completely understand Sonos’ internal drivers to urge their customers to upgrade their systems. However, as Patrick well said, customer experience and their loyalty is paramount and trumps anything else.

I plan to remain as a loyal Sonos customer and will continue to expand and upgrade my home sound system when it makes sense to do so.

I think people are a lot more surprised than they ought to be, this strikes me as being a fairly predictable issue with any ‘connected’ devices in modern times.

 

Personally, I was more surprised by the short lead time, not the announcement itself. An EOL notice with 4 months warning is not very customer friendly, especially when it’s attached to a $2000 bill.

If it was a year, that’d be different for me. I can come up with a reasonable and affordable plan for updating my system (or replacing it) in a year. I can’t do that in 4 months.


 

Personally, I was more surprised by the short lead time, not the announcement itself. An EOL notice with 4 months warning is not very customer friendly, especially when it’s attached to a $2000 bill.

If it was a year, that’d be different for me. I can come up with a reasonable and affordable plan for updating my system (or replacing it) in a year. I can’t do that in 4 months.

 

Then you should run on legacy mode for that year, and upgrade as you get the funds. 


 

Then you should run on legacy mode for that year, and upgrade as you get the funds. 


Well, obviously. That doesn’t mean 4 months lead time is customer-friendly.

On the upside, they are committing to bug fixes and security patches. That does make this less of an issue than it was when the first announcement came out.

Ideally, though? I’d like a service mix, so that old and new can co-exist with new doing its new things, and old supporting old things, and the two capable of grouping together. That isn’t what they are committing to. Which implies that if I buy new things, my new things will only run the old things. Will that be a problem? I don’t know--I can’t predict the future. But given that the post-4 months period is not coming with any guarantees beyond bug fixes, it’s still pretty crappy service.

Defend it all you want, but there is clearly a disconnect between Sonos and its oldest customers. If there wasn’t, we wouldn’t be seeing this much commotion.

 


I think people are a lot more surprised than they ought to be, this strikes me as being a fairly predictable issue with any ‘connected’ devices in modern times.

 

 An EOL notice with 4 months warning is not very customer friendly,

 

This is not an EOL 

 


 

This is not an EOL 

 

You’re being pedantic. They no longer get new features, and they only get emergency fixes. Oh, and keeping them around drags your whole zone down to the lowest common denominator. Close enough.


I think WIkipedia has a pretty good definition of EOL:

"End-of-life" (EOL) is a term used with respect to a product supplied to customers, indicating that the product is in the end of its useful life (from the vendor's point of view), and a vendor stops marketing, selling, or rework sustaining it. (The vendor may simply intend to limit or end support for the product.)

 

Seems to fit here.


 

Then you should run on legacy mode for that year, and upgrade as you get the funds. 


Well, obviously. That doesn’t mean 4 months lead time is customer-friendly.

On the upside, they are committing to bug fixes and security patches. That does make this less of an issue than it was when the first announcement came out.

Ideally, though? I’d like a service mix, so that old and new can co-exist with new doing its new things, and old supporting old things, and the two capable of grouping together. That isn’t what they are committing to. Which implies that if I buy new things, my new things will only run the old things. Will that be a problem? I don’t know--I can’t predict the future. But given that the post-4 months period is not coming with any guarantees beyond bug fixes, it’s still pretty crappy service.

Defend it all you want, but there is clearly a disconnect between Sonos and its oldest customers. If there wasn’t, we wouldn’t be seeing this much commotion.

 

 

Not defending their PR nightmare, disconnect, or lack of communication, or anything else, except from software standpoint.  Many of us who know software engineering looked at the hardware and predicted this years ago.  Quite frankly I’m surprised they got blood out of the well wringed stone for this long.


Not defending their PR nightmare, disconnect, or lack of communication, or anything else, except from software standpoint.  Many of us who know software engineering looked at the hardware and predicted this years ago.  Quite frankly I’m surprised they got blood out of the well wringed stone for this long.

Do you know whether the ZP80 and ZP100 have the same memory/storage/CPU as the ZP90 and ZP120 that succeeded them? One of the things that surprised me was that it wasn't just the original hardware that is included in the legacy list.

I was also caught out by buying used Connects that appeared identical to the Connects that were still being sold by Sonos until recently.


Do you know whether the ZP80 and ZP100 have the same memory/storage/CPU as the ZP90 and ZP120 that succeeded them? One of the things that surprised me was that it wasn't just the original hardware that is included in the legacy list.

I was also caught out by buying used Connects that appeared identical to the Connects that were still being sold by Sonos until recently.

 

Every model given legacy status has the same RAM and SD storage (not sure about CPU).  I imagine that was the deciding factor.  It appears they just couldn’t fit the application and data in 32 MB anymore.  

Plus look at things like SMB v1.  The old kernel from 2005 didn’t even know what it was, and there was no way you are going to fit a modern kernel, plus the application, plus the data in 32 MB.  Which is one reason they couldn’t go to v2.  There’s probably a hundred other things also.  

As to the “one of these Connects is not like the others” thing, they admitted they were caught with that, which is why they have used the generation designations on newer units.


Oh and one more difference between legacy and modern, all legacy models pre-date the 5 GHz standard, all modern devices have 5 GHz capability.  What the significance of that is, or if it is significant at all, I don’t know.


Oh and one more difference between legacy and modern, all legacy models pre-date the 5 GHz standard, all modern devices have 5 GHz capability.  What the significance of that is, or if it is significant at all, I don’t know.

Interesting. I have a non-legacy Connect:Amp. I thought it lacked a 5GHz radio because it can’t be used wirelessly to drive surrounds.


Oh and one more difference between legacy and modern, all legacy models pre-date the 5 GHz standard, all modern devices have 5 GHz capability.  What the significance of that is, or if it is significant at all, I don’t know.

Interesting. I have a non-legacy Connect:Amp. I thought it lacked a 5GHz radio because it can’t be used wirelessly to drive surrounds.

 

Whoops. Forgot about those.  Amend that to say “speaker models”. That’s what I get for overthinking, LOL.  :persevere:


What about a low cost bridge type device they could sell or give away at cost that connects to the legacy speaker via the ethernet port and then that becomes its new modern brain?

 

Or:

- legacy only ecosystem - carry on as before

- modern only ecosystem - carry on with updates

- legacy and modern coexist - a modern device always becomes the master and the legacy always a slave? Create a light weight firmware for the legacy that strips out all the master bloat stuff as it will never be needed and create some “space” to keep it going a bit longer.

if the legacy gets sold or added to a legacy only system it just need to get its old legacy firmware back!

caveat to this mode is it always needs a modern device online...


What about a low cost bridge type device they could sell or give away at cost that connects to the legacy speaker via the ethernet port and then that becomes its new modern brain?

 

Or:

- legacy only ecosystem - carry on as before

- modern only ecosystem - carry on with updates

- legacy and modern coexist, a modern device always becomes the master and the legacy always a slave? Create a light weight firmware for the legacy that strips out all the master bloat stuff as it will never be needed and create some “space” to keep it going a bit longer.

if the legacy gets sold or added to a legacy only system it just need to get its old legacy firmware back!

 

Already discussed.  In short, it won’t be low cost.  The Bridge is low cost because it is just a network device with a WiFi card. No different than an access point, but with some mesh logic.  

Sonos players stream using a proprietary timing/syncing/communication protocol, and that is subject to change (which is why a legacy system won’t always be compatible with up to date systems).  In short, each unit must speak the same language or nothing gets played, nothing gets grouped, nothing is synced, etc. 

The “Bridge” you speak of would have to process the streams and control protocol, translating up to 32 simultaneous streams from legacy to modern or modern to legacy, which requires far more processing.  Those processing requirements would probably price it out of the reach of a sensible resolution.  There is also the issue of this additional processing causing timing errors and loss of sync. 

That’s just a couple of things off the top of my head.   


What about a low cost bridge type device they could sell or give away at cost that connects to the legacy speaker via the ethernet port and then that becomes its new modern brain?

 

Or:

- legacy only ecosystem - carry on as before

- modern only ecosystem - carry on with updates

- legacy and modern coexist, a modern device always becomes the master and the legacy always a slave? Create a light weight firmware for the legacy that strips out all the master bloat stuff as it will never be needed and create some “space” to keep it going a bit longer.

if the legacy gets sold or added to a legacy only system it just need to get its old legacy firmware back!

 

Already discussed.  In short, it won’t be low cost.  The Bridge is low cost because it is just a network device with a WiFi card. No different than an access point, but with some mesh logic.  

Sonos players stream using a proprietary timing/syncing/communication protocol, and that is subject to change (which is why a legacy system won’t always be compatible with up to date systems).  In short, each unit must speak the same language or nothing gets played, nothing gets grouped, etc. 

The “Bridge” you speak of would have to process the streams and control protocol, translating up to 32 simultaneous streams from legacy to modern or modern to legacy, which requires far more processing.  Those processing requirements would probably price it out of the reach of a sensible resolution.  There is also the issue of this additional processing causing timing errors and causing loss of sync. 

That’s just a couple of things off the top of my head.   

Thanks. So what your saying is that they probably have actually explored and exhausted all avenues and they didn’t really have a choice? At the end of the day the equipment is old and reached its limit. Guess they knew this was coming for a long time and dreaded the day they had to announce it. But they should have given more than 4 months notice.

 

Also May is a strange month to chose considering I bought my Play 5 Gen 1 from Sonos direct in August 2015 so you would expect their 5 year support would be August 2020?

 


Thanks. So what your saying is that they probably have actually explored and exhausted all avenues and they didn’t really have a choice?

Personally, I disagree with this, although I know that opinions differ.

I think it’s more accurately described as: technical solutions are feasible to allow legacy and modern products to continue to interoperate, but Sonos decided that the (non-trivial) R&D investments required to implement them are not where they should be spending their R&D money.


Thanks. So what your saying is that they probably have actually explored and exhausted all avenues and they didn’t really have a choice? At the end of the day the equipment is old and reached its limit. Guess they knew this was coming for a long time and dreaded the day they had to announce it. But they should have given more than 4 months notice.

 

Also May is a strange month to chose considering I bought my Play 5 Gen 1 from Sonos direct in August 2015 so you would expect their 5 year support would be August 2020?

 

 

Well I have no inside knowledge, but being in the software engineering business, the last thing one wants to do is downgrade the customer experience.  I’m sure they thought of everything, the writing on the wall has been clear for years and yes, it was probably met with many meetings full of PR people not believing what they hear from the engineers.  If I had a nickel for how many times I’ve heard “Just make it work” in my job, I could replace my two P:5G1’s.

As to future support, the thing about knowing this is coming, is you can build for future proof-ness.  Also, RAM and SD memory is far cheaper now than in 2005.  You can get a 256 MB card for the price of a 16 back then, and the Play:5 Gen 2 has 8 times the RAM/storage as the legacy devices.  So if the application and data fit in 32 MB now, it’s going to be some time before it hits 256 on the P:5G2.  Now is this enough to outrace the inevitable code bloat?  Well, since Sonos engineers are pretty good at squeezing blood out of a stone, they can probably keep squeezing, even if the stone is 8 times bigger.  


Personally, I disagree with this, although I know that opinions differ.

I think it’s more accurately described as: technical solutions are feasible to allow legacy and modern products to continue to interoperate, but Sonos decided that the (non-trivial) R&D investments required to implement them are not where they should be spending their R&D money.

 

As discussed before, all technical limitations involve financial decisions.  You simply cannot separate the two.  Example: The perfect solution to today’s problem would be to replace every legacy product out there with the equivalent modern product for free. It can be easily done, and it’s feasible. 

Then tell me, what’s keeping them from doing it?


Personally, I disagree with this, although I know that opinions differ.

I think it’s more accurately described as: technical solutions are feasible to allow legacy and modern products to continue to interoperate, but Sonos decided that the (non-trivial) R&D investments required to implement them are not where they should be spending their R&D money.

As discussed before, all technical limitations involve financial decisions.  You simply cannot separate the two.  Example: The perfect solution to today’s problem would be to replace every legacy product out there with the equivalent modern product for free. It can be easily done, and it’s feasible. 

Then tell me, what’s keeping them from doing it?

No big deal, but you’ve been suggesting that it’s not technically possible, I’ve been suggesting that it is technically possible, entirely within software, but requiring a system architecture change. That’s the only difference in our positions.


No big deal, but you’ve been suggesting that it’s not technically possible, I’ve been suggesting that it is technically possible, entirely within software, but requiring a system architecture change. That’s the only difference in our positions.

 

My “technically impossible” statement comes with the fact I wear a project lead hat.  As such, financial impact is always figured into my analysis.  Sadly, I long ago passed the day where I could dream big as an engineer.  

Besides, it is just as disingenuous (though ingratiating to the mob with the torches and pitchforks) to say “It’s technically possible, Sonos just decided not to do it”, leaving off the financials, as it is to say “Sonos could replace every legacy product out there with the equivalent modern product for free, they just decided not to do it.”*

*Though the few times I perused the main threads, I saw this sentiment posted a lot.  There’s no quelling the mob once they get going.  And this mob is something special.  We actually passed the “Holocaust comparison” barrier at mid-day on announcement day, which is a new record. 


No big deal, but you’ve been suggesting that it’s not technically possible, I’ve been suggesting that it is technically possible, entirely within software, but requiring a system architecture change. That’s the only difference in our positions.

My “technically impossible” statement comes with the fact I wear a project lead hat.  As such, financial impact is always figured into my analysis.  Sadly, I long ago passed the day where I could dream big as an engineer.  

I get it. I ran large global software product R&D organisations for many years, as well as having done lots of software development myself. I routinely made decisions of this nature. However there is a difference between technically impossible and too expensive (I didn’t ‘leave off the financials’), and it’s better if we’re honest about that. Just my opinion.


I get it. I ran large global software product R&D organisations for many years, as well as having done lots of software development myself. I routinely made decisions of this nature. However there is a difference between technically impossible and too expensive (I didn’t ‘leave off the financials’), and it’s better if we’re honest about that. Just my opinion.

 

Disagree.  Emphasizing the fact that it can be done to an irrational mob only puts them in a more irrational state.  Technical feasibility cannot be separated from costs, any more than giving everyone a free replacement can be separated from costs.  It’s bad enough they are suggesting Sonos bankrupt themselves by giving away free stuff when they know the costs, why give them hope when they can’t possibly know the costs, only that is is “feasible”?  You and I can have that discussion, because we know.  The mob?  They only want a cudgel to beat on Sonos, I’ll not have my knowledge hand them one.

 

And by the way, thanks to @David_366 for a rational discussion without all the furor.  It's back and forth like this that makes me think this place is not just a mob.  Good talk!


I think people are a lot more surprised than they ought to be, this strikes me as being a fairly predictable issue with any ‘connected’ devices in modern times.

 

Personally, I was more surprised by the short lead time, not the announcement itself. An EOL notice with 4 months warning is not very customer friendly, especially when it’s attached to a $2000 bill.

If it was a year, that’d be different for me. I can come up with a reasonable and affordable plan for updating my system (or replacing it) in a year. I can’t do that in 4 months.

 

I think they did not want the announcement to effect the Christmas retail season.  I’m sure that will come off as greedy to some, but sales of new product is their only income.    Other companies could give a year notice and not risk it effecting sales quite as much since the old products are new products are not nearly as tied together.   For example, if Google announces they are dropping support for an android version, it won’t make people pause in their purchase of a Google Mini.

 

As far as people being surprised, how and why this is happened is different then almost any other product out there.  Some compare it to an analog amp or dumb speaker, while some compare it a phone or tablet...and there are similarities in both, yet significant differences.


 

 

 

Also May is a strange month to chose considering I bought my Play 5 Gen 1 from Sonos direct in August 2015 so you would expect their 5 year support would be August 2020?

 

 

I see two possible explanations for May.  One being that it’s a significant distance from the retail shopping season.  Even if there are delays, I’m sure they want this long forgotten (if possible) by the time people start thinking about Christmas.

 

The other (and I speculate) is that it is timed around product releases or other good news to report.  Two years ago, Sonos announced the Beam around April/May and it came out in July, if I recall correctly.  If there is a new product coming out for the summer, I can see where that may appear to soften the blow so to speak for some people.  Not all for sure, but something.    This could also be part of the reason they can’t give full details of the change over in May.  A product release or other functional tied into this somehow might be something that don’t want to talk about right now.  Again, speculating.  Just a WAG.

 


 

Again, so what? There’s update/install, and then there’s playing audio throughout the zones. I admit that procedure sounds irritating, but playback sounds unaffected. What problem am I solving? 

 

You don’t get it.   There is no update/install, because legacy units, by very definition, have to stay on the legacy software and there is no support for the new protocol changes on the legacy software.  They are stuck with the old software that has no way of connecting to the new! 

 

 

You’re right; I am not following you at all here. You said this (emphasis mine):

 

You take it home and try to add it to the system, and it sits there and blinks at you.  This is because there were some changes to the wireless protocols that are preventing it from connecting.  The standard response when someone ask for help with this scenario is to connect it via Ethernet, add it to the system, let it update to the new software, then disconnect it and it will run wirelessly.

 

That sounds like there’s a workaround that works. So I don’t know what point you are trying to make. Since we’re obviously not communicating effectively here, and continually trying to explain it over and over again is frustrating, let’s drop it.

 

 

So support a reasonable limit if 32 is too big.

The system supports 32 separate streams.  If you truly want what you have now to work with the stuff in the future, you need to process 32 streams.  Anything else is just bargaining away the facts, a very bad thing in computer science. 

 

I only need as many streams as I have legacy components, and odds are pretty good I don’t even need that many since the average user is probably not playing a different audio stream on every speaker at the same time.

This is a hypothetical product intended to serve as a bridge for legacy users to in order to improve interop between old and new. Putting a lower limit on simultaneous streams across the bridge seems like a reasonable restriction to me. Is it a seamless UX? No. But it’s a better UX than having two zones that are walled off from one another, and less distasteful than buying a new product with new features I can’t access/use as long as a legacy device is talking to it.

Might such a device be expensive? Maybe. But what’s expensive to an end user is going to be relative to how many components they have that are being EOL’d. I’d pay a $1000 for such a bridge device since I am facing a $2000 upgrade path today (and I have two first-gen Play:3 devices whose days appear to be numbered, so that cost is going to go up in the near future).

It’d also mean a lot less e-waste. Reuse and extended use is always better than recycle.

This is why I take issue with you describing any solutions as “impossible”. It might be infeasible, it might be cost-prohibitive, but it’s not impossible. But Sonos is not having that conversation. They are giving us the options of all or none and expecting people to accept it. Quite clearly, they are not.