I think @levicki is correct about being beholden to the manufacturer’s release cadences. Most manufacturers of embedded networking kit are still hanging out on kernel 3.x. It’s really annoying! If any manufacturer is reading this: STOP DOING OUT-OF-LINE KERNEL RELEASES. UPSTREAM YOUR CHANGES.
I digress…
In terms of features, at release, ROS 6 was in the unique position of supporting some fairly advanced scenarios; but these had to be developed in-house. Since that time, much effort (and a LOT of money) has been put in to the Linux network stack, especially in the v4.x series. As a result, vanilla Linux kernel can do almost everything ROS can do, and more besides. ROS can’t leverage those developments unless they backport the features from v4 kernel to v3 kernel, because most manufacturer SDK’s are, as mentioned previously, still stuck in kernel v3-land.
So, all this to answer the question, “When?” My gut tells me that it won’t happen until it’s more painful to maintain ROS v6 than it is to start over and leverage open-source efforts better. As ROS v6 continues to age, use-cases in [newer, more complex, software-driven] environments will shrink; to the point where it’s only useful for very small providers, small business, and home users.
From where I’m standing, as a service provider, the competitive landscape is changing rapidly. To survive, I must be able to offer new services my customers are demanding as quickly as possible. Right now, my biggest limiting factor in delivering those services is RouterOS. I really, really love RouterOS, but it’s not growing with me and, sadly, I don’t think Mikrotik is all that interested in what we have to say.
Evidence:
- Numerous attempts to solicit ideas for future products from the forum community (see: http://forum.mikrotik.com/t/which-types-of-ports-would-you-like-to-see-for-a-high-speed-router/108634/1), then basically ignoring it and going a different direction
- Continued focus on last-mile and switching-type devices and software supporting said devices
- Inability and/or unwillingness to maintain a coherent feature request list (see: https://community.ubnt.com/t5/UNMS-Feature-Requests/idb-p/UNMSFeatureRequests as an example of how to do it better) that the community can vote/provide feedback on
Am I wrong? Possibly. I’m trying to be as objective as I can in this analysis; but I’ll admit I’m at the point of “believe-it-when-you-see-it”.