Honestly, I had not thought that far ahead yet. I’d love to see some others propose some possible options that we can all talk through and evaluate.
To be clear, I’m concerned solely with extra paid levels of support for the software only, not so much the hardware. In the “pay per box” models that I’ve seen, the hardware itself also tends to get roped in by being treated as if it is still under hardware warranty and/or part of an insurance plan, for as long as the support contract for that box is active. I’m not particularly interested in that; maybe others are, though.
I would say that a healthy percentage – not all for sure, but the majority – of the ROS bugs I run into are not hardware- or platform-specific. I also try to go to great lengths before filing a ticket to come up with a minimum viable config and a way to 100% reproduce the problem on that config. Oftentimes, I will lab things up not with actual hardware, but in speculative VMs with throwaway license keys (24h regular demo key, or CHR 60-day demo I have no intention to buy because I’m going to destroy the VM after I’m done with tests) that I spun up for the sole purposes of bug repro and bug report composing. The bugs I’m interested in fixes for often impact multiple – maybe hundreds – of validly-licensed ROS devices to my employers’ name. I realize this wouldn’t be a problem unique to a hypothetical per-device MT support subscription program, but it still raises the question: would I need an active subscription for all devices covered by the bug I’m trying to get fixed in an expedited manner? Which device serial# or Software-ID with an active subscription do I open up the bug report against? etc.
To avoid all of that confusion, I’d rather that paid software support be decoupled from specific hardware units entirely. Maybe the right answer, then, is to simply start offering a per-incident payment option for “expedited”/priority support, without changing anything else?
Even if MikroTik was to bring back their ESP progarm, this would be great benefit to alot of us. Majority is software issues, lack of QA and online documentation. We need more info and help from the horses mouth..lol.
Within their online support portal, we register our serial numbers and purchase ESP program package that gets tied
Opening support ticket will have required fields, including the requirement of uploading supout.rif.
This would also help created a closed loop for issues being submitted, made aware and addressed. Then fixes be back ported or rolled to stable/long-term…
There are many of us who would pay for “add-on” enterprise level support of RouterOS software…
Rarely have hardware failures with MikroTik [Unless outdoor device with water intrusion].
In my opinion paid , enterprise level support option is a great idea. It would benefit everyone: every customer, as it could speed up fixing bugs for everyone and also incentivizing MT to have lower maintenance SW (ie. LTE versions, more tests).
I believe the reason why I´m rarely seeing MT deployed in enterprise level networks is often the lack of good support.
In contrast: Subscription based feature sets, even just paying for “enterprise” functions/licenses is horrible. The main reason why I´m using MT, is because I´m free to use whatever function I´d like. Also I don´t need to pay or just register for getting docs or SW.
IMO, the root problem is the lack of good written docs… you cannot have good support if you communicate everything person-to-person. If an IT engineer can find the answer in docs, they don’t need to call support. But MikroTik seems to have a fear to commit anything to written form.
The help.mikrotik.com is a fine “reference manual”, but it just not same as the “series” of docs/KBs a typical enterprise router would have. For example, among dozens, it quite the task to determine the HW offloading ability of a particular model. A typical enterprise product would have specific manual for each hardware device that “resolved” its routing/switching ability on each device. And different “guides” with complete examples and considerations/best practices on deploying each of the various protocols, like BGP/MPLS/VXLAN/OSPF/etc. With some cherry doc/blog/KB/etc “Picking the right routing protocol” existing someplace.
Anyway improving/expanding docs plus providing a list of “known issues” with each release notes would go a long way on this topic. @normis claims they have money to hire engineers, perhaps allocate some of that budget to expanding the doc team. Right now it seems the poor support guys have to do double-duty to update docs — so long way from 24x7 support organization (which is very hard).