Michael Wurzer I had a fun Twitter discussion the other night with Sam DeBord, Bill Fowler, Jon Breault, and Victor Lund regarding Sam’s advocacy on behalf of brokers for “one feed” for IDX, VOW, and back-office needs instead of separate feeds. Though Twitter doesn’t do a good job of threading the discussion, Sam’s tweet about a post on his personal blog was the start of the discussion.
In his post, Sam outlines that there’s an alphabet soup of related proposals: The abandoned LEAP and the new ADS (both from CMLS), REAL (from Zillow), and the original NOW (from a broker work group). In his post, Sam proposes to set all those aside for now and focus on the idea of “one feed.” This focus was well stated by Jon Breault:
This was echoed as important because apparently there are some MLSs that only provide broker back office feeds via FTP, which we all agreed is ridiculous, even though there doesn’t appear to be hard data about how many MLSs actually do this.
Much later that night, when my typical insomnia reared its head, I started thinking about some of the practical aspects of this idea of “one feed.” More specifically, I wondered what the actual language of the mandate for “one feed” would say. For example, would it enable a broker to insist on one FTP feed? Or would brokers be able to insist on one RETS feed, even though the industry is trying to encourage adoption of the RESO Web API?
This train of thought led me to thinking whether the mandate would restrict the “one feed” to the RESO Web API. If the demand from brokers for one feed is critical to innovation as advocated, this could be exactly the incentive brokers and their developers need to migrate to the Web API, which they’ve largely resisted so far. As I mentioned on Twitter, spurring adoption of the Web API through the proposed benefits of “one feed” would be awesome. What wouldn’t be awesome is having a mandate for one RETS feed or one FTP feed.
Even with one Web API feed, I wonder if, in the current state of the standard, that’s actually a benefit to brokers. Currently in the standard, there’s no option that I’m aware of to delineate in a single feed what fields are allowed for multiple roles. The fact that the rules and permissions for each role are different is the primary reason there is a different feed for each role today (i.e., IDX, VOW, back office). Without independent feeds, how will a broker/developer know the permissions and rules for each role? Will a single feed that doesn’t make those distinctions increase or complicate the compliance efforts from MLSs and broker vendors?
Sam points out in his post that RESO is working on adding role permissions to a single feed, but that isn’t the case today, so is it really more efficient and will brokers really benefit from one feed today? I’m skeptical of those benefits but, leaving that skepticism aside, what is clear to me is that the best chance for a “one feed” mandate to move the industry forward is if it is focused only on the Web API and excludes FTP and RETS.
Sam educated me about NAR process and indicates that any mandate proposal will be published and subject to review for about three months, so I look forward to seeing the actual proposal and encourage all of you to watch for it as well so we can continue the discussion.
P.S. As I mentioned on Twitter, I’m skeptical of the benefits of just focusing on “one feed” as advocated, because the alphabet soup of proposals include restricting the ability for individual MLSs to specify their own license terms. I agree there are opportunities for more standard IDX, VOW, or other license terms, but such standards should not trample on the rights of MLSs to craft individual pricing for specific use cases, whether that is volume pricing, derivative works, or other cases. The more limited proposal for “one feed” skirts this issue but that just seems to leave the hard work for later with very limited, if any, benefits today.