Conversations about the MLS industry, creating software, and employee ownership.

I attended a presentation from Dale Ross and Marty Frame to a variety of MLS and public records software vendors last Sunday at the NAR Convention in San Diego.  Here are a few points I took away from the Q&A session:

• No Focus on Data Standards for MLSs.  In response to my question as to whether RPR would be promoting a data standard for MLSs, Marty said something like they didn’t want to be a RETS enforcer.  I’m not completely sure what that means but if Marty intended for RPR to help with data standards, he likely would have said so.  Instead he said it wasn’t part of their plan and they’re primarily focused on about 120 data fields or so.
• No Help For MLSs With Overlapping Market Disorder or Those Who Want to Data Share.  In response to my question as to whether RPR would be helping MLSs resolve overlapping market disorder in their area by serving as a data exchange/repository, Marty said no, that wasn’t in the plan either.  Of course, users can come to the RPR interface and see data from participating MLSs but there isn’t a plan for an API (RETS or otherwise) to allow MLSs to retrieve aggregate data even if the MLSs in the area agree to such an exchange.
• No Authoritative Record.  In response to my question as to whether RPR will be establishing an authoritative record from the various sources of data (public records, MLS, loans, etc.), Marty said no.  RPR will present the various sources of data side by side but they won’t try to reconcile them.  I think this fact makes their claim of being a “property-centric” system a bit off target.  My understanding of property-centric systems is that they do, in fact, establish an authoritative record from the many sources — they combine the best data to provide a long-term repository of property information, instead of just displaying disparate data side-by-side.  The scenario I posed was as follows:
  • Agent Smith creates a new listing on January 1 and auto-pops the listing from the RPR tax record, and then corrects the square footage, which is off by a significant amount.
  • Agent Smith’s listing expires March 30.
  • Agent Jones lists the same property on April 1 and again auto-populates the listing from the tax record.  Agent Jones will again have to correct the square footage coming from the RPR public records because there isn’t a base or authoritative record available from RPR.
• Application Programming Interfaces (APIs) — (Note: An API is a way two systems (such as RPR and the MLS or a broker back-office system) can talk to each other.)
  • Marty said there will be an API for the public records and MLSs will be able to pull the public records into their own system.  MLS systems also will be able to link to the PDF market and listing reports (though they won’t be available in HTML, just PDF).
  • RPR hopes MLSs will help RPR with authentication by using single sign-on (SSO) standards, though they’ll adapt to whatever the MLS will provide.
  • There will not be an API for any of the third-party licensed data (including listings), just the public records.  If you want to see the other data, you must login to RPR.
  • API documentation should become available in the next 30 days or so.

There were questions from other vendors as well about the APIs and the business model, but the above were the highlights for me.  I walked away from the meeting thinking they were missing a lot of the potential for how a system like RPR could help MLSs and their broker and agent members.  Helping MLSs improve data quality, data standards, and data sharing are all key benefits not being addressed by RPR. Hopefully this will change over the coming months as MLSs negotiate licenses with RPR and require that these issues be part of the deal.

——————————————————————–

Related and recent posts RPR by others:

Brian Larson — Report of RPRs Birth Is An Exaggeration

Rob Hahn — No More Drama and Hype: Known Facts on RPR

——————————————————————–

P.S.  Can I please request that all NAR conventions from here on out be in San Diego?  What a perfect location, with a great convention center, great hotels nearby, awesome restaurants, entertainment, and, of course, the views and weather!

I’m pleased as punch to announce that FBS is integrating DocuSign into our flexmls Forms product.  Here’s the press release from DocuSign.  We expect the new features to be available to our Forms users by the end of the year, if not earlier.

If you’re not familiar with DocuSign, it is a web-based system for getting electronic signatures on your contracts.  But, it’s not just about electronic signatures.  DocuSign has some very powerful workflow functions built into it that just make it easier to get deals signed.

I first started looking into DocuSign when I saw agents I follow on Twitter say great things about it. (that link is more recent, but I couldn’t find the older ones that piqued my interest).  Once I started working with Dave Thorpe at DocuSign, one of the first steps in moving ahead was signing an NDA.  Of course, Dave sent me the contract using DocuSign and the agreement was reviewed, signed and archived in matter of minutes.  I was convinced from that moment that this would be a great addition to our flexmls Forms offering.

