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

  • 1
  • Question
  • Updated 2 years ago
  • Answered

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.

Photo of Nick Lowe

Nick Lowe

  • 5 Posts
  • 1 Reply Like

Posted 2 years ago

  • 1
Photo of Nick Lowe

Nick Lowe

  • 5 Posts
  • 1 Reply Like
Here is an example here of where this policy seems to really hurt customers:
https://forums.ruckuswireless.com/ruckuswireless/topics/zd9-9-and-7962aps
Photo of Michael Brado

Michael Brado, Official Rep

  • 1968 Posts
  • 275 Reply Likes
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_Dec302015.pdf
(Edited)
Photo of Nick Lowe

Nick Lowe

  • 5 Posts
  • 1 Reply Like
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
(Edited)
Photo of John D

John D, AlphaDog

  • 497 Posts
  • 136 Reply Likes
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.
Photo of Nick Lowe

Nick Lowe

  • 5 Posts
  • 1 Reply Like
But implicit to that is that ZD 9.8 MR with 7962/7982, while a supported path, gets all support discontinued such that existing features are soon not maintained and security vulnerabilities are soon not fixed. I am not convinced that it is a commercially reasonable practice to cease support 2 years after EoS for that reason in that release branch.

Perhaps I'm wrong, definitely curious what others think.
(Edited)
Photo of Michael Brado

Michael Brado, Official Rep

  • 1968 Posts
  • 275 Reply Likes
Important bug/feature fixes and all available AP performance enhancements went into the latest
ZoneDirector (1100/3000/5000) 9.8.3.0.14 MR3 that we posted in late July.
https://support.ruckuswireless.com/product_families/1-zonedirector

Ruckus always addresses security issues asap, and may issue sw patches.  We've replaced any
susceptable firmware with patch releases, and we keep a public security notice page. 
http://www.ruckuswireless.com/security 
(Edited)
Photo of Nick Lowe

Nick Lowe

  • 5 Posts
  • 1 Reply Like
Thanks Michael, good to know that common sense discretion on the security front takes place. I worded things too strongly. By "soon not maintained and security vulnerabilities are soon not fixed", I meant that according to the documented lifecycle policy, only 2 years of sustaining engineering can be expected after EoS and, after that, there should be an expectation to be on your own, anything more is discretionary.

I'm naturally playing devil's advocate here, which I do with all vendors. Nothing against Ruckus! :)
(Edited)