At last week’s semi-annual meeting of RESO (Real Estate Standards Organization, née RETS), I had the opportunity to participate in a panel session titled “RETS Issues, Challenges & Perceptions”; following what I thought was a great session, it seems that there is some continuing mischaracterization of my position (and message) that could use some clarity.

First, it is worthwhile to note that this panel arrived with the backdrop of “the COVE ultimatum” just days prior, in which roughly 20 large MLSes that comprise the “Cooperative Venture” (COVE) Group expressed concern that the standardization of Real Estate data has been inadequately progressive and, to that end, would be assigning its respective subject-matter experts to the task.  Ironically enough, my MLS is a member of the COVE group and, although I had some foreknowledge heading into this panel, that’s about where my involvement ends.

Second, the intent of the panel was to publicly mobilize some aspect of the effort and there was hope that confronting some of our collective shortcomings might help to that end.  I have well-documented my position(s) on this blog and have spoken to a number of the industry stakeholders about these issues, but (as David Harris put it so well) the whispering majority is currently overshadowed by the loud minority.

I’ve already summarized my position on what needs to happen with RESO, but here are my point-by-point criticisms with the Standards that RESO defines:

• RETS needs to be accepted for what it is: a Transactional system.  RETS was not designed for the task of synchronization (i.e., copying portions of the MLS in bulk) and another transport should be developed & advocated soon to address this need in the industry.  There are a seemingly-infinite number of third parties receiving MLS data and their number is only increasing every year… a standard method of copying data in a lightweight manner would benefit every MLS, vendor, and consumer of RE data.  This is especially needed for data-sharing efforts and VOW providers.  RETS is just too fat a protocol (that costs real money to transmit) and requires a number of “guesstimating” approaches to ensure consistency between source & client.
  
• RETS is ugly.
  Of course, no one in that room is going to admit to RETS being ugly… most people there are making their livelihood either supporting or consuming RETS, and many had a hand in its creation. Even David Harris was quick to point out a likely bias in the room.  However, the empirical evidence – well-documented in the RETS forums and especially the ezRETS and libRETS mailing lists – suggests that RETS is a very odd duck in a world of lots of standards.  Although I was chided during the session for saying that “DMQL was basically made up for RETS”, the reality is that RETS’ DMQL has little in common with its likely namesake “Data Mining Query Language” as publicly theorized in the early 90s.  Aside from some syntax similarities, RETS’ DMQL has no methods (as far as I’m aware) for interacting with metadata rules and constructs as part of a query, which was the basis for the “real” DMQL.  Beyond that, RETS uses a “just like HTTP” and a “just like TDS” payload to return “just like CSV” data, which is a lot of work… as Chris McKeever aptly described it in the session, “it’s like we’re building two bridges over the river instead of one” and, to paraphrase, just for the sake of saying that we made two neat, big bridges.  “Other” access methods (i.e., CSV files) shouldn’t be frowned upon just because they are simple – sometimes a simple approach is actually the most elegant.
  
• Data standardization is very important, but also very difficult.
  RETS has (and has had) over 500 defined “Standard Names” fields for over 5 years.  To date, not a single MLS (okay, maybe one, the one who submitted most of the list) has implemented them all.  This is because they include definitions of the data, which are generally not universal… Real Estate is still largely local:  What you call a “patio home” I call a “garden condo”, and what may be to building code in your jurisdiction may not here. My biggest concern is the loss of fidelity that will occur when we standardize.  One of the best examples of this was from another MLS’ aggregation effort, in which they listed commercial building heights in ranges (i.e., “15-20 stories”)… which means that no matter how you form the new universal “Building Height” field, you can’t say “15” or “20” without losing the original value’s meaning.  There are hundreds of examples of this in any MLS that has been around for more than a decade.  While I advocate the continued effort of mapping the universe of Real Estate data, I don’t think that it will come to fruition beyond its existing state any time soon.
  
