Collaboration between interested parties!

[jimmycuadra]

Hello, everyone! If you're just seeing this project for the first time because I CC'd you, take a look at the README, or if you feel like spending more time, you can watch the presentation I did about it at the SF ChatOps meetup last year.

Since this project would not be particularly useful if there weren't compliant implementations for multiple languages, I'd like to gauge the interest of people involved in major chat bot frameworks, tools, services, etc. I'd like to know:

1. Do you think this is a good/worthwhile idea to continue developing?
2. For Hubot/Err maintainers, would you be interested in potentially adding support for them running in an OCO-compliant way in the future? (Assuming OCO progresses to a useful point of maturity.) Obviously, Lita is in. It'd be a big win for all three communities if in the future plugins written for one bot were usable by the other bots.
3. Would any/all of you be interested in helping to develop the spec and/or the reference implementation with me? If I drive development by myself, I'm afraid we'll end up with something better suited for Lita than for Hubot/Err/Cog/whatever, since that's where most of my familiarity and experience are. I also want to factor in the design of newer systems like Cog (which is a lot closer to the spirit of OCO than Hubot/Lita/Err.) Plus, collaboration in general always results in a better product than the unfiltered crazy ideas of one person.

Feel free to reply here and/or come chat in the IRC/Matrix channel I created for the project (see the community section in the README.) And of course, please CC anyone else you'd like to see involved that I missed or don't know. Thanks for your time, everyone!

/cc potentially interested parties:

Hubot: @technicalpickles, @michaelansel Err: @gbin, @zoni GitHub: @jnewland Operable: @imbriaco, @Shelton PagerDuty: @tristaneuan, @esigler VictorOps: @jasonhand Librato: @djosephsen Shopify: @byroot, @Sirupsen

[casperisfine]

@byroot here (work account).

We migrated from Hubot to Lita 18 months ago because we are primarily a Ruby shop and as such our Hubot instance was badly maintained and it was more complicated than it should be for our developers and ops to write and maintain plugins.

Since the migration, the number of contributions and contributors have been multiplied by 5 at least:

So yes definitely the language used matters a lot. From my point of view, nobody work full time on a chat bot plugin. It's more something you hack quickly so you can make a few key metrics and routines accessible from your enterprise chat. It's a very nice thing to have, but not enough for people to bother if the barrier of entry is too high (e.g. new langage or too different paradigm).

With that in mind, as you menton in you talk / spec, the advantage of an unified framework supporting multiple languages would be a bigger pool of chat service adapters and plugins.

In our case we have ~90 Lita handlers, our of them only 2 come from public Lita plugins (dice and wolfram-alpha) and I just searched our slack history, they haven't been used at all in the last month. All the other handlers are custom built, most because they integrate with internal services, but even for general services like say GitHub or PagerDuty the open source plugins were not satisfactory, both the Lita and Hubot ones, and that for diverse reasons:

• The commands format was not consistent with the others
• It was missing some capabilities or had capabilities we didn't want (e.g. deleting a GitHub repository)
• Writing our own specifically for us allowed a better user experience because we could implement our internal workflows in a single command instead of teaching people a list of commands to run in a specific order.

And I suspect we're not the only ones, https://github.com/litaio/lita has 1200 stars, https://github.com/PagerDuty/lita-github 9 stars.

As for the chat service adapter, while we were happy to be just able to grab one, we had to implement quite a lot of Lita helper so we could exploit more Slack feature than just the IRC supported ones, and also all the messages the bot send use the Slack markup. So in the end it's not like we could switch to another service just by replacing the adapter. And while this abstraction totally make sense from the framework point of view, it gets a bit in the way sometimes when you write custom plugins.

And finally architecture and operation wise, hosting an application written in multiple different languages talking over RPC is way harder and way more problematic than hosting a monolithic app, and I would feel way less confident maintaining it internally than I do maintaining our Lita installation. So even if it was available tomorrow morning, we would likely stick with Lita as it's very low effort in term of maintenance for us.

So to sum up my professional view on this, while it's conceptually a very cool idea, the cost / benefit ratio isn't there for Shopify given our chatbot usage. But good luck!

[jimmycuadra]

Thanks very much for the thoughtful reply! Those are all good points and I will think about how OCO might be designed to alleviate some of those concerns, and more importantly whether the whole thing is even worth it for what actual benefit it would provide.

[gbin]

We talked a little bit about it at the chatops meetup but here are my thoughts about it from an Errbot maintainer perspective.

First, I think the main difference between plugins written for Hubot / Lita and plugins written for Errbot is that on Hubot and Lita you quickly end up developing a plugin for let's say Slack but on Errbot you develop a plugin ... for Errbot. Let me give you a series of examples:

