Going to carve off a use-case. If your printer does not play well with OctoPrint, your printer is garbage.
OctoPrint is a very nice piece of work. OctoPrint makes the best possible from printers that only vaguely/sorta/kinda offer a controllable interface. Gina does an admirable job in trying to be accepting of crappy printers.
Gina is trying to make silk purses out of pigs ears.
I am a software guy. APIs are damned important. We can do a lot with even fairly minimal well-defined APIs.
Someone needs to become strict. A printer needs to be reliably responsive in command and status. This could be reduced to a set of strict tests.
Printers need to respond exactly to external control.
Printers can be valued as they respond exactly to common theme.
Watching the videos from MMF and someone(?) asked what is next. To get past the foggy futz-around-until-it-works model, we need stricter evaluation of new printers. New printers should be predictable and controllable. That notion requires measure.
A new field needs a single standard (at least at single time). Perhaps we should appoint Gina as the God of all interoperable things.
My suggestion is that all printers become strictly controllable. That could mean scoring by an OctoPrint module. Any printer review should mention this score.
We need at least one hard criteria other than the price. 
Thanks but, could you give me one idea why I should go OCTO when I Have S3d ? Especially when I Have Duet Wifi board that got brilliant and simple web interface …
I am torn between admiring Gina’s work to make OctoPrint work for as many people as possible and predicting that this permissiveness will just make printer makers even sloppier and we’ll end up with an awful mess of an API. The “effective SLO” problem, essentially.
Either a printer should be some expensive proprietary thing where they have spent time and effort to build it with a slick interface, which is fine if you like that kind of thing, or it will be based on the open source controllers and firmwares, and will be easy to switch out to the latest standards. there really is no excuse for anything inbetween.
@Preston_Bannister There allready exists a standard for cNc machines that has existed since the 1950’s. This is the RS-274 standard, sometimes called gcode. This has always been slightly modified from use case to use case but still remains a standard today.
There’s always the excuse of “it’s cheaper to just hack something together that almost does it right.”
The fact that gcode gets modified from use case to use case is just what makes it necessary for Gina to put work towards making the printers work rather than advancing the state of the art.
Yeah no the gcode we use is not a standard. Yes, there’s a bunch of commonalities in the commands you may send, but for OctoPrint and BotQueue, @foosel and I have dealt with a hellish number of issues related to gcode inconsistencies.
Unfortunately, every attempt to standardize them has resulted in unmitigated disaster.
In a way the standard is set. The standard allows for alot of custom options and that is how it has been for all CnC machines. The solution in the past is simply to have companies like HAAS or Mazak public post-processors for gcode for applications like mastercam so toolpath writers could make toolpaths for multiple machines with the industry standard CAM solution!