launchpadblog

The online team at The Economist recently set up a Launchpad project, using a commercial subscription. I asked Mark Theunissen, from The Economist Group, about their plans.

Mark: We’re migrating the existing Economist.com stack from Coldfusion/Oracle to a LAMP stack running Drupal. At present, we’re about half way through — if you visit a blogs page, channel page, or comments page they will be served from Drupal, but the home page and actual articles are still served from Coldfusion. There’s a migration and syncronisation process happening in the background between Oracle and MySQL.

Matthew: Is much of your web infrastructure based on open source software? If so, what?

Mark: Our new stack sure is! 🙂 We run almost all open source, in fact I can’t think of anything that isn’t.

• Redhat Linux servers throughout (not Ubuntu, unfortunately).
• MySQL enterprise database.
• PHP 5.
• Varnish HTTP accelerator.
• Drupal content management system. Actually, a distribution called Pressflow.
• Memcached for caching.
• BCFG2 for configuration management.
• The Grinder for load testing.

Matthew: Do you customise much of that?

Mark: We do, yes. We’ve sponsored or contributed patches that have mostly been for Drupal but also made their way into Varnish & BCFG2. We use Pressflow, and our changes go there first and often get back ported into core Drupal. Our policy is to open source as much as humanly possible!

Matthew: And, of course, I’d love to know what made The Economist choose Launchpad.

Mark: We chose Launchpad for its usability, mostly the workflow around reviewing code (merge proposals). It provides excellent tools for managing distributed teams, and we are a very large distributed team, with three locations where development is occurring on either side of the Atlantic.

The integration with Bazaar is great, and we are going to consider moving our bug tracker to Launchpad too at some time in the future.

Matthew: Thanks Mark!

Thomas Pietrowski is an 18 year old high school student in Solingen, Germany, whose mopedix project aims to create a control system for mopeds and other vehicles.

Matthew: Tell us more about mopedix

Thomas: My software system is split into two different parts.

First of all there is the control system, which is using an Arduino to control relays and H-bridges that also can dim light. This project is still under construction and soon I’ll be adding functions such as locking via a RFID reader and activating an alarm using an accelerometer.

But the important part of the project is the interaction between the control system and the computer. The client can be used for setting your values, e.g. when you want the moped to turn on its lights according to the intensity of the ambient light. In general it sends commands via serial connection and this gives the project a wide range of ways to communicate with the Arduino used to control the moped’s lights.

At the moment I am working with the Arduino Duemilanove, which has a built-in USB-to-serial adaptor. But there is also the possibility of communicating using a cable, e.g. RS232 or simply two wires, one for incoming data and one for outgoing data, or wireless via Bluetooth [50-100m], radio frequency [2-10m], Xbee[>90m-1.6km (1 mile)] and many more. Using Bluetooth you can also change your settings using a Nokia mobile phone running PyS60 or other devices that can send commands via the serial connection to the control system.

But to be honest, the control system has not been tested on the vehicle, as I still need to transport it from my grandparents in Poland to Germany. However, I’ve tested that it works in theory.

Matthew: What prompted you to start writing software that interacts with your moped?

Thomas: I decided to start the project in the end of 2009 when I looked on the web to see if there was something similar already available. I found some discussions in forums and elsewhere but didn’t come across anything that really did what I wanted.

The most important thing that interested me was how much such a control system would cost, because prices on the market are in the most cases not very realistic. Imagine a radio frequency controlled locking system kit for your car. Such a kit can cost around 100 Euros. Now think about making such a locking system on your own using Bluetooth and your mobile phone.

Here is a short calculation what you would need:

• a bluetooth-serial module (14 Euros from China)
• an Arduino board (20 Euros)
• a 6v relay that can handle voltages of 12v (2 Euros)
• and some other typical things like a few transistors, resistors, cables, and a solder clip (5-7 Euros).

That makes a total of 41 to 43 Euros and some hours programming your Arduino and a little Python script for your Nokia S60 mobile phone.

So, can you see it can be cost effective to offer such a system.

Another thing is that I had an Arduino Duemilanove and had been developing some applications in Python for my personal use, so I had the most important things that were needed to start my project: the resources and the knowledge.

Because of the great community, lots of Arduino users, a detailed instructions for programming the Arduino and my own Python experience, I decided to give it a go.

