Why OpenEvents Is an Uphill Battle!

Marc Canter and I have been talking about OpenEvents for a long time.  Scott McMullan picked up on it.  A lot of people have offered to get involved.  But, no action has been taken. I know that tribe.net is interested in this in a major way.  Technorati is obviously interested.  Feedster, after their job search launch, has stated in public that they are interested in other verticals.  Besides bookmarks and photos, events are the natural next step. 

So, the interest is there.  But, where is the collaboration? What progress has been made?

There has been some.... Whether it is called OpenEvents or not, Tantek Çelik at technorati has made some progress defining a schema called hcal, based off of ical, that could be applied to the effort. Brian Dear, a big proponent of OpenEvents, has gotten involved in CalConnect, which has some industry heavyweights talking/doing calendar interop. Not sure if that is really what we are trying to do with OpenEvents, but it certainly is similar. Update: Also, Jeff Julian and cohorts have developed ESS. (Read the comments to see why ESS is superior to hcal... and why Jeff Julian is frustrated with the lack of action with OpenEvents.)

We've established an OpenEvents wiki, but I don't think wikis are particularly good at getting people interested in working together. They are good for helping people work together, but obviously the steam isn't rolling yet to make that happen.

So, I am writing a series of posts on why OpenEvents is an Uphill Battle. I am hoping that this rallies some people to think creatively, and also to realize that if we work together to make this happen, then we will all will benefit much quicker. 

So, The first reason that OpenEvents is an uphill battle is because the established players have no incentive to share data.  Actually, they have disincentives because there are so many businesses that depend on the data for their revenue stream.

Exhibit A

Event Crazy, historically a printed directory of events, powers weather.com. They also sell access to the directory online...

Now for $19.99 you can search the database for a one-time test. This search gives you access to the database in a unique way. You can now join as a Limited Member. That membership is for a fee of $19.99 and entitles the member to one of the following: One 2 hour search*, or 200 search results or 3 searches of your choice, whichever comes first.

This Limited Membership allows the user a taste of what searching the database is like. You can search the same database that the Premium Members search but you are limited by the pre-set restrictions.

They aren't well known by consumers, but they have a nice databse of clean content. But, providing free and open rss feeds of their events would basically destroy their business model, or atleast, I assume would be their immediate take on the matter.

Exhibit B
SocialWeb makes money from setting up and hosting web calendars. Except they aren't using xml to do it. In fact, if xml feeds were openly available, you wouldn't need someone like socialweb to skin a calendar to look like your website and host it on their servers. Nor do you need only 1 interface to enter your events, which is the basic model behind the business.  You may not have heard of SocialWeb, but I'd bet that they have the most complete event directory in a given area of the US.  They host many many calendars for large organizations in Central MA.

Exhibit C
Ticketmaster (InteractiveCorp)
They are the Amazon of ticket sales online, except they have no competitors. Why? Because for some stupid reason - their vendors agree to only sell through them.  In other words, Ticketmaster is the only place to buy tickets for the events/venues they sell ticets for. Talk about a monopoly. So, every consumer has to go to their website to get tickets.  They have no need to share the data. 

So, RSS is certainly not on their radar screen. They have no financial incentive to open it up and they don't have a history of doing things because consumers want it, if they can't make a buck off of it.

I know from good sources that their strategy is to develop a model for eliminating the ticket aftermarket industry (Aftermarket industry: consumers, scalpers (legitimate and not so legitimate)  usually buy blocks of tickets from ticketmaster or box offices and sell event tickets to the highest bidder.)  TicketMaster plans to build an auction model for ticket sales at their initial sale time.

Exhibit D
Evite
Evite is also part of the InterActiveCorp family. Their revenue is based on impressions and ppc advertising. In addition to the semi-private online rsvp pages that they host for people, they share a public event database with all of their sister sites: TicketMaster, TicketWeb, CitySearch. But, not with us. Why? Because we would build cooler applications on top of the data that would limit them from monetizing it with your eyeballs. John Foley, President of Evite, has stated their focus:

The business reason we are now in public events is to help expand our consumer brand and to bring user to Evite more frequently so that they will ultimately create more private events (our core). We have done a modest job of monetizing this traffic so we want to continue growing this core vertical.

He also said they plan on supporting RSS too:

We plan to add RSS and XML feed options (in and out) so that this becomes a robust destination to easily find and post all events.

but there hasn't been any thing that they've done yet.

------------------------------------------------------------------------------

I could go on and cite a lot of other sites/companies that have reasons why they wouldn't want OpenEvents to succeed.  I think the above examples exhibit the point.

In later posts, I'll be talking more about the technical challenges, who DOES want to be involved and why, other companies that I think should be involved that have little clue (mainly event registration companies) and some clever ways to let consumers leverage the information on the above sites to support OpenEvents. (There is no RIAA for the event business that will actually sue consumers.)

Comments

[Jeff Julian]

OpenEvents has issues because it is just a concept, no action. hCal is probably one of the most unorganized specs out there because you could easily break a parser using attribute values as your significant values instead of elements, just try parsing an iTunes playlist to see where I am coming from. ESS is here and starting to get some adoption. The main piece missing fromESS is the communication between event vendors, this is where OpenEvents can fill the gap. Pushing into iCal like hCal does is important, but not as important as fitting into syndication formats if we are aiming for aggregators to support them. ESS fits in Atom and RSS without any problems.