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.
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 :)
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.
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.
