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.
The Gateway/TREC/TBD discussions are heating up again, sort of. Re-visiting the topic seems timely with the latest iteration of the NAR PAG report recently “released” and the trimester RETS meetings in Philadelphia next week.
My take is this: The NAR may well have the cart before the horse. So far, the NAR’s PAG seems to have focused on defining a “system” for aggregation but the TREC documents avoid the fundamental question of the terms of use on which brokers and MLSs will agree to share data. Here’s a quote from the document:
Then, further down, the document says:
These two statements seem inconsistent, because an MLS or broker submitting data to TREC will be required to license that data to all other TREC subscribers and such a license is a transfer of intellectual property rights. This apparent conflict is just one of many key questions, however, regarding the terms of use for the data submitted to TREC.
The document also stresses that the data will not be publicly accessible. Yet, at the same time, the “Statement of Inevitability” at the beginning of the document lists the proliferation of “[c]onsumer-focused real estate websites” as one of the reasons TREC is necessary — to keep Realtors “at the center of the real estate transaction.” At this level, not only does the concept feel like the cart before the horse but also like trying to put the horse back in the barn, just as they’ve started to run free.
This brings us back to the core issue: What are the terms of use on which brokers and MLSs will allow others to use their data? TREC tries answering this question only in the most narrow terms (broker/agent to broker/agent, in private, behind a walled garden) but the web insists on asking a much bigger question involving not just brokers and agents but consumers and third-party aggregators and so many others. As the links above show, brokers are already answering these questions for themselves by sending listing data here and there but not yet everywhere, which creates the very real likelihood that TREC will be too late to the party.
Of course, NAR is hamstrung in fostering the necessary dialog about usage of listing data on the web by the DOJ litigation. Also, in spite of the insistence that it isn’t any such thing, TREC very well may be the first gingerly step in the direction of addressing the question of how listing data should be used on the web. Rather than being the cart before the horse, an actual implementation of a national aggregation may be exactly what is needed — and all NAR can do for now — to incubate the discussion. For this, I applaud the work of the PAG.
Like the NAR PAG, I believe this is a defining moment for real estate data on the web and I encourage the NAR to consider how it can re-visit the big issue of sharing listing data on the web. That’s what the consumers want, not having to go through an agent to access the data. For example, one of the best uses of TREC data would be for an agent or broker to create a publicly accessible web site to engage their customers. Yet, that seems off the table. I’m pretty certain the NAR PAG would have loved to create a more sweeping plan involving both public and private access, but felt it wasn’t possible. The result is the proposal focuses on implementing a closed system instead of creating a foundation on which others can build systems.
What I think would be useful is for NAR to foster a discussion among brokers, agents and MLSs regarding the Open Web and what that means for real estate. This same discussion is occurring right now with regard to the web as a whole, and Brad Neuberg recently suggested: “If we take the long term view, how can we give the web an open enough infrastructure to evolve over time and meet each generations needs, while maintaining its structure enough to actually mean something and stay true to its promise, similar to the U.S. Constitution?” He emphasizes that this isn’t so much about specific technology but rather the general philosophy: “if we define the Open Web in terms of [specific] technologies, then we risk losing sight of what makes the web special and being able to have the intellectual nimbleness to evolve the infrastructure of the web. . . . We will be fighting yesterdays battle while allowing new, proprietary technologies to take over if we focus on technologies rather than philosophy.”
This is where I think NAR can provide leadership, by fostering discussions around how aggregated real estate data can be made most valuable in an ever changing world. IDX has been and remains one of the best tools available to agents and brokers for engage with customers on the web today. Is it time to revisit the IDX policies of old? Are the same questions and controversies that arose over VOWs in the DOJ litigation still a concern? Or is it now possible to redefine IDX in a way to make it even more useful? These questions are left unanswered by TREC, for good reason no doubt, but I think they remain the core questions.
If you’re interested in listing portability, you may want to keep an eye on dataportability.org.
DataPortability – Connect, Control, Share, Remix from Smashcut Media on Vimeo
The press release last week from Zillow, Yahoo! and Trulia certainly created enough confusion, especially this part regarding the Real Estate Standards Organization:
The companies participating in the new standard will work in close collaboration with the Real Estate Standards Organization to ensure that the data specification interoperates with the Real Estate Transaction Standard (RETS).
I saw and approved this language before the press release went out, so I take responsibility for some of the confusion. The words that seem to have caused the most difficulty are “new standard” and “interoperates.” For example, apparently focusing on “interoperates” and reading it broadly, TechCrunch picked up on the press release after talking with Lloyd Frink and erroneously reported that these companies are adopting RETS. Later, David Gibbons from Zillow corrected them, but not before many people contacted me thinking these organizations had adopted RETS. In contrast, apparently focusing on the words “new standard”, Inman News seemed to swing the other way and proclaimed that these companies were “pioneering” the standards. In a bizarre twist, Realtor Magazine even focused on the word “new” and omitted any reference at all to the RETS.
The truth, of course, is somewhere between these two extremes. The language in the original press release, though too vague in retrospect, accurately reflects the “in between” state of the relationship of these companies to the RESO. As I’ve said to others, we’re dating but not married. My open letter created an opportunity for discussions but these guys have let me know during our early discussions that they were already working together on a common feed format and that my open letter was timely but coincidental to their plans. They’ve all said they are open to working with the RESO but the discussions have not yet gotten detailed regarding what that actually means.
Last Thursday at the Inman Connect conference in New York, Matt Lavallee (Chair of the RESO Query Work Group and Development Director for MLSPIN) and I met with the press release group and also a representative from Google, and we all concluded that getting together to try to put together a common payload for syndication made sense. These meetings have yet to be scheduled but they are anticipated to be in the next month at Yahoo!’s headquarters.
Both during and following the meeting, I tried to seek more specifics regarding what “interoperates” means but the discussions just weren’t far enough along to allow anyone to say. Again, we’re dating but not formally married, making the nature of the relationship uncertain. The feeling in the group was to get a standard document together and then we can figure out later what it all means.
After the meetings, I sent a few e-mails to the group urging them to move this work into a formal RESO Work Group for syndication so that we can all have a common understanding regarding the process for developing and evolving the standard for the long term. A loose collaboration is fine to bootstrap a process and get it going with a small number of companies, but, sooner rather than later, having agreement on the process for developing the standard is very important to keeping the group together. This is especially true as the number of companies adopting and relying on the standard grows so that everyone knows what to expect over the long term. The RESO has developed these processes already (PDF), they are very open and community-driven, and make certain that the intellectual property (PDF) created will be freely available and not hindered by any patents or other IP claims from the participating companies or antitrust (PDF) concerns.
I’ve committed to the group that the RESO intends to move very rapidly on this and, to that end, the RESO Board voted today to charter a new Syndication Work Group. The charter document for this new work group will be posted on RETS.org by the end of the week, and I’m very hopeful Google, Yahoo!, Trulia, Zillow, and other syndication recipients decide to participate in this work group. This is a great opportunity for all of us to work together to create a win-win-win for brokers, agents and the industry as a whole.
I’m not going to offer a purported answer now, I’m just asking questions, specifically: Why is real estate immune from the ideas being debated in other industries? Doc Searls wrote some time ago:
To really take advantage of open source, he explained, you need to value ubiquity in your marketplace at least as much as you value scarcity in your product portfolio. In fact, your smartest move may be to take some of the products you’re selling, and make them ubiquitous by moving them from proprietary/closed to open/public domain — literally, from scarcity to ubiquity:
This same theme is picked up by Alex Iksold at Read/Write Web in an analysis of how Google’s OpenSocial initiative could impact FaceBook:
Open Social paves a way to a potentially new kind of web culture. In that culture, companies would recognize that users are entitled to their information. It should be importable and exportable. It should not be locked in.
Why is real estate sales through the MLS excepted from this general idea? I’m not asking this rhetorically, I honestly don’t know and wonder about the answer. Interestingly enough, the idea that data should not be locked in applies just as much to companies like Zillow as it does to MLSs, maybe more so. So, what do you think is the answer? Where is MLS data on the curve towards ubiquity and commoditization?
Mark Flavin has an interesting post today about the usefulness of wireless access to MLS systems. We’re going to review some statistics regarding usage of flexmls wireless access, and will post on that analysis when we’re done.
In the meantime, the idea that demand can sometimes outstrip usefulness made me think about RSS feeds and the MLS system. What are the best use cases you can think of for RSS feeds and the MLS system? Hot sheets, perhaps? An RSS reader doesn’t seem to be the best way to review new or changed listings. A replacement for automatic e-mail updates? Again, readers seem ill-suited to this purpose. Anyway, what are your thoughts on how RSS could be made useful in MLS systems?
