Adapters first, then protocols

Continuing from last week, I’ve started working on a new open-source web app which I’m calling Hubert because it will be a hub for all your content (and “rhubarb” was already taken by none other than Tim Pope himself). The immediate motivation is to solve a dillemma I’ve faced for a while with my startup: there are a lot of potential features I could add that would complement my product, but I also want to avoid feature creep. Thus Hubert will make it convenient to release additional features as independent open-source plugins.

There is also a long-term motivation which I wrote about last month: I want to help make the web more extensible. Protocols are an important part of that, and Hubert takes an interesting approach here. Hubert will include authentication, a separate database for each user, a plugin system, and some schema conventions to help plugins work together. Plugins are responsible for moving data in and out of the current user’s database by whatever means necessary. That could include forms, APIs, feeds, email, etc.

For example, you could write a plugin to import your tweets from Twitter, another plugin to import your comments from Hacker News, and a third plugin to publish them all as an Atom feed of your short-form content.

In other words, Hubert makes it easy to apply the adapter pattern to web services. As long as a given service has an API (and sometimes even if it doesn’t), you can write plugins to import the data and expose it via a protocol. That will help solve one of the biggest challenges for protocols, the chicken-and-egg problem. There’s not much value in a protocol if nobody uses it yet.

Beeper is a great example of a startup using the same strategy. They’re making a messaging app that works with Whatsapp, iMessage, and a bunch of others… and it also works with Matrix.