ibid-dev team mailing list archive

[Jonathan Hitchcock <jonathan.hitchcock@xxxxxxxxx>]

Hi Matthew,

Apologies from us for taking so long to finish the interview.  We
answered it like we write code:  by consensus, and this may have
slowed down the process somewhat ;-)

Here is our reply:


Thanks for interviewing us.  These answers have been put together by
the three main developers of Ibid: Jonathan Hitchcock (~vhata),
Michael Gorven (~mgorven) and Stefano Rivera (~stefanor).


1. What are you doing with Ibid that's different to other chat bots?

Like all bots, Ibid has two parts: the front end, and the back end,
and we like to think that there is something to distinguish Ibid in
both.

On the front end, we attempt to make the bot as intuitive as possible
to interact with. All commands are natural language, and our
philosophy is that the plugins should try to work out what the user
actually wants to know and answer that, rather than forcing him to
learn an esoteric set of syntax before he can use the bot.  Queries
are bubbled through plugins in order of priority so that the most
relevant reply can be given.

Secondly, on the back end, Ibid is also divided into two parts:
"sources" (i.e. transports, communication mediums - IRC, jabber,
email, etc) and "plugins" (modules that tell the bot how to respond to
various queries). The design aims to be clean and modular:  all
sources and plugins are discrete units that can be enabled or disabled
without breaking any assumptions elsewhere in the code. Unlike other
bots where non-IRC protocol support seems to be an afterthought, Ibid
plugins deal with all protocols equally (hopefully without making them
all equally bad).  This modularity helps both new and existing
developers.  It is easy to jump straight into a small part of the code
without having to understand the entire system. It is also very easy
to add new sources: we had a DC chat source up and running in under a
day, and a prototype GSM SMS gateway in a weekend. In addition,
hot-pluggability is an important goal of the project: you can add and
remove plugins and sources on the fly, without having to restart the
bot.


2. Who do you see using Ibid?

As we've been developing the bot, we've started thinking in terms of
three different personas: users, owners and developers.

Users are the end-users who happen to be in IM channels where an Ibid
is running - they should just see the bot as a fun and useful tool.
They'll notice people using it to google things, store factoids, check
the weather, do currency conversions, and so on, and start following
suit.  We've noticed that our bots very quickly become integral to
channel communities, and we try to make sure the bot's "personality"
facilitates this:  the natural language interface, and the
characteristic responses that the bot gives aid this. Michael and
Jonathan both have Ibid instances running internally at their
companies, and the other employees find them very useful.

Owners are the people that run instances of the bot - they probably
run the channels too, and they need a way to integrate other things
with IM.  Ibid aims to make that easy.  We've already got plugins for
checking RSS feeds, working out distances, fetching tweets, and so on
- the plugin nature of the bot's features mean that as soon as a new
need arises, we can churn out some code to fulfill it.

This is where the third persona comes in: the developer.  Ibid is
designed to have a very low barrier to entry, and to make it very easy
to write plugins, so it can be used as a framework for interfacing
with almost anything. It already has plugins for interfacing with
Bazaar, Trac and Buildbot, and a Launchpad plugin is in development.
Because Ibid is so modular, stripping out all the funky stuff to build
an IM interface to a single service is pretty simple, and Ibid hopes
to be a good building block for such systems.  Which brings us to your
next question...


3. Are you hoping to attract developers to Ibid?

See http://icanhascheezburger.com/2007/12/09/yes-yes-a-thowzand-timez-yes1/

That would be a yes. In the channels where we have Ibids running,
users have contributed plugins for features they want, and in one case
used it as a quick way to get an IRC game up and running. We'd like
more of all of those.

We've done our best to make it as simple as possible to write Ibid
plugins. There's still some work to go (mostly documentation), but
anyone who knows some basic Python should be able to hack a quick
plugin together in a very short time.

We haven't made an initial release yet, as some of the Internal APIs
have some biggish problems that need to be resolved, but the bot is
packaged and already works out of the box, and we'd love for people to
start using it and contributing plugins.


4. The project's a fairly heavy user of Bazaar. What made you choose
Bazaar over other VCSs?

It was almost accidental - we didn't have much experience with DVCS,
but we definitely wanted to use one rather than, say, subversion. We
saw that the Ubuntu community was punting Bazaar, which is relatively
sane (compared to, say Git), and ran with it. It turned out to be a
good choice: it's simple to learn and pretty powerful. It also has a
very low barrier to entry, coming from more traditional VCSs, but you
can ramp up to using the advanced features in fairly small, but
logical steps (which makes it very similar to python, as a learning
language, I suppose).


5. What aspect of Launchpad has most helped your development of Ibid?

We originally started with Launchpad just to get quick bug-tracking
integration, but soon discovered the other features on offer. After
moving the source over to be wholly hosted on Launchpad, we started to
use branches and merge-requests, and these have now become integral to
our development methodology. Every feature and fix that we work on is
developed in a separate branch and the merge reviewed by all three of
us. Waiting for reviews can stagnate development a bit when all the
developers are busy with their dayjobs, but we think the results are
worth it - apart from the obvious benefits of catching bugs before
they're merged into trunk, the request-and-review process keeps us all
involved and aware of what is happening in the project.  I imagine
that as we grow, this benefit will lessen (since not everybody will
review each merge), but it is still a good way of signalling to the
rest of the team that changes are happening in an area, so that if
they are interested, they can make their opinions heard before the
changes get finalised.

As a whole, the tight Lauchpad-bazaar integration has been a huge
bonus, allowing us to develop from a few guys committing bits of code
to trunk into a community with workflows, milestones, goals and a
clear vision of where we're headed.  Having the VCS and the
bug-tracker and the discussion boards and everything all in one place
really builds cohesion in the project.


6. What would you most like to see improved or otherwise changed in Launchpad?

We have been moving more and more of our project management into
Launchpad (throwing out Trac, and our own Bazaar repository, and our
own mailing lists, and so on), but there are still a few things that
we have to host ourselves: repositories for non-Ubuntu packages (just
Debian debs right now, but we'd like to include RPMs, etc, in the
future), the build environments to create them (we have our own
pbuilders presently), documentation, and our wiki.  There are free
services that provide each of the above, such as the OpenSUSE build
service, and the many "create your own wiki" services, but filling
those gaps would mean our project could live entirely on Launchpad,
and would bring along greater integration and easier flows.

Other neat things we could use would be support for Bazaar hooks, and
permanently linking merge commits with the merge request - currently
we include the merge request URL in the commit log.

Basically, tighter integration of everything would make project
management much easier, and let us focus more on coding, which is
always a win.


Thanks again for interviewing us!
Cheers,
-The Ibid dev team