• plugin output is always extended markdown. It will generate colors, tables, embed images etc on any chat system if it can do it or the best it can if it cannot
• Identifiers (the thing pointing to people) are not strings, they are an abstraction that clearly map to rooms, persons, persons in a room. Your plugin can compare them, store them etc...
• Identifiers are leveraged all over the API for example for presence callbacks, mention callbacks or ACLs
• and more high level functions: the file transfer API is common, the card rendering (called attachment on Slack) is common etc.

And our users have been swapping their chat systems quite a lot those last 5 years ! Just myself, I have been using Errbot on XMPP, then on Hipchat to finally settle on Slack + Gitter. The chat landscape is more fragmented than ever so I expect people will continue to do that.

Second, talking about those high level functions, we have added a lot of things that are pretty foreign to other bots like for a couple more examples:

• flows (as conversation flows): being able to concurrently track a state of a back and forth communication over a state machine with a participant or even a group of participants
• command flavors / parsing: we support plain commands but also arg parsed ones, regexps (a la Hubot), ...
• persistence for simple stuff is part of the API too (Errbot can end up storing it locally or on a redis or Google Cloud Datastore or S3 etc..).

Last, for the language, I agree with @casperisfine that people don't want to invest in foreign languages. In some extend Errbot has been mitigating that because python reads like pseudo-code and the dead simple ramp up with it: a method returning a string, boom you have your first command (yep I look at you Hubot where you need to grasp what a callback of a callback is before doing anything ;) ) ! So I see a lot of Errbot users with no notion of Python starting using it and asking beginner questions on our support chat.

Ok, after all that, what is my point ?

TL;DR If we write a common denominator between bots through an API, I am pretty sure that everything that makes Errbot great disappears if you try to develop against it. This is simply because you can be sure one of the other bot won't support it (either a correct abstraction vs a chat system, or a sane identity management or any other high level function).

And, the simplicity goes out of the window: we'll need IPC, stubs, non-idiomatic mapping to the targeted language etc. What is a errbot -T + a method that returns a string to get started become : start multiple processes/docker containers, write against skeletons, parse raw strings etc.

So while I love this idea, I am a little pessimistic about its success as I don't see how to make it so good it becomes an incentive for Errbot plugin designers to develop against this common API.

[jimmycuadra]

Great feedback—thank you, Guillaume.

The bullet points you list for things Err does that Hubot and Lita do not are good examples of the competitive advantage the bots can have against each other. I think this is a good thing as it drives innovation and, more importantly, helps to solve the needs of users. If OCO were to represent a common denominator, it should include at least the things you listed (and probably others) as baseline features, which would in turn push their addition to the other bot frameworks. Flows are a good example of this. This is a feature that has been requested many times for Lita. I was aware that Err had the feature but I haven't looked at how it works in detail yet. (Lita does have CLI-style argument parsing, but it's implemented as an extension, not part of the core API.)

However, we then run into the problem that you do with any interoperable spec, which is that when you want to evolve new features for one bot, you now have the added overhead of considering spec compatibility, which will likely move more slowly than what you'd for your own framework. A possible solution to this would be to treat bot frameworks as dependencies in the same way I describe "specific data stores" in the spec. That is, if a plugin needs features not universal to OCO, it has a dependency on the specific framework it was written for. This is also similar to what I say in the presentation video about how features specific to a chat service are handled in Lita today. That is, you're welcome to use features specific to a chat service, but it of course binds your plugin to work with only that service. If Lita's API later added whatever you're using as a core feature, then that restriction would obviously be lifted. I think that's actually a good way of prototyping new features before adding them to the standard robot API. I can see that process as analogous to a whole bot framework prototyping a feature for OCO. And of course, many of the features that might set one bot apart from another may not actually require different APIs at the OCO protocol layer. Examples of that, as I mention in the video, are integrated HTTP clients and timers for executing code after a delay or at intervals.

Operational/deployment difficulty is the challenge imposed on users that seems like it might be a bigger blocker to OCO. Interestingly, Cog takes an approach much more similar to the OCO idea, where plugins run as separate apps that get invoked by the main bot program, and so plugins can be distributed across a cluster, and can be packaged as container images. This is obviously meant for a more serious business use case, and is likely unnecessary operational complexity for the average Jane. It sounds like Jean is echoing that sentiment, which shows this is a real problem even for teams that have the technical ability to manage OCO/Cog-style architecture. I'll continue thinking about how OCO could be a smoother deployment for the "average Jane" case.

[technicalpickles]

Hubot: @technicalpickles, @michaelansel

Also cc @bhuga