I have just learned that the Prusa Mini will include a product called PrusaConnect, which is essentially a web-server built into the 3d printer. Now, this wouldn't be a big deal at all, but they have so far NOT implemented USB support. This means that Octoprint will not work without additional development (that Prusa will likely not contribute to). Furthermore, they have implemented a fuse that you have to physically break in order to flash custom firmware, which will make this new software difficult to remove.
I'm not against manufacturers doing their own thing, but this feels like an assault on our community, and an attempt to close down the printer's hardware/software and shut out competition. I am aware that the current source is 'Open' but they now have 'Closed' hardware, and have removed (or at best have not implemented) critical third party connectivity components.
I don't know about you, but OctoPrint was what led me to purchase my Prusa MK2, and I'm certain I'm not alone. If anyone feels the same, feel free to comment on their thread here, or on the official blog regarding PrusaConnect and the new 'Fuse' here.
Sorry to hear about this. I don't have a Prusa printer and I was actually considering the possibility, given their MMU2 device. But after this? Hell no.
What actually annoys me the most about this is that I can already picture what'll happen once that thing becomes more mainstream edit and indeed turns out to be incompatible.
"Why doesn't OctoPrint support it? Can you fix this?"
So, just for the record - I will not divert time off more pressing issues to adapt the code to communicate with a pretty much proprietary interface just because said interface happens to belong to a printer from a popular manufacturer. I didn't do that for Makerbot and I won't do that for Prusa Research edit2 or any other manufacturer either. Not even if said manufacturer decides to document the API. That would be utterly unfair to everyone who doesn't have said printer.
Once 1.4.0 stable is out I plan on fully concentrating on the new comm layer anyhow, which will heavily facilitate plugins to adapt to proprietary interfaces. Beyond that it edit would fall to edit2 whatever manufacturer or the community to write a driver edit if it doesn't speak the common gcode protocol.
On a more personal note, let me add that I find this development towards walling up the garden worrying to say the least, and that just like with the whole pi0-support-on-the-einsy I would have wished for a more collaborative approach with the established community. But I'm also (sadly) not the least bit surprised.
Edit it has come to my attention that there seems to be some conflicting information floating around now whether the mini is compatible not. My above points however stand should it turn out to be incompatible indeed. I've adjusted the phrasing sightly to properly reflect the current uncertainty.
Edit 2 further adjusted since it looks like it's probably compatible after all