incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Engbrecht <erik.engbre...@gmail.com>
Subject Re: The current state of ESME
Date Mon, 02 Mar 2009 15:16:51 GMT
>
> I catch myself equating the desire to *contribute* to ESME as a
> function of the desire to *use* ESME. In order for more people to use
> ESME, it's necessary (but not sufficient) more people to know about
> it.


Yes, absolutely.


> Another thing we should avoid is branding ESME as strictly for the
> Enterprise. It might have been beneficial before the preparation for
> the SAP Demo Jams, but now there's a much wider user base. There might
> be users who could be put off if they feel anyone not in the
> enterprise category cannot benefit fully from what ESME has to offer.


As a potential enterprise customer, this sentiment worries me greatly.  In
my mind the singular killer feature of ESME is the enterprise focus.  Things
that detract from that, like emphasizing OpenId for authentication rather
than more enterprisey methods like Kerberos or (**shudder**) NTLM.

I say stick to your roots and make sure you do it well.  Right now the
business case for microblogging in the enterprise is clear as mud.  I think
it could be made if it was effectively blended into existing infrastructure
in a way that's likely to produce value added communication rather than the
sometimes amusing line noise produced by services like Twitter.

On Mon, Mar 2, 2009 at 8:46 AM, Vassil Dichev <vdichev@apache.org> wrote:

> Still more thoughts coming up, but first the response to Bertrand.
>
> > Note that I know very little about the overall ESME context, feel free
> > to slap me with a trout if there's too much sillyness below ;-)
>
> Actually these are very valid points. We would benefit enormously from
> this type of input, so feel free to add more, noone could slap you
> with anything :)
>
> > You mentioned http://laconi.ca/trac/ - If I go there I immediately see
> > a boilerplate description of what that is and does:
>
> Also a very apt comparison, since I think laconi.ca is the most
> similar project to what ESME does.
>
> > What's the scope of ESME? Server, client, RESTful API? How does ESME
> > compare with and play with other microblogging platforms? Can you say
> > that in 100 words on the ESME website?
>
> If we can't explain something in simple terms, we don't understand it
> ourselves either :)
>
> > That's problem 1 I think: making it easy for potential users and
> > contributors to decide whether ESME is for them. That should not take
> > more than 10 minutes, people are lazy.
>
> I would even strive for 2 minutes. It's an easy enough concept.
>
> I catch myself equating the desire to *contribute* to ESME as a
> function of the desire to *use* ESME. In order for more people to use
> ESME, it's necessary (but not sufficient) more people to know about
> it.
>
> I think one of the best steps for ESME to catch on was to become
> open-source, and also becoming part of Apache. I also knew it wouldn't
> be an easy transition as it loses its umbilical cord to SAP.
>
> Once we have a functional release, we should announce it- but not any
> earlier. If people don't like what we see, they might not look back. I
> intend to notify e.g. the folks from the Java Posse podcast so they
> can announce the release of ESME in their next podcast, but if they do
> it now, it would probably do more harm than good.
>
> Another thing we should avoid is branding ESME as strictly for the
> Enterprise. It might have been beneficial before the preparation for
> the SAP Demo Jams, but now there's a much wider user base. There might
> be users who could be put off if they feel anyone not in the
> enterprise category cannot benefit fully from what ESME has to offer.
>
> I think ESME is different than laconi.ca, in that it focuses on
> scalability in a way few other microblogging platforms have (Twitter
> is using Scala to solve their performance problems). Using actions
> currently it is also much easier for the power user to reroute and
> process messages, which would otherwise need setup of additional tools
> (if they exist at all).
>
> ESME needs a killer feature. There are  a couple of scenarios where
> ESME could be seen as superior. Example: there was a case in my
> current job where our distributed team was having daily instant
> messaging sessions. The problem was anyone who wasn't there couldn't
> see what the others have been discussing, so we had to save the chat
> sessions, and it wasn't very straightforward to make them available
> publically. This was a good case for me to propose Yammer. We tried
> it, and when the team lead noticed the message shows in the others'
> timeline in more than 10-15 seconds, he rejected Yammer as not fast
> enough. This was a perfect opportunity to promote ESME! Due to comet,
> it updates instantly.
>
> Another thing ESME is better in, is notifications for different
> server-side events. For instance, Darren has contributed code to send
> a status to ESME when an exception comes to the SAP log viewer
> service. It could easily send messages when a build finishes. It would
> also be ideal for a front end of different system event notifications
> a-la Nagios.
>
> There are a lot of use cases which capitalize on ESME's real-time
> responsiveness: problem solving when supporting a technical issue,
> development discussions, or just plain chat.
>
> Finally, I'm certainly not worried about Scala being popular or not.
> If Twitter has an interest in Scala, then we aren't likely to be on
> the wrong track. If anything, it lets us be more productive with less
> developers ;-) For instance, once I knew how I wanted to implement the
> Twitter-compatible RESTful API, I managed to put a new feature by
> coding for half an hour every couple of days. Also, remember the speed
> with which David managed to assemble a working ESME for the Demo Jam
> (though I must attribute this to David's experience and great vision
> as well).
>
> Vassil
>



-- 
http://erikengbrecht.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message