Matthew: What sort of interface does a moped have that allows you to hook it into a computer?

Thomas: You can use mopedix in general on any vehicle you want. I aimed it at mopeds because, as an 18 year old student, I only have a moped and access to its schematics.

By reading its schematics I noticed that the heart of my moped was actually the ignition lock. The control system that I am working on is nothing more than a digitally controlled ignition lock”, which will replace the old one and provide an interface for the client application.

The system will be powered on my moped with 6 volts and newer mopeds that have 12 volts will need at least a 9V rectifier for use with the Arduino Duemilanove or a 5V rectifier for the Arduino Mini. An Arduino Mini will be great for the control system because I believe that there will be also vehicles that will have room available than in my moped.

It should be possible to use the same software and control system on a car. So, for the future I should think about a project name that isn’t specific to a category of vehicle.

Matthew: Is there any other software, proprietary or open, that does a similar job?

Thomas: Not that I know. I found, via Google, a patent that describes a control system for bicycles, but I am sure that there is no other software, neither proprietary nor open, that can be compared with mine.

In addition to that I would really like to learn from people who are familiar in working on free software and earning money for their work to show me how to earn money on my own for buying additional modules, like a bluetooth-serial-module, to improve my software and provide the end-user a wider range using the control system.

Matthew: Why did you choose Launchpad?

Thomas: I chose Launchpad because I worked on packages that are hosted in my PPAs for the Canola project (that page is a little outdated) and I have been helping to test unstable Ubuntu packages since Lucid Alpha 3.

So I was already familiar with Launchpad but the main reason for choosing Launchpad was that it gives the possibility to other people translating my client application into their languages from English.

Moreover it gives the possibility for the end-user to get in contact with the project using the “Answers” tab on the project page or report errors by using the “Bugs” tab. As well as that the user is able to follow the future of the project by the “Blueprints” tab. But I haven’t used this feature yet because I didn’t think that there were people who would be interested in my project.

The only reason I don’t use Bazaar is that I’ve only previously worked with Subversion. I hope to take some time to learn Bazaar, in the future, switch over from Subversion.

Matthew: Thanks for telling us about mopedix!

The Sikuli project recently switched to using Launchpad. I asked Tsung-Hsiang Chang to tell me more about the project.

Matthew: Your website says, “Sikuli is a visual technology to search and automate graphical user interfaces (GUI) using images (screenshots).” That sounds like it’s a general purpose screen-scraping solution. Is that right?

Tsung-Hsiang: Not exactly. Sikuli is not about extracting data from screen.

The current release of Sikuli is called Sikuli Script, which focuses on only automation using screenshots of GUI widgets.

We have another project called Sikuli Search, which queries a search engine using screenshots instead of keywords.

Although Sikuli Script is supposed to be able to “search” buttons or text on the screen, it isn’t good at scraping or analyzing information from screenshots yet.

Matthew: In your YouTube demo video, you show how you can write a Sikuli script that will open an app by name. Then, you can take a screen shot of one of the icons in that app and have Sikuli click it as part of the script. You even show how you just have to take a screen shot of the option you want from a drop-down list and Sikuli will select that option. That’s really cool but you say that Sikuli will even tolerate small changes in the icons you ask it to click. How does that work?

Tsung-Hsiang: Matching between a target image and the screen image is done by computing the normalized cross-correlation between the two images.

This is a standard technique in computer vision for finding patterns when variations are known to be small. This technique works incredibly well for matching desktop GUI patterns.

Matthew: Where do you think Sikuli will be most useful?

Tsung-Hsiang: Whenever the internal API of an application is not exposed. Lots of people have created their scripts to play the applications that were used to be very difficult to be automated, such as facebook (flash) games and testing android systems.

Matthew: Particularly on Mac OS X and Linux-based systems, where does Sikuli become a better option than standard shell scripting?

Tsung-Hsiang: If a command line interface is available, Sikuli may be not a good choice for a shell scripting guru. But sometimes you just can’t find command line tools or don’t want to learn complicated commands and parameters. In fact, the core of Sikuli is just a Jython library, so it can be mixed with other Python scripts or command line tools easily. Therefore, Sikuli can be an additional handy tool for command line gurus.

