Matt Cohen from Clareity Consulting has produced a white paper “to generate discussion on possible MLS system future features by providing a big picture view of the changing relationship of real estate professionals with each other and with consumers, the changing relationship of local and regional MLSs with each other, and to illustrate, at least at a high level, how these changes may be either enabled or reflected technically in the MLS system of the future.”
Of course, this is right up our alley here at the FBS Blog, so I’m psyched I finally feel like I have something of substance to write about again. I’m going to focus on a couple of the ideas floated by Matt, because I think they are related and pose some of the most interesting possibilities. (I’m definitely stretching the ideas Matt proposed to my own needs, so don’t blame him for my crazy ideas. )
Widgets-Broker Tools-RETS
Three of the ideas Matt has put forward are widgets, broker tools and expanding use of RETS. I’m going to put my own spin on these ideas and try to relate them together as my contribution to the discussion.
I love the idea of MLS widgets and Matt’s are great examples. What I most like about widgets is that they often rely upon APIs (application programming interfaces) that allow for other developers to modify the tools or even create their own. For example, at the core of many widgets is the use of some sort of syndication (RSS/Atom) feed. The data is made available through the syndication feed and the widget re-purposes or figures out a clever way to display the data.
This type of creativity relates directly to developing better broker tools. If brokers (or their developers) had access to easy to use MLS APIs, they could develop all sorts of cool things. RETS, of course, is an API to the MLS system but it’s not terribly easy to use and is what Robbie Paplin would say is pretty close to the metal. In other words, RETS provides access to the data and images from the MLS system but pretty much everything else is up to the developer.
What I think is the future are RESTful MLS systems with excellent APIs that allow for all kinds of new ideas and developments by brokers to allow them to differentiate themselves. Brokers could then develop widgets and all sorts of other cool stuff. I think this also is the right vision for the NAR’s Gateway/TREC/[new name coming soon]. From Mark Lesswing’s comment on my last post about the Gateway, NAR can’t develop another public-facing search engine outside of Realtor.com, but I don’t think that would prohibit [New Name] from developing an API that would allow brokers to do that. Then imagine an API that not only does listing searches but also exposes through simple requests all sorts of statistics, graphs, heat maps and what otherwise would be complex data-warehousing type queries. Bloggers with a bit of coding skills would be in heaven, creating all sorts of market analyses for their customers and the public.
The key to all of this, however, is developing the API with an excellent permission model. The MLS aggregation is built on cooperation among competitors and the type of creative freedom fostered by a more open API needs to work within that model of cooperation. However, I’m convinced it can be done and that such tools would re-empower brokers to compete at an even higher level. I’m also convinced that fostering such competition is the role of the MLS and that cooperation is a necessary part of that competition.
Michael,
I’m glad you enjoyed the paper!
Regarding your comment, “For example, at the core of many widgets is the use of some sort of syndication (RSS/Atom) feed”. That’s exactly how the Konfabulator widgets (yes, before Yahoo! bought it) were built.
The problem with RSS is that it’s a pain to manage the feeds securely. While RSS will be the easy to use, ’standard’ answer to pushing data out of the MLS for these types of use for now, securing RSS is a near impossible task, and the more data one tries to expose the more problems there are. But, the risks can be mitigated. Being mindful not to expose too much in the feed, expiring the feeds in a reasonable timeframe (and having Widgets that handle that gracefully), not using integer feed identifiers … plenty of other tricks.
Long term, I hope RETS gets where it needs to go in order to accomplish the types of things that we are envisioning – versus having a separate API for each MLS provider.
I look forward to seeing you (and everyone else) at the NAR meetings next week!
Security, MLS Rules, ILD Litigation & and whatever other red tape road blocks aside, how cool would it be to instead of subscribing my prospect to autonotification emails, I was able to give them a specific link thet could add to their feedreader or RSS enabled web page. I’m guilty of making iGoogle my browser homepage. All my news and blog subscriptions are all delivered nicely to one place. Going even further with this concept, MLS content could be delivered to Facebook, Twitter, MySpace, etc. – all realtime. Endless possibilities here.
The content is all there. Unfortunately connecting to various vendors’ RETS servers is even less standard than the field naming. I would argue (ignorantly I admit) most of the obstacles are probably from within the industry and not due to the technical capabilities of the development community.
I’m very interested in this topic and anxiously await the possibilities that may come from a single source Archive.
Regards,
Seth
1:02 pm
Even better would be if some (or all) of these MLS widgets were available as open source apps for other brokers/agents to use, re-tool, etc. [new name coming soon] could be an aggregator/distributor of open source widgets. The collection development by MLS vendors, brokers, etc., could quickly (and exponentially) increase the web services and tools that real estate practitioners could use for the benefit of their clients.