Right now, we’re busy mapping out the signature and initial locations on all our forms so they’ll be ready to go at launch.  Sending the documents out will happen right through the flexmls Forms system just as you’re able to email them now.  The difference will be that your customer will now get to review and sign the contracts using DocuSign and we’ll be able to monitor and update the status of the transaction right through your flexmls Forms folders.  This way, you’ll always know who has signed and who is left to sign the documents to finalize them.

We hope our Forms customers are excited about this as we are.  Let us know if you have any questions.

I wrote yesterday why NAR’s RPR won’t mean the death of the MLS.  Today, I want to ask some more important questions regarding the terms on which MLSs will allow NAR’s RPR to use (license) their MLS data.  I suspect NAR will be presenting a lot of MLSs with some sort of terms of use over the next few weeks and months, promising their members “free” access to the RPR in exchange for their MLS data.  There is some basic information on a fact sheet NAR posted about RPR (thanks, Kevin McQueen!) but the fact sheet doesn’t provide many details.

If I were negotiating this terms of use, I’d want to know answers to at least the following questions:

• Will the MLS data be re-licensed (re-packaged) by RPR and, if so, on what terms? This is the same basic question asked by Brian Larson asked in his recent post about the possible business model for RPR.  There is some early speculation that RPR’s deal with LPS for the parcel database includes giving LPS the exclusive right to re-license the MLS data.  Clearly, much more detailed information about re-licensing of the MLS data is needed.
• If the primary business model for RPR is re-licensing of the data, what does the MLS get in return? Is there a revenue opportunity for the MLS here?
• What sort of access to the RPR database does the MLS get? More specifically, will there be an API (application programming interface) for the MLS to integrate RPR data into the MLS system?  In other words, will the data flow be a two-way street or is RPR expecting it to only flow one way?  As I mentioned in my post yesterday, an easy to use method for the MLS system to retrieve the universal property ID is critical in listing maintenance.  But also important is the ability for the MLS system to bring back data from the RPR during listing maintenance, into listing detail reports, CMA creation, and other places.  NAR claims the RPR isn’t trying to replace the MLS, and one proof of this will be whether RPR includes APIs that will open up the data to the MLS system.  Two clarifying points here: (1) I’m not talking about opening the system to the public, but rather to the MLS system already being used and paid for by the agents and brokers; and (2) agents don’t need yet another system to log into to do their work, what they need is all the data to be available to them wherever they login (MLS system, RPR, etc.).  If RPR silos the data and makes it accessible only through their web interface, that’s a sure sign that NARs real intent is to replace the local MLS.  Accordingly, having a strong API should be a key term required for access to the MLS data.  In other words, it’s not a one-way street, the data should flow both directions.
• What are the real costs of the RPR? The magic word “free” is being bandied about a lot regarding RPR, but clearly it’s going to cost a lot of money and that money has to come from somewhere.  It’s important for the MLS to understand the costs of creating the RPR as a member benefit, because those costs will drive the business down the road.
• What will MLS members be able to do with the MLS information once it’s in RPR? In this regard, the fact sheet put out by NAR currently states: “There will be no public access to the RPR™, and the database and its data cannot be shared through consumer websites or listing presentations.”  That seems like an odd restriction and contrary to the statement earlier in the fact sheet that RPR “will be exclusive to members of NAR, who can share its information with their clients.”  Again, clearly more information is needed here.  This point also is why being able to bring the data back into the MLS system is important, because that is a system where the agents and brokers have clearly defined rules about what they can do with the data and the local brokers and agents make the rules.
• What happens if the deal sours down the road? Can the MLS get its data back?  Will RPR have commingled or transformed it to a point that it is no longer retrievable?

I understand a press release will be coming later today, but my guess is that the press release will be more hype than details.  The real facts will come in the proposed license agreements NAR tries to get MLSs to sign.  I think a system like RPR has a ton of opportunity for MLSs to make their members more efficient, but the key to leveraging the RPR opportunity will be in the license agreement for the MLS data.  RPR won’t amount to much without the MLS data and so that value should be recognized by the brokers and agents in the MLSs providing the data.

Update: Here’s NAR’s press release for November 9.  Not much different from the fact sheet except that CAR is going to partner with RPR with their ZipForms and Relay transaction management systems.  I’ll probably post more about that later.

Last Friday, following the burst of rumors that NAR had purchased Cyberhomes to power its RPR (Real Property Resource) and  HouseLogic web sites, the cries of the death of the MLS have risen to a fevered pitch again.