Besides, the primary goal of Sikuli is to help ordinary users who know nothing about command line tools and shell scripting to automate their tasks. We hope everyone can enjoy using computer efficiently.

Matthew: What’s next for Sikuli?

Tsung-Hsiang:Better, faster, more accurate.

We have a long list of planned improvements for Sikuli. Among the top of list are:

1. Social programming: the ability to share scripts and search scripts by visual patterns. For example, when a user takes a screen shot of a recycle bin, the user can search a database for all the other scripts written by other users that involve the image of a recycle bin.
2. Event-driven programming: the ability to register event handlers to handle visual events. For example, a user can define a function to pop up a warning message to handle the visual event that involves the appearance of the “low battery image”.
3. Face detection: the ability to find faces on the screen.
4. Recorder: the ability to record a sequence of clicking and typing operations and generate a visual script automatically.
5. Tutorial converter: the ability to convert an existing step-by-step instruction with screenshots into executable scripts.

Matthew: Why did you choose Launchpad?

Tsung-Hsiang:We were using Trac before moving to Launchpad. Trac is more developer-oriented, just like Github.

But what we really want is a user-oriented project hosting site. We want a place to report and discuss bugs, ask and answer questions, and also download and track the development of Sikuli.

We compared Github and Launchpad, and at last chose Launchpad over Github because Launchpad has almost everything we need, except a wiki for writing documents. But we already had a wiki in our Trac system, so this was not a big problem.

Matthew: Do you have any requests for the Launchpad community?

Tsung-Hsiang: It would be great if we can write documents on Launchpad. A wiki or something like EtherPad would be fantastic.

Matthew: Thanks very much and good luck with Sikuli!

Chat bots can be controversial. Apart from the fun to be had watching a friend carrying out an inadvertent Turing test, finding the right balance between useful information and annoyance seems to be one of the harder aspects of chatbotology.

I spoke to Jonathan Hitchcock, Michael Gorven and Stefano Rivera about their work on the Ibid chat bot.

Matthew: What are you doing with Ibid that’s different to other chat bots?

Ibid team: 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/her 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.

Matthew: Who do you see using Ibid?

Ibid team: 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…

Matthew: Are you hoping to attract developers to Ibid?

Ibid team: See here.

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.

Matthew: The project’s a fairly heavy user of Bazaar. What made you choose Bazaar over other VCSs?

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

Matthew: What aspect of Launchpad has most helped your development of Ibid?

Ibid team: 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.

Matthew: What would you most like to see improved or otherwise changed in Launchpad?

Ibid team: 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.

Matthew: Thanks Jonathan, Michael and Stefano!

Xibo is a free software signage system. I asked its lead developers, Alex Harrington and Dan Garner, about the project.

Matthew: So, does Xibo power the sorts of display we see in train stations and airports?

Alex and Dan: Yes, and in shops, post offices, schools, universities, colleges, churches or hotels. Anywhere there is a need to display information to the public or employees via a screen or projector. There’s over 150 Xibo installs worldwide that we know of, running 250 screens — however the Launchpad download stats suggest the actual install base is much larger.

Xibo allows organisations to build up collections of images, videos, RSS feeds, Flash, Embedded or External HTML and Microsoft Powerpoint presentations and combine them together into presentations which can then, in turn, be scheduled on to one or more of the displays attached to the Xibo system.

Matthew: We’re pretty used to seeing the Windows blue screen of death on public displays. In building Xibo, what have you done to ensure high uptime and to avoid rather public, embarrassing, error screens?

Alex and Dan: The current stable release of Xibo (1.0.3 at the time of writing) comprises a server application written in PHP and a client application written in C#. The client is written with resilience in mind, and is capable of operating over poor quality internet connections or running offline for periods of time.

The classic BSOD FAIL images from digital signs are often the underlying operating system crashing rather than the signage application itself. To that end, the client attempts to be as light as possible on system resources to keep the workload on the OS manageable – We have a production client running on a Via EPIA Fanless Mini-ITX system.

Looking forward, we have a new cross-platform (Linux/Win/Mac) client coming written in Python using the libavg engine which is guaranteed BSOD free! It uses OpenGL to do a lot of the screen rendering which opens up a lot of possibilities for cool-new-shiney-bits later on.

