The September 2011 RETS meetings were held last week, with a lot of forward momentum in terms of a data dictionary, potentially new API approaches and new governance model for RESO.
The most important movement was the recommendation to the Board to form a workgroup to extend the existing standard names approved for RETS 1.8 into a data dictionary, including data types and enumerations. The first meeting of this new workgroup likely will be just before the NAR Annual meetings in California. Because they’ll be starting from the standard names document, this workgroup is going to move fast and so hopefully we’ll see the first version of the dictionary approved in the next 3-5 months. The need for a data dictionary is legion, and it’s incredibly heartening to see this moving forward based on the already existing standard names document.
All other work will stem from the development of the dictionary. New payloads likely will be developed, but only once the dictionary lays the foundation. The data dictionary will provide the RESO workgroups and the real estate community as a whole with an incredibly valuable way to inform MLSs and consumers of data best practices for implementing different field types and categories. The process for adopting new field definitions also will be very streamlined to ensure that the dictionary can respond to new market developments, such as we’ve seen over the last few years with green fields and short sales. Instead of every MLS developing their own approach because there is no guidance, the data dictionary will give them much needed guidance.
Another interesting conversation at the meetings was regarding the development of RESTful APIs. I was part of a panel moderated by Mark Lesswing called The Great API Debate, along with Sergio del Rio, Steve Clarke, and Scott Petronis from OnBoard.
I was first up and reviewed our new flexmls API, which is focused on delivering data real-time without the need for the data to be replicated in other databases. In addition to providing efficient and secure real-time access to the MLS data, one of the the main reasons we developed this API was to help us promote adoption of RESO data standards to all of our MLS customers. We built the API based on the current standard names document and are working on harmonizing those standards across all of our customers.
At the same time, we’re using the flexmls API to build new products such as our real-time flexmls WordPress plugin and our new touch-enabled mobile flexmls site, which took some major strides just the other day when we added support for flexmls customer portals and IDX. By building new products on the real-time flexmls API, our customers will see the benefits of data standards and ask for more. User demand for more standards will increase even more as the API gets used by third party developers. Our theory essentially is to create demand for standards by making it easy for developers to create cool products agents, brokers and MLSs will want to improve their business. We’ve been calling it the “field of dreams” or “build it and they will come” approach and we’re excited about the results we’ve seen so far.
Sergio del Rio represented MRIS and reviewed how their new RESTful API (called MRIS Data Services) provides real-time data access as well. There are a lot of similarities between the approach MRIS took with their API and the approach we took, including use of OData query formats and delivery of data in JSON (and also XML) format. It’s great to see other developers seeing the benefits of RESTful APIs.
Steve Clarke and Scott Petronis also discussed several important points about how these new API developments could help promote data standards and provide benefits for real-time data access. Steve made an important point that as the new APIs develop, the RESO community needs to be careful to try to provide guidance to help avoid fragmentation.
To that end, Mark Lesswing made a presentation later in the day where he reviewed RESTful APIs and sought feedback from the community regarding whether they saw this approach as a viable for future consideration by RESO. I was very encouraged that support seemed widespread for a RESTful approach generally and use of OData for query formats, JSON and XML for payload format, and possibly oAuth as well. One of the main points Mark made was that it made sense to not reinvent the wheel when there are good tools already available and proven.
The last, but certainly not least, of the developments reported at the meetings are related to governance of RESO. Chair of the RESO Board, Rebecca Jensen, reported that by-laws have been filed with the State of Illinois for incorpration of RESO. In the new by-laws, the RESO Board of Directors firmly asserted control over governance of the standard.
Without as much as a peep from the community as a whole, the Board now has sole authority to create workgroups and approve the standard and really anything else that goes on with RETS and RESO. There will be no more votes from the community at large, even, from what I can tell, for the Board itself.
Rather, input from the community is garnered through workgroup participation. This change could appear controversial, but, in reality, the workgroups have been where the real work is done anyway and it’s a very rare change proposal that makes it out of a workgroup that isn’t approved by the community and so this shift of control to the Board likely won’t change that and it could have the benefit of making the process move faster as we won’t have to wait for the semi-annual meetings to approve changes.
Another potentially controversial issue that didn’t seem to raise too many hackles was the institution of a new RESO membership fee. The primary benefit of paying the RESO membership fee is that a representative from your firm can then be considered for the Board of Directors, as Board members are appointed based upon membership class. If the Board is successful raising funds from the largest vendors and MLSs, there won’t be many seats available because 12 of the 16 seats are automatically appointed to NAR (2 seats), vendors with over $50 million in revenue (4 seats), and MLSs with over 50,000 members (6 seats). Today, there probably aren’t that many large vendors or MLSs/Associations, but the Board nonetheless will be weighted strongly toward the biggest as those who are appointed from the biggest vendors and MLSs get to appoint the remaining seats.
Whereas I don’t see too much difficulty with the Board taking control of approving the standard because the workgroups are where the action is in defining the standard anyway, I’m a bit more concerned with the lack of input from the community on who gets on the Board. There appear to be few checks and balances in place with this new structure. The biggest check and balance, of course, is that the community can cease to participate, but that might be too little, too late. I have no problem with the largest MLSs and vendors having Board seats, but I’d like to see more clear broker involvement and a stronger role for the community in providing oversight to the Board through some participation in the election process.
In conclusion, despite my long-term concerns about the lack of checks and balances for the Board, congratulations are due to the RESO Board as a whole but especially Chair Rebecca Jensen, NAR CTO Mark Lesswing, and RESO Executive Director Travis Wright for the progress they’ve made in moving RESO in the direction of data standards and to creating a clearer and stronger organization structure.