I love this kind of service, but extensibility is probably the most important feature and unless I'm wrong, your platform is not open (yet). We developers all use different services.
Hubot is extremely simple (based on regular expressions to match commands) and quite successful because it's so easy to write and use your own module [1]. Hubot being free and open source, what is your differentiation plan? I'm sure there is room for different players.
We want to run this as a service, for eg with hubot you need to add the API keys in a config file which isn't that easy unless you have a dev to write something on top of it. We are planning to make the UX really simple on provide /pulling the data from your services.
We use OAuth so we don't store any API keystroke passwords. Well more than the ease we are trying to make this collaborative so you can add data to your team mate services easily.
Not sure what you mean by "API keystroke passwords". Almost all major APIs these days that you'd be working with for your bot use either OAUTH, generated API token strings, or bot. So you're either storing an OAUTH token or a token that isn't OAUTH but that the user treats a lot like a simple OAUTH token (it is use-case-specific, can be revoked, is identified by its purpose, etc)
Ask a non-developer to just update the configuration file with the API keys received from whatever service and you'll get a confused look as an reply in most cases.
Keep in mind that the people who have need of this kind of thing are typically dev , ops, or both. To neither group is updating a configuration file a major consideration.
It sounds like these may not be your target audience - but in that case, who is?
Well, its not just updating the config details its connecting other team mates apps together for eg you can create a google calendar event in your team mates calender by adding their name @teammate :)
This is great, thanks for sharing! What I think I like most about this is project's emphasis on testing, something I've always missed in Hubot scripts.
Is this supposed to be "Hubot, but usable without hiring a developer?" There are lots of non-software companies that could benefit from chat-ops-like automation.
Nice suggestion. Yes we would want to open this framework for custom integrations. We are trying to create a bot which is easy to setup and use with neat interactions. We will be doing this as a service integrating interesting commands and services. We would want to provide an easy way to add data to other team members eg: You can create an event and add your team members calendar too easily.
I don't really see the appeal of this because it looks like it's only good for one-liners. I'd rather have a complete interface that allows me to write a huge description, provide screenshots, link to other bug #s or githud commits, etc. It's a solution looking for a problem in my opinion because I would be pissed if all of a sudden all my issues, tasks and bug were one-line description. Please correct me if I'm wrong but that's what I get from the first impression of looking at your app.
We are just getting started but we have plans to build an interactive input methods where you can add more details to your apps. We do have plans getting there. We are initially mobile focussed.
We don't have any plans of open sourcing it at the moment. We want it to be a service and it is free. Yup we are starting with slack and we have plans to integrate Chat apps which has the API option open :)
How about integrating with a protocol instead of adding value to someone else's product?
Have we not learned our lessons from how Twitter treated developers?
Enjoy getting shut off when Slack decide they don't want customers to be adding functionality without paying their per integration rate, or want to stop getting the support tickets from people using your service and confusing it with Slack itself.
Thanks for your feedback. Actually the communication market is picking up. We are not dependant on slack we are an API which can be plugged to any chat service like Hipchat kato etc.
Your company may not be directly dependent on Slack, but if I pay you to use your bot with my Slack system and then Slack pulls the plug, I'm dependent on Slack and your bot working together.
If Slack pulls the plug on your integration and enough of your income is from users who are integrating with Slack, your business could indeed be impacted.
We are working closely with Slack team to get this going. I don't foresee that happening since we promote people to get on board with slack. It's a win win. But I do get your point :) thanks for the feedback.
I think this seems like a great idea. But I have never worked one place that used any of the seemingly trendy integrations. How about Lync -> Jira, Confluence, Perforce?
Hubot is extremely simple (based on regular expressions to match commands) and quite successful because it's so easy to write and use your own module [1]. Hubot being free and open source, what is your differentiation plan? I'm sure there is room for different players.
[1] http://hubot-script-catalog.herokuapp.com/