Matthew: What’s the competition for Xibo?

Alex and Dan: There’s huge competition in the digital signage market place, however we’re frequently told that our offering is better than a lot of the commercial signage applications people have used before. In terms of Open Source competition, there is the Concerto Signage Project who are based at the Rensselaer Polytehnic Institute and released under the GPL v2.

What we’re hoping to bring to the DS market place is a Free solution translated in to many languages with a thriving community of contributors working together to make Xibo the best it can be. An example is the new Xibo Layout Exchange. Here you can download contributed artwork for use in the Xibo system but eventually we plan to allow people to share whole bundles of content.

Matthew: Are you building a business around Xibo?

Alex and Dan: The Xibo application is Free and we have no plans to change that. There are many options available to monetize Xibo (content creation, hosting, support, custom development etc) but there’s nothing in the pipeline at the moment.

Matthew: Why did you select the AGPL 3 as Xibo’s licence?

Alex and Dan: Xibo is written with SaaS (Software as a Service) in mind. We’re very happy for businesses to take Xibo, rebrand it and sell it as a service to their customers, but the freedom needs to be two-way. We wanted a license that ensured that modifications these companies made would be accessible to the end user, for the greater good of the project. AGPLv3 offers us those things, while being compatible with a lot of existing library code.

Matthew: Is there a community of people interested in developing an open source signage system?

Alex and Dan: Xibo currently has two main developers. We’ve had code contributions from a few other people to date, but there’s a fair learning curve which presents a hurdle for prospective developers. We’re working towards a more modular architecture which will allow people to develop plugins to the server and client to extend it’s functionallity, which should lower the barrier to entry significantly.

There’s an active support community already in the Forum and in Launchpad Answers. We’re also taking art submissions for the Layout Exchange, and there is already a huge list of blueprints in Launchpad for future development, contributed by many people.

At least one of the developers is planning to be at LugRadio Live 2009 and Oggcamp in Wolverhampton later this year — just as a visitor, we aren’t exhibiting, but they’ll be suitably dressed so come over and say hello!

Matthew: Heh, see you there. So, why did you choose Launchpad?

Alex and Dan: We have used Sourceforge and Subversion before, but we wanted to use Bazaar for the RCS and Launchpad gave us Bazaar hosting and a good bug tracker. The translations support has been a huge bonus as has Blueprints and Answers. It rolls almost everything we needed in to one convenient package. It also acts as an OpenID provider so we can give the community secure access to edit the wiki and authenticate with the forum.

Matthew: What have you found particularly useful in Launchpad?

Alex and Dan: I think possibly the single most useful feature is merge request tracking – allowing us to fix bugs in individual branches and then queue the fixes up for merging later on. Answers has been great for doing user support – especially where there’s four or five of us helping someone it gives a good overview of which issues are outstanding, and a clear progression to a bug if needed. The bugtracker integration with bzr is great too for keeping track of where fixes went.

Matthew: What would you like to see added to Launchpad?

Alex and Dan: In the early days it would have helped us a lot if Launchpad had provided a wiki too. Now we’ve got our own system in place migrating over makes less sense though. I’d love to see a “Convert to Blueprint” button in Answers, as we get a lot of people making feature requests there.

Matthew: Thanks both!

I spotted this link in my Facebook news feed yesterday: MySQL at Facebook is a Launchpad project to which Facebook publishes its patches for MySQL.  There is also a Facebook note announcing the new project.

Surely Launchpad’s social networking credentials are in order now, and it’s just fun to point to a Facebook page on Launchpad rather than a Launchpad page on Facebook.

Zim is a desktop wiki that use both Launchpad and Bazaar. I asked Jaap Karssenberg, its founder and main developer, about the project.

Matthew: How does Zim compare with something like Tomboy?

Jaap: I really don’t know as I never used Tomboy for an extensive amount of time — it wasn’t around yet when I first started with Zim. From interface design I get the feeling Tomboy is designed as a replacement for sticky notes while Zim was designed as a replacement for an outliner. I think Zim is more tailored towards structuring notes. But Tomboy is moving fast as it has seemingly more developers and of course it gets traction from being included in Gnome.

Matthew: Do you think desktop wikis will eventually take over from larger applications, such as OpenOffice.org Writer, now that we’re increasingly producing documents for distribution online rather than via paper?

