Unsolicited Advice for the New RESO Board
On the eve of my trip to Scottsdale for the December RETS meeting, which will be my last as the current RESO Board Chair, I offer the following unsolicited advice to the new RESO Board:
1. Elect a Chair from the Technical Side. The RESO Board is split into business and technical sides, and I am on the business side. However, all the action is on the technical side, which, along with chairs of the technical workgroups, constitutes the Standards Committee. The Standards Committee is responsible for defining the road map for the standard. Given that the Standards Committee defines the road map, I recommend that the Chair be elected from the technical side or, at the least, should attend the Standards Committee meetings to stay in the loop on the work going on there.
2. Get Past June 2009 Sooner Than Later. In November 2007, the NAR MLS Policy Committee recommended a rule that all MLSs become RETS compliant by June 2009. Though this policy has the potential to do great things for the industry and RETS over the long run, the initial impact has been to divert attention into getting the few MLSs not already RETS compliant up to speed. This has required cleaning up version 1.7 to version 1.7.2, rewriting the compliance checking tools, and working on a bunch of procedural issues for compliance. Though important, none of these efforts directly advance the standard.
3. It’s All About The Data! I’ve been attending RETS meetings since 1999, I believe, but for several years I had been less involved until the April 2007 meeting in Austin. I went to that meeting with the express purpose of advocating for stronger data standards. The ideat that now (then) is the time to push for greater data standards nationwide seemed to gain some traction from advocacy from me and folks like Frank Tadman and Peter Spicer (then of REInfoLink) and Gregg Petch (then of MRIS). We established a rigorous schedule for the payloads workgroup and proceeded to meet nearly every month for the next year or so. A lot of work was done in those meetings, and then the NAR MLS policy for June 2009 compliance was announced and that work essentially ground to a halt. Yet, a stronger data standard is what will deliver the promise of RETS.
Related aside: One of the biggest challenges with the current payloads is that they are expressed in schema, which, for all practical purposes, is not accessible to lay people. Since Austin, I’ve been advocating for a RETSipedia that would allow the entire community to work together to define the standard names (fields) for RETS but we haven’t gotten there, largely because schema doesn’t play well when flattened out. If we’re going to get anywhere with data standards, I think the community should strongly consider starting with defining the data dictionary first (start simple and use spreadsheets, like most of the regionals have been doing across the country) and then pick the best technology for representing that dictionary. This also directly relates to the Syndication standard, which should be a key priority for the new Board.
4. Define and Promote a Strategic Road Map. For as long as I can remember, the “marketing” workgroup has met at each in-person meeting to discuss ways of promoting RETS. At each of these meetings, I say the same thing: “Marketing is more than promotion and you can’t do effective promotion until you’ve defined your product and your market.” What’s been missing for many years is a clear strategic road map. In my view, the marketing workgroup and the business side of the Board should be helping to define the customers to be served by RETS and the needs of those customers. Once defined, the promotion of that road map will be much easier. Here’s my suggested road map:
- Adopt and promote broad and deep data standards to:
- Reduce or eliminate duplicate entry of listings;
- Promote easier data sharing among MLSs; and
- Reduce the costs brokers and others face from dealing with disparate IDX data feeds.
- Adopt AtomRED as the transport for syndication to make it more cost effective for all parties involved to have timely and accurate data on all web sites, instead of the out-of-date mess that exists today.
- Establish and promote a uniform property ID system to foster linkage of property data on the web.
5. RETS.org or RESO.org. This is both a small and a big deal. Currently, the communication channels in the community are not very good. The RETS.org web site could be made a lot better by: (a) putting the standards documents in HTML (instead of PDF) and breaking them down sufficiently to enable people to link to, comment on, discuss and make suggestions for specific provisions of the standard; (b) create and show detailed version histories; (c) make it easier and clearer for Board members and workgroup chairs to communicate to the community at large regarding what is happening; and (d) fix the forum RSS feeds so they send out all updates instead of just the initial post. One of the successes of the RESO community over the last year has been to establish firmer rules regarding how and when change proposals are to be made. However, making the standards more accessible on the web would go a long way to helping everyone meet these new rules. Unless the community wants to make Google documents or groups the final home for rets.org, better functionality needs to be built into the rets.org site to allow for the best communication. This need also extends most urgently to the need to finalize broader and deeper data standards. The RETSipedia remains a good idea that could generate a lot of valuable content and energy in the broader real estate community.
I wish I could have accomplished some or all of the above while I was on the RESO Board, but, alas, it was not to be. I’ve been privileged to serve as Chair of the initial RESO Board and look forward to continuing to participate in the community as a non-Board member to promote and advance the standard, which is critical to the growth of our industry.
I look forward to seeing many of you readers in Scottsdale!