• Data standardization is somewhat unnecessary.
  This is the one that sets most people off, but is the most important one “on the ground”.  Every market has mostly local Real Estate data consumers – local publications, local website providers, and local franchises and brokers that want/need access.  None of those particularly care about whether the MLS’ data conforms to any standard – they just care that it is easily digestible and readily available.  Data standardization matters most to national and regional efforts:  It is not until you leave a single definition of real estate data that you run into a problem.  For many data consumers, that just doesn’t happen.  For me, making the feeds timely and well-documented satisfies 99% of my data consumers.  They only implement their download system once, by and large, and don’t really need a quintupled implementation cost because Real Estate commands RETS.  It just doesn’t make sense.  It really shouldn’t be easier to set up an eBay store than to display your own listings on your own website, but it is, and I think that’s just wrong.

Hopefully, this helps clear the air and takes some of the biased reporting out of the mix.

A little over a year ago, following the last RESO meeting that I attended, I publicly called for the rescinding of “RETS 2.0” as voted for adoption by the General Assembly of the RETS Working Group two years earlier.  One thing that really struck a nerve in that conversation was that the governance model was being ignored.  In this particular case, I suspect that the Workgroup Chair didn’t want to identify with a consequence that would clearly upset one of his corporate superiors (the only vocal dissenter).  Overall, this exemplifies the conflict of interest that I feel is probably the leading hindrance to RESO today.  To understand RESO’s success and failings, you need to understand RESO.

What is a RESO?

RESO is (by hook or by crook) comprised of a mélange of representatives from the four major strata of Real Estate technologists:

• MLS Vendors
• Dependent-tools Vendors
• Industry Member Representatives (NAR, MLSes, Associations, etc.)
• Consultants

The MLS Vendors, by and large, own the greatest stake in implementation burden – they generally temper the ideal with feasibility.  They are the voice of limitation.

Dependent-tools Vendors (which I used to be) represent what I feel is the most important group: those parties that are most responsible for the actual carriage of the data.  They are the voice of application.

Industry Member Representatives (which I am now) are most concerned with the fidelity of the data and ensuring that the MLS Vendors have done what is needed for the Dependent-tools Vendors to be useful.  They are the voice of necessity.

Consultants run the gamut of serving all three of the aforementioned groups (sometimes simultaneously), usually either serving as an integrator between the parties and sometimes implementer for one or more.  Unfortunately, they notably benefit from a slow, arduous process and complexity that can be billed T&M.  They are, however, often the voice of mediation.

So What’s Wrong?

RESO (nee RETS) is painfully slow.  It’s the slowest standardization effort I’ve even heard of.  In 15 years, RETS has evolved about 1 years’ worth of technology and is dramatically behind current trends.  Most of the RETS spec mimics TDS (aka SQL) from the mid-80s, which itself has evolved substantially since.  Hell, in 2 years (that’s 730 days to you & me), the most anyone could agree on was clarification of existing language.  Seriously… two full years, and some aren’t even sure that they’ll make it.

RESO has its obstacles…

Obstacle #1: People

Each party involved in the standards wants as much utility as possible out of the least amount of effort, which is precisely where things get dicey. 

• MLSes do not want to expend the effort necessary to standardize the data, even though fidelity is their highest virtue.  Standardization means anti-localization, which is often a discriminating factor between MLS “A” and MLS “B” in a competing market.  Beyond that, change is hard: “2.5 baths is now 2.1? … Heresy.”
• MLS Vendors do not want to throw away ten years’ worth of cobweb-laden code and effort to change to something that may or may not be industry standard (read: an RFP requirement) for years to come.
• Dependent-tools Vendors are mostly upfront-capital companies that poured significant effort into “dealing with” RETS a few years ago and do not want to (or cannot afford to) have it change.  Others, of course, have their entire business staked in the standard as-is, so for them significant change is a death knell.
• Consultants… ahh, the consultants.  My heart really doesn’t bleed for them.  They tend to either denounce major change or drive it, because they need a paycheck next year and either one of those two will ensure it.