Jaap: I don’t think so, both serve different purposes. Wikis are very useful for storing information and building a knowledge base. Websites to some point have the same use cases, so a program like Zim can be used to build a website (in fact the Zim website itself is maintained in Zim). Office applications on the other hand are used when the focus is on layout and presentation of the data (e.g. writer and presenter) or do specialized calculations (e.g. calc). In my own workflow, I use Zim to collect notes about all my ongoing projects and this changes from day to day. When I need to produce a document these notes are the raw material, but I use an office application to produce a polished document. When such a document is finished itis published and does not change anymore.

Matthew: One of the great advantages of web-based wikis is collaboration. Does Zim have any features to enable collaboration?

Jaap: Zim has plugins to use version control like Bazaar or Subversion on the wiki data. My take on collaboration is that it can be done for a wiki the same way it can be done for code. Obviously you would need some betteer graphical interfaces for non-programmers to use it, but why not. This features doubles as backup mechanism and as synchronization. I especially like Bazaar for this due to it’s decentralized nature which fits a document concept real well.

Matthew: Are you looking for contributors?

Jaap: Always. Now it is just me on two nights a week and one or two irregular patch submitters. But we do have a lot of translators contributing already and
someone working on windows packages, which is very good. Still I feel the project is to much driven by a single developer.

Matthew: Why did you choose Launchpad and Bazaar?

Jaap: Bazaar was a logical choice as I was an avid Arch user before subversion and other modern version control systems arrived on the scene.

In the past I hosted projects on Sourceforge because I didn’t have my own hosting and needed centralized CVS etc. After some frustration I moved to Gnu Arch for version control and started hosting myself. But I started using Launchpad to allow translators to contribute and gradually discovered more useful features. I still have my own hosting contract for the website and put the bazaar branches there, but Launchpad is useful for contributers of other branches, translations and the bug tracker. Also running the mailing list there since my hosting provider doesn’t offer one. In short it spares me the work of setting up and maintaining those services myself.

Matthew: Thanks Jaap!

Last month we made a small change to the series page as a commitment to making a distinction between the driver for a project and the driver of a series. The drivers of a project have the power to make the decision of what features go into a release. But the driver of a series is special. Often a select number of individuals are delegated the awesome responsibility to define the intent of a series, manage all the milestones necessary to meet the goals, and to create the release. Series drivers are release managers.

When developers talk about the trusted persons who are making the release happen, they use the term release manager. While Launchpad recognised the role, it required the person also be a project owner, which is not always suitable for large projects. Release managers do not need the power to edit the project information, they need the power to edit the series information, create milestones, and release them. That is the power they now have.

A project owner can set a user, or a team as the series release manager from the series page. Project drivers also have the power to create a series; they have the power to start planning to be make themselves the release manger of the series they create.

What’s next

Distribution have release managers too, they have the same responsibilities as project release managers, but giving them power is a bit tricky. For distributions other than Ubuntu, release managers will be able to create series and milestones, and edit their details just as a project release manager.

Ubuntu must be handled as an exception; the gift of Soyuz and Translations is also a curse. Many special tasks must be performed before an Ubuntu series can be register a series in Launchpad. The release managers for an Ubuntu series will have more power to edit the series details and milestones.

Open Mind is an open source effort to create a database of common sense concepts. I asked Catherine Havasi, Rob Speer and Ken Arnold about the project and their use of Launchpad.

Matthew: Open Mind is almost the stuff of 1950s science fiction. You’re building a database of the ambient knowledge that we all take for granted, is that right?

Catherine: Yup. We’re looking to capture that intuition about the world that people have but computers and devices don’t. When you’re walking down the street you don’t need to worry about whether you will fall through the sidewalk. When you tell a friend you bought some groceries at the store, you know not to explain to them how money works. This kind of knowledge, knowledge about the relationships between everyday objects and knowledge about people feel about situations and goals, is critical for pretty much any AI task: from knowledge management for companies to robots interacting with the world around them.

