Why do Ruckus only offer 2 years of sustaining software engineering?

[nicklowe]

I am curious why Ruckus see fit to only offer 2 years of sustaining software engineering after End-of-Sale (EoS) when competitors such as Aerohive and Aruba offer 5 years?

Looking at the documentation that Ruckus provide:

Ruckus Support is unable to provide software fixes or upgrades which may be required to resolve support cases after the EOM date. 

I think that it is important to factor in how long sustaining engineering is available when calculating the total cost of ownership for a wireless solution.

It is one thing to not get new features after EoS hits but quite another to be left with unmaintained, unfixed software. 5 years not 2 years seems reasonable.

What do others think? When you buy or think about buying a Ruckus solution, does this more limited useful product lifespan not concern you?

As many customers clearly buy having not fully checked when an AP or controller came to market, having a safety net of 5 years of sustaining software engineering after EoS seems, to me, commercially reasonable.

[nicklowe]

Here is an example here of where this policy seems to really hurt customers:
https://forums.ruckuswireless.com/ruckuswireless/topics/zd9-9-and-7962aps

[michael_brado]

Hi Nick,

  We understand your viewpoint but are trying to balance doing new development versus
supporting/maintaining older products.  Chips used for CPU, memory, Flash, and radios
have all been upgraded in new model APs, to be able to provide the added features/functions
that the software team are writing.  We'd like to provide 5,6,7 years of continued fixes after
EoS date, but are meeting Cisco's 2 years after EoS support.  If further bug fixes become
available, we'll certainly provide them, but DE focus is on new feature development as we
aim to provide the best products.

  Please contact your Ruckus account team, or local VAR, regarding any TradeUP or other
discount offerings, as these may vary across territories, but I can't offer more thru the forums.

  Here's a link to our marketing brochure on the TradeUP program:
http://marketing.ruckuswireless.com/acton/attachment/3040/f-0459/1/-/-/-/-/Tradeup_Customer_Dec30201...

[nicklowe]

Hi Michael,

Thanks for the reply.

I do not think that it answers the question though.

I am struggling to understand why sustaining engineering after EoS until EoL for APs/controllers would impose additional, tangible constraints on the resources available as new, additional features would not be added.

Sustaining engineering that is carried out until EoL occurs would instead only make corrections to existing features or resolve security vulnerabilities. That is the very purpose and nature of that process via maintenance branches.

Surely the CPU, memory and flash storage argument that you put forward is moot and simply not relevant to the point under discussion?

What am I missing? Is this not a realistic and reasonable expectation for your customers to have?

Cheers,

Nick

[john_d]

I think Michael's point applies to the question you pointed out regarding running ZF 9.9 and 7962's. ZF 9.9 is a feature release and for the customer, running 9.8 MR with 7962/7982 is a supported path.

Not arguing against your point though. 

Personally speaking, this is not something that bothers me a lot, because my requirements for fast wifi generally means the technology advancement outpaces Ruckus's EOL cadence anyway. I set up two deployments, one using R600/R700/R710, and one using ZF7982's. When setting up the 7982's, I knew what I was doing lifecycle wise.

Now, about a year and a half later, the 7982 isn't even EOL, but it's starting to get to the point where I've been thinking hard about upgrading. And by the time the R600/700 go 3-5 years and start becoming EOL, I can't imagine not wanting to upgrade them too.


EOL or not, you are still paying a constant support cost to run the controllers, and Ruckus offers some very attractive trade-up promotions. I think between the two, there's always a good upgrade path going forward.

The only case where I felt a bit upset was the EOL of the ZD1100. At the time I bought it, it was still the newest ZD on the market, and I got it to go along with the 802.11ac AP's. These AP's never got feature complete before ZD1100 was EOLed. Unlike for the AP's, the VAR didn't have any incentives for controller upgrades despite it being under a year from when I purchased the ZD1100, so to be fair, I think that situation could have been handled better.