Michael Wurzer 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.