Rob: And while we do our day-to-day work on the short-term applications of our system, we do keep the idealistic long term of AI in mind sometimes. It’s interesting that you should mention science fiction — one of the things that indirectly led to me joining the group was the goal of creating a computer system that could hold a conversation, perhaps like Mycroft in “The Moon Is a Harsh Mistress” or at least one of his stupider siblings. Using what I knew about natural language processing, I tried making a silly little discourse system or two, but I could see a clear barrier to them ever saying anything useful, and that was their lack of access to common sense.

So from there I changed my goal to the lower-level goal of getting this common sense knowledge into a computer in the first place, and joined the Open Mind Common Sense project.

Catherine: I’ve actually never been much of a science fictiony person — I tend to read mysteries. However, I’ve been a part of collaborative projects on the internet since the ’90s — before Wikipedia — and I always wondered how to harness the power of this sort of project for something like artificial intelligence.

Matthew: What uses do you envisage for this data, or is that not yet important?

Rob: Oh, it’s important. If we didn’t have applications we wouldn’t have funding.

Catherine: Recently we have worked on a lot of external applications. A few years ago, we developed an inference algorithm called AnalogySpace, which uses linear algebra techniques to find patterns in our common sense data. We then take those patterns and extend them to our entire data set — it’s a great noise-resistant way to do inference. We’ve also got a new technique called “blending” which lets us reason over other datasets with common sense added in. This is a good first step to the dream of using Open Mind as a sort of semantic glue in AI and in human-computer interaction.

Rob: We use these techniques to develop tools for our sponsors that can deal with natural language text according to its meaning (and not just what words it contains), and experimental user interfaces that adapt to what they think the user’s goals are.

Catherine: Our machine-learning toolkit, Divisi, is open source, so other people can build applications that use these techniques as well. We’re trying to make our community more open for others to use our stuff in a wide variety of applications — that’s one of the reasons we’re using Launchpad.

Matthew: How are you populating the database?

Rob: Currently we populate the database through our public website. Anybody who logs into that site can contribute new knowledge or vote on existing knowledge. We’re also working on improving that site (which is the openmind-commons project in Launchpad).

Catherine: In addition, we’re working on games you can play online which would help populate and refine the database.

Matthew: How do you programmatically show links between concepts?

Catherine: We have a semantic network called ConceptNet, which is constructed automatically from common sentence patterns in our contributed data.

Rob: When someone has told Open Mind a statement of the form “You can use an X to Y”, for example, this lets us add the semantic link “UsedFor(X, Y)”. ConceptNet has hundreds of thousands of these links. The combination of Divisi and ConceptNet can be quite powerful for representing semantics in a programmatic way.

Matthew: Where does Launchpad come in?

Rob: At this point, doing research on Open Mind requires working with a rather complex set of code. Our group’s Subversion repository wasn’t cutting it any more. It was also becoming very difficult to introduce the code to new people (whether they are new members of the group or collaborators). Launchpad is what we’re using to organize and distribute our code, and to build community around it.

Catherine: We’re especially interested in making what we do open and accessible to everyone. We can’t do this alone.

Matthew: Why did you choose Launchpad?

Rob: The first decision was which revision control system we should use. We needed something that would enable a distributed workflow.

Ken: …so that one person trying out their crazy idea for a new representation wouldn’t have to choose between breaking everyone else’s code and leaving it uncommitted for weeks.

Rob: It was important to make branching not painful, so we could release packages such as ConceptNet more often than the coincidental times that every part of the system was in a stable state.

Ken: We also wanted to open up our processes to the community; some external observers have mistakenly thought that the project was “dead” because they couldn’t see our internal work.

Rob: We first experimented with Git a bit. Not everyone could get their head around it. It felt like black magic. When you don’t completely understand the system, you can’t be sure it’s doing what you want. (I recognize the irony of this statement coming from a bunch of AI researchers.) After looking at other options, we settled on Bazaar, which fit into our workflow well and let us continue to use the Subversion idioms we were familiar with.

From there, it became a natural choice to set up a Launchpad account. Now we have a reliable place to look for all our code — as well as a lot of other tools for organizing our development, and a way of keeping our downstream users in the loop.

