I'm a committer on the Apache Enterprise Social Messaging Environment (Apache ESME). At least I think that's what it stands for today. We sort of looked at SAP's approach where the acronym for a product changes every year or so and we maybe went a little too far in the opposite direction, refusing to change the acronym even when we need to change the name - teen vampire romances be damned!

In any case, ESME takes a lot of its cues from Twitter, but with a focus on the needs of the enterprise. To that affect, we built in Scala (which runs on the JVM and provides easy integration with Java code), used David Pollack's super-scalable Lift framework and an actor-model designed by David, then we added features like message pools (which allow for groups of people to exchange non-public messages), the ability to post more than 140 characters, and the ability to follow not just people, but also tags and conversations.

Maybe that gives you the idea, maybe not. You can always go try it for yourself athttp://esmecloudserverapache.dickhirsch.staxapps.net/ or help out with the project - we can use help in many areas.

We've managed to do lots of other cool stuff in the context of ESME, but what I want to write a little bit about is what I think we still have ahead of us.

Distributed Twitter and federation

Talk of a non-centralized version of Twitter sprung up in earnest a couple of years ago with a post by Dave Winer, the inventor of RSS. The initial context was Twitter's regular downtime as it struggled with scaling, but the larger context quickly because the concern that we can't trust a single company to properly steward an enormous piece of communication infrastructure. The concern is basically about the Facebook-ification of Twitter. GigaOm has a prettydecent overview of the current state of the discussion.

From an enterprise perspective, this concern is even more motivated. Most enterprises still tend towards on-premise software by default and it is unclear if a messaging service is well-suited to a SaaS deployment option. Some companies, like Yammer (pure SaaS) and Status.net (open source - SaaS and on-premise options), are working on delivering a Twitter-like solution for the enterprise, but we aren't there yet.

Key requirements for a distributed Twitter service:

Inter-operable Federation - Status.net has worked to introduce the OStatus standard, and this is an excellent start. However, the inter-operability of this protocol is relatively untested. I'd like to see if we can make this work for ESME, but it is going to take some additions to the protocol to manage pooled messages, for example.
Follow any feed - Friendfeed had this capability, and ESME provides it in a bit of a different manner through our actions (though actions - Vassil's brainchild - do far more than this). I sometimes think of this capability as light-weight, or one-way, federation.
Real-time updates from federated data source - Not only do we need to be able to follow feeds, we need to get updates from those feeds nearly instantly. PubSubHubbub (PuSH) is probably the most wide-spread solution here, and it is the solution that OStatus uses. But PuSH has weaknesses around authorization of subscriptions to private feeds, and here it would need to be rolled up with another standard like OAuth.
Updates available as (protected) feeds.

Status.net seems to be the most on-the-ball with regards to these requirements, but there is a need for variety and for a tool like ESME that was built with business users in mind.

Real activities and objects as social objects

One important ability for an socially-oriented messaging system is that it makes business objects into first-class social objects. This is what John Tropea is getting at when he talks about the ability to follow conversations and tags. These objects should be first-class members of the messaging environment, supporting following and real-time updates.

We should also be able to integrate real business objects and business activities into the system as first-class objects. "I want to follow this customer", should be a desire that we support. Currently we offer a couple of ways to do this:

Bring an activity into the ESME system as a message, either via the API or through an action that pulls an RSS feed. This message (or rather, the conversation around it) is a first-class messaging object in ESME, so if people want to see responses to an action, then they can follow the action. For example, I have actions set up onhttp://esmecloudserverapache.dickhirsch.staxapps.net/ that pull my new Twitter messages and newly created ESME Jira tickets in to my timeline.
Bring an object into the ESME system as a tag, again using the API or an action. The tag then acts as the object that we can follow. We currently allow this as well, and it was used heavily by Sig Rinde in his prototype during his quite awesome prototype integration of the object-oriented business process engine (OOBPE?) Thingamy with ESME. But we could stand to have some more functionality for extracting tags and metadata from RSS feeds, allowing us to use this tag-as-object approach in a richer way.

We're currently thinking about ways to make our system more extensible and further enable the representation of business activities and objects as first-class objects in the messaging environment. We'd certainly like all the help we can get thinking about this topic.

Easier integration into other software products and environments

The capability that actions give us to pull in RSS and Atom feeds is really important. It means that ESME can integrate with systems that were not designed with ESME, or even social messaging in general, in mind. In turn, we need to improve our APIs to allow easier integration of ESME into other tools. Part of this involves doing things like providing RSS and Atom representations of timeline, probably via open standards like the Activity Streams standard.

On the somewhat more complex side, in will probably involve supporting other existing and emerging standards like allowing use of LDAP for authorization, LDAP groups for automatic pool creation, OpenSocial, PubSubHubbub for push-based feeds, using OAuth in our API, providing more semantic and linked information about data via our API, and supporting actions pulling Atom from OAuth-protected resources.

When I put it like that, it sounds like a lot, but it also sounds really exciting!

So, I'm sure I've missed a lot here, but these are just my thoughts about directions I'd like to see ESME move over the next few releases. Got ideas about where the project should go? We'd love to hear them :-)