RESO Manifesto

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.
Posted by MattL on Monday, September 14, 2009 at 9:32 PM
Tags:   ,
Categories:   Development
Actions:   E-mail | Permalink | Comments (2) | Comment RSSRSS comment feed

Glacier Wins Race Against RETS!

Today, it was formally(?) decided that RETS 1.7[.1] is about the best that can be achieved before the NAR's June 2009 deadline.  For the sake of edification, I'm including it here:

The integrity of data is a foundation to the orderly Real Estate market. The Real Estate Transaction Standards (RETS) provides a vendor neutral, secure approach to exchanging listing information between the broker and the MLS. In order to ensure that the goal of maintaining an orderly marketplace is maintained, and to further establish REALTOR® information as the trusted data source, MLS organizations owned and operated by associations of REALTOR® will comply with the RETS standards by June 2009, and keep current with the standard's new versions by implementing new releases of RETS within one year from ratification.

Now I'm going to do the posh thing and quote myself:

There is absolutely no chance RETS 2.0 will be done in fourteen months.

-- Matt Lavallee, RETS Assembly Meeting, Chicago, IL, August 9th, 2007

All I got then was hand-waving and chuckles...  Today, I may as well call myself The Nostradamus of RETS (although no one else will).

The ".1" incremental build is to correct some minor errata in the documentation of the specification.  This is truly pathetic:  RETS 2.0 was started in 2004.  How can anything be this slow?

For the sake of argument, let's look at the timelines of some other widely-known specs:

  1. HTML
    1. Version 1: 1993.
    2. Version 2: 1995.
    3. Version 3.2: 1997.
    4. Version 4.0: 1999.  Note: Considered "good enough" by most of universe.
    5. XHTML 1.0: 2002.
    6. [X]HTML 5.0: 2008.
  2. SQL:
    1. ANSI v1: 1986.
    2. FIPS 127-1: 1989.
    3. ANSI SQL2: 1992.
    4. ISO SQL3: 1996.
    5. SQL1999: 1999.
    6. SQL2003: 2003.
    7. SQL2006: 2006.
  3. Wi-Fi (IEEE 802.11)
    1. 802.11: 1997.
    2. 802.11a: 1999.
    3. 802.11b: 1999.
    4. 802.11g: 2003.
    5. 802.16 (WiMAX): 2005.

I understand the issues of timeline management and pragmatism, but come on... this isn't rocket surgery.

Here's how I understand our current timeline:

  • RETS 1.7.1 - Expected standards vote December 2008, adoption by June 2009
  • RETS 1.8 - Expected standards vote August 2009 (?)
  • RETS 1.9 - Expected standards vote... December 2010?
  • RETS 2.0 - Prediction: 2015+

This makes no sense.

Posted by MattL on Thursday, March 20, 2008 at 6:26 PM
Tags:   , ,
Categories:   Development
Actions:   E-mail | Permalink | Comments (5) | Comment RSSRSS comment feed