We intend to use Launchpad to distribute releases of ConceptNet and Divisi, track bugs, answer questions from users, and possibly even keep tabs on our documentation. (Currently, it seems a bit inconvenient to manage documentation using Launchpad. I’ve filed bug #334688 about a minor fix to Blueprints that would help, but it would really be nice to have a “Documentation” tab or something.)

Other aspects of Launchpad seem promising also — for example, we could make our translation project more high-profile if we figure out how to bring it from our own Rosetta installation over to Launchpad, and the “Mentoring” system seems like a good idea for giving projects to undergraduates, who often take a long time getting their bearings and figuring out what they want to do. (I should know.)

About Catherine, Rob and Ken

Catherine Havasi: I started as one of the co-founders of this project back in 1999 as an undergrad at MIT. I’ve been with it on and off for nearly ten years now. I took breaks to pursue other projects, but kept coming back to Open Mind because of the need for common sense. I’m currently finishing a PhD at Brandeis and will be soon starting a postdoc at MIT working full-time on Open Mind.

Rob Speer: I joined this project as an undergrad in 2005. I then made it the subject of my graduate research starting in 2006. After a couple of research ideas that didn’t really go anywhere, I worked on updating our knowledge collection site to make it start doing the things our papers said it should do, including asking relevant questions to expand its knowledge. I gave the site the working title “Open Mind Commons”, which stuck. I’m working toward a Ph.D. now, with a goal of improving knowledge collection across multiple languages.

Ken Arnold: I’m a second-year Master’s student at the Media Lab. My first task my first year here was to rewrite the Open Mind Commons site in Python/Django. I’ve been maintaining it ever since (enough to get fed up with it and pine for a rewrite — again!). I also have been helping with Divisi. I’m mainly working on my master’s thesis now, but somehow I keep finding myself working on this stuff.

Launchpad has a little known feature that is getting better. The product release finder is a process that runs everyday to locate new releases and import them to Launchpad. The process uses the series’ Release file pattern to locate files and import them to the appropriate release. It can even create releases for series. The process is robust and worth consideration if you want to upload large release files for your project.

The project owner and series release manager can set the Release URL pattern by the series edit page. The pattern is an ftp, http, or https URL with a glob (*) in the part of the file name that varies with each release for a series. For example:

http://widgets.dom/downloads/widget-2.*

describes all files that start with ‘widget-2.’. This might be the source for two different releases, widget-2.1.tar.gz and widget-2.2.3.tar.gz. The pattern will also match multiple files that belong to a single release, such as widget-2.1.tar.gz, widget-2.1.zip, widget-2.1.changelog.

Many projects choose to group files in series in a directory of their own, in which case the Release URL pattern would look something like:

http://widgets.dom/downloads/2.8/*

You can tell the product release finder to search multiple directories by using a glob for a directory. For example, if your project separates release files in directories for each OS then you can try

http://widgets.dom/downloads/*/widget-2.*

to scan downloads/ubuntu/widget-2.* and downloads/mac/widget-2.*.

Be careful to include the common part of the series in the URL, otherwise files from different series will be imported to the wrong series. Do not do something like:

http://widgets.dom/all-releases/*

because any file that looks like it has version information in it will be imported to one series.

In all cases, the product release finder will extract the version from the file name, and match it to a milestone name. It will create the milestone and release it if necessary. If a version cannot be extracted, the file is ignored.

The version numbers extracted from file names conform to Launchpad URL name rules. So if your release files have underscores or pluses in their version names, dashes will be substituted. Flavour information is also ignored in the file name. For example these file names yield these versions:


emacs-21.10.tar.gz => 21.10
vpnc-0.2-rm+zomb-pre1.tar.gz => 0.2-rm-zomb-pre1
warzone2100-2.0.5_rc1.tar.bz2 => 2.0.5-rc1
furiusisomount-0.8.1.0_de_DE.tar.gz => 0.8.1.0
glow-0.2.1_i386.deb => 0.2.1
Bazaar-1.16.1.win32-py2.5.exe => 1.16.1


What’s Next

The product release finder should notify owners and release managers when there are problems with imports. A lot of problems were fixed recently, but there are two issues we are still seeing in the logs that indicate the Release url pattern must be updated for some projects. The product release finder cannot access the server or directory in some of the URLs. There are also a few URLs that have no glob. They appear to be the URL to a single file, where a glob is needed so that the series can have many releases. If the product release finder does not find your files after a few days, review the Release url pattern and check the remote site to verify they are fine.

We will update the UI to make the Release url pattern more prominent, and easier to set for each series.