Rob Hahn, founder of 7DS Associates, thinks MLSs need to be very concerned with RPR and that a war is coming between NAR and the MLSs.  Brian Boero, from 1000Watt, doesn’t use such stark language, but he, too, thinks RPR will be a “a significant shock to a system that needs it” and asks: “Will MLSs play ball?”  He then answers with uncertainty: “As with most things in this space, the outlook is unclear.”  As an agent and one of the members of the original NAR PAG that envisioned the RPR, Jim Duncan is excited by the possibilities of RPR and HouseLogic and asks some important questions, namely what will agents be able to do with the information and who will have access to it.  The comments to all three of the above posts focus in on the impact the RPR will have on MLSs.

Though I was initially going to wait for an official press release from NAR (I hear it’s coming Monday), the more I thought about it, the more it seemed appropriate to weigh in on some of the speculation about RPR’s impact on MLSs.  I’ve already written at length about both the death of the MLS and RPR (RPR or Ready?).  In fact, most of the posts on the FBS Blog have been about these same issues in one way or another.

For example, I wrote some time ago that MLS is about more than technology.  This crucial point — that MLSs enable competitors to cooperate — is where I think Rob Hahn goes awry in his post.  He assumes that the MLS is only about the software.  What Rob ignores is that the software merely implements a wide variety of business rules that were carefully crafted by the local MLS or Association in order to create the compromise that makes it possible for the competitors to aggregate their data in the first instance.  NAR understands this, though, which is why they’ve been saying that RPR is not intended to replace local MLSs and, to my knowledge, has no listing input or maintenance functions so far.  In other words, the data is going to come from the local MLSs and not brokers or agents directly.

NAR and its leadership knows how “local” MLSs really are.  The local Boards and Associations and their respective MLSs (some independently owned, others not) are run by brokers and agents competing in the local marker and who have cooperated together just enough to make aggregation of their listings possible.  Often, this cooperation results in a complex set of business rules.

This set of business rules is the heart of the MLS today and so talking about the death of the MLS means killing these local business rules in favor of business rules established by RPR.  NAR knows this is a tough challenge, and so they’re just not going there, yet.  As this issue (death of the local MLS business rules) is debated again in the coming years, I believe there are few core questions:

• Is cooperation at the local level (agents and brokers deciding how they want to work together) necessary to aggregate the listing data or is aggregating listings now a given (a commodity, if you will) such that it can more easily be established at a national level?
• Is a single national MLS a good thing?
• Are there alternatives?

If you’ve read my earlier posts on these topics, you already know that my answers to these questions are:

• Yes – local control is needed;
• No – monopolies are not good; and
• Yes – standards are the alternative.

All three of these issues are related to each other.  FBS serves over 100 different MLSs across the country.  We know how important our system is to our customers and that it’s important to have lots of cool features.  More importantly, however, we believe responding to each of our MLS customers’ needs is what differentiates us over the long term.  We provide value by implementing their business rules, which makes the cooperation central to MLS possible.  Responding to these local needs is critical.

At the same time, the lack of standards created by local control of MLSs causes pain for many bigger brokers, franchises and others dealing with multiple MLSs.  This is where standards could be of great benefit.  Creating standards, however, is very, very difficult, especially at a national level.  Of course, one way to create a national standard is to create one MLS.  The problem with that result, however, is that you create a monopoly.  I’m pretty sure what online real estate needs is more competition, not less.  Standards enable competition, monopolies do not.

Accordingly, I applaud NAR buying Cyberhomes and using it to power RPR.  As an MLS vendor, FBS loves competition and looks forward to learning more about RPR and how their tools can help our customers.  We’d love to see RPR help create a universal property ID.  We’d love to leverage data from RPR if it can in any way help improve accuracy of the MLS data.  We’re excited about the possibilities of RPR but also strongly believe that those possibilities should not be used to create a monopoly that squelches competition in the MLS software space.

For those of you interested in these issues, join me at the NAR meetings next week in San Diego for the Future of MLS panel.  The RPR and related issues should be a hot topic.

Here are some tips from Adam Bosworth (who worked on ODBC, XML, etc.) on how to build a successful standard:

1.  Keep the standard as simple and stupid as possible.

2.  The data being exchanged should be human readable and easy to understand.

3.  Standards work best when they are focused.

4.  Standards should have precise encodings.

5.  Always have real implementations that are actually being used as part of design of any standard.

6.  Put in hysteresis for the unexpected.

7.  Make the spec itself free, public on the web, and include lots of simple examples on the web site.

To all those involved in trying to create RETS data (not transport) standards, how many of these have we followed?

(h/t Joel Spolsky)