And, to top it off, all of these parties are volunteering whatever time and effort they can to contribute, in the interest of their personal stake.  This often means votes based on unread specifications, votes for friends, votes for things that shouldn’t even be voted upon, etc.  The reality is that most contributors do not have enough time to ensure that things are done right, just that something (anything) gets done.  I endorsed the Governance document, but no one ever followed it.

Obstacle #2: Politics

Most MLSes use consultants at some point, because they don’t have the staff to make long-range analytical (or even strategic) decisions.  All MLSes have an entrenched vendor (even if it is their own staff).  Most Vendors have worked with an MLS executive (or their colleagues) in the past.  Most consultants have experience or direct relationships with one or more Vendors, and have at some point worked for NAR.  All MLSes work with NAR on some level, and most must follow its policies.

Here’s how this plays out badly:

• A new Request for Change Proposal (RCP) is submitted to RESO to reword a substantially vague point of the standard that will settle an issue once and for all.  For the sake of argument, we’ll call it “RCP 7”.
• An MLS Vendor (“Omni MLS”) realizes that RCP 7 would require a significant rewrite of one-third of their code, affecting dozens of MLSes and requiring hundreds of man-hours to develop and test, even though none of their customers have complained about the issue.
• Omni MLS’ CEO calls a group of MLS executives in his client base, telling them that The Change will increase their annual fees next year if they don’t contact NAR to complain or send their representative to RESO to vote against it.
• The local MLS executive, not really caring about the effect of the change, doesn’t want the MLS fees increased on their watch, so they send an email to a few of their friends (also MLS executives) and ensure that their noble Consultant feels equally about RCP 7.
• The Noble Consultant then contacts all of his customers to inform them of the dramatic consequences of RCP 7, ensuring certain doom (and likely dozens more billable hours) should it pass.
• RCP 7 is shot down before it ever gets serious review.

Now, mind you, this was a hypothetical case and on a grand scale of conspiracy, but similar conflicts occur every day in RESO at a much lower level, and I think often without realizing that they may be tainting whatever purity is left in the community effort.

Obstacle #3: Technology

The Real Estate Transaction Standard (RETS) was made to support (get this) TRANSACTIONS.  That is not how RETS is used today and is absolutely not what most people want:  Most people (The 95% Use-Case) just want to synchronize their local database of listings with the originator (usually the MLS)… maybe with some criteria, although that itself is a fringe case.

What we need is a synchronization standard.

Obstacle #4: Reality

Regardless of what whiz-bang, idealized standard is created by the group, everyone must implement it in order to make it valuable.  This is why #1 and #2 are tolerated, accepted, and sometimes extolled as a “concerted effort.”

So Now What

I’m going to keep my proposal simple as this post has already gone on for far too long.

1. Convert RESO to an organization funded at least 50% by its membership and products in a short timeframe (18 months?). Right now, even Board membership in RESO is a cheap badge that anyone can pick up, regardless of contribution (monetary or otherwise).  This leaves the standard far less exposed to grassroots subterfuge and ensures that those members that remain bear genuine interest.
2. Contract the Board to just five members.  Their role is actually fairly limited in scope and there are so many chefs (and interests) right now that they’re making things worse.
3. Make the Executive Director have a stake in the standards’ progress:  Set some measurable goals to denote success and point out when they’re falling short.  Make them solely accountable for the smooth operation of the organization and put a significant portion of their compensation on the line.
4. Whittle the workgroups down to two and require new workgroups to submit a business plan for review before creating them.  Workgroup #1 is RETS legacy, Workgroup #2 is RESO Sync.
5. Business, outreach, education, etc., are all secondary to the technology at this point.  NAR has guaranteed that The Voice exists for this Standards body, so stop wasting brokers’ time.  They really don’t have to care right now and don’t actually understand most of what you’re saying.  We can market when we have something marketable.