I understand that Hubot is more framework than finished product. My point is that when I am evaluating whether to implement it fir the company I work for vs spending time and resources on some other side project, I am having a hard time making a case for this particular framework.
As for production vs dev: Hubit is either your tool for deploying code or it is not. If there are many ways to deploy the same piece of code you are doing it wrong. Now consider being the Ops guy who has to deploy a critical security fix and Hubot took a cigarette break because it never started properly or some other bug in the code caused it to fail.
Understandable. But surely you would have a fall back way to deploy given your main way doesn't work? I can deploy my apps via Hubot, but I can also deploy them without Hubot because I have an abstraction that Hubot uses to deploy my apps. And as far as I know GitHub have also something similar in place.
A bug in any piece of software is going to cause issues, Hubot isn't an exception.
Yes. And I agree that any piece of software in you stack can ahve bugs that make life difficult. My issue is that (1) Hubot is supposed to be central to your ecosystem and (2) when I looked at the code at first I saw a style of deployment and docs that made me think that running it would be more trouble than it's worth.
I am continually trying to help improve the deployment and documentation of Hubot, and I even created https://hubot-factory.herokuapp.com that makes it really easy to get up and running on Heroku.
As for production vs dev: Hubit is either your tool for deploying code or it is not. If there are many ways to deploy the same piece of code you are doing it wrong. Now consider being the Ops guy who has to deploy a critical security fix and Hubot took a cigarette break because it never started properly or some other bug in the code caused it to fail.