Hyping Short-Term Tech Under The Gauzy Lights of Vegas

Apr 20, 2017  |  Michael Wurzer

Zillow is undoubtedly providing a good party for lots of MLS leaders in Las Vegas this week, including many of our customers. I love a good party and I applaud Zillow for reaching out to MLSs to educate them on their solutions.

What I’m not so fond of is the short-term technical direction being pushed by Zillow simply because they’ve decided they’re in a race with Upstream. Look, I get it, Zillow doesn’t want to see a repeat of the Listhub debacle and so countering Upstream is important to them.

To do that, Zillow bought Bridge Interactive, which has a product called Compose that Bridge created many years ago to solve a problem in Atlanta where there are two MLSs requiring duplicate entry of listings. Zillow’s thinking is that because Compose is being used in Atlanta and a few other markets, they can use it to beat Upstream to the punch and corner the broker listing management market.

But this strategy is a purely short-term play that benefits only Zillow and is a really bad idea for everyone else involved, especially MLS vendors like FBS. The reason is that Bridge’s Compose product uses an old version of RETS update that soon will be replaced by the new RESO Web API update. Implementing both the old and the new update method at this stage simply wastes valuable time and energy and distracts everyone from the long-term solution.

I was super-excited to read the other day that Upstream is willing to work with MLSs to implement a robust sync API. This is the right approach and RESO is actively developing such an update standard. Zillow, Upstream (via RPR), FBS, Black Knight, Docusign, Redfin, and several other key vendors are all involved in creating this new specification for all vendors instead of just catering to one.

Again, I understand Zillow’s desire to beat Upstream to the punch. But we owe a duty to our customers and the industry not to get caught up in all the hype like the press release Zillow issued today saying that, among others, Georgia MLS and First MLS in Atlanta are using Compose to enter listings, which I’m pretty sure has been the case for about ten years. That’s old news, not a new development.

The reality is that there is no emergency here, no fire in the theater, and no reason to shove a short-term solution down the industry’s throat. I’m looking forward to seeing Zillow, Upstream, and many others at the RESO meetings next week in Austin so we can move forward with a long-term solution that benefits our entire industry.

 

 

 

 

8 Responses to “Hyping Short-Term Tech Under The Gauzy Lights of Vegas”

  1. victor lund says:

    Great article – and you are spot on with the press release. Bridge did not really publish their customer list, but when I looked at the announcement from Zillow, I had the same impression. They published a list of existing Bridge customers and made it seem like they are new customers. I think that will backfire on them because many agents and brokers will contact their MLS to find out about it.

    I know that a number of MLSs on that list have, like GMLS and First MLS – used Bridge for years. I think that the only other customer for Compose is NorthstarMLS in Minnesota. Most of the others on the list only use the Bridge RETS server – and do not use the add-edit features of Compose.

    You are spot on with the Upstream comments – Upstream is using modern transport processes and is committed to supporting industry standards and RESO.

    • Victor Lund says:

      So…… if you ever wondered – a lot of people read this blog, but do not necessary comment. As it turns out, many Bridge customers have agreed to take the offer of RETS Update via Bridge Interactive. Its not live yet – so as Mr. Wurzer suggests – the best is yet to come.

      The big news here is that leading MLSs have agreed to open the MLS – which will provide a new requrrement for MLS Vendors like Flex to consider opening their data base to remote listing input. This is very complex, and as Mike suggests – open APIs are the way to go. Bad news is that no MLS system publishes an open API today – they are all closed systems.

      RESO is pushing forward on a specification for open APIs – but some folks believe that it will not be a reality for about 3 years.

      In the interim, – we will push forward. To be certain, the days of an open MLS that will communicate both ways with other technology applications is our near term future. The closed system MLS has received the bad news from the doctor that they either responsibly accept input or perish.

      Will they listen?

      Hope everyone is enjoying the hospitality in Las Vegas –

  2. Paul Stusiak says:

    I’m the chair of the RETS Workgroup and the co-chair of the Transport Workgroup of RESO. Michael knows this, but those of you reading this blog may not. So I speak with some authority when I talk about standards and update (add-edit) in specific.

    I won’t speak to the news release, only to the current state of the ability to enter records into databases from the perspective of the listing.

    Anyone who has ever written a data entry application has had to deal with business rules. They are messy. Really messy. Technical people simply try to implement those rules, defined by the members of an MLS or Association or state legislators or other well meaning people trying to run a business and operate fairly. If you’re lucky, the clever people writing the data store will have figured out how to expose those rules to allow third parties to write applications against those rules and store records into that database in a way that doesn’t frustrate the end user. Historically, this meant speaking generally, the vendor did not expose those rules or even allow third parties to store data into their databases.

    Several years ago, we worked very hard for many years to come up with a way to provide this functionality – a way to create and update listings with exposed business rule that would allow third parties, in a standard way, to do this. This has been part of the RETS standard for 6 years and a precursor version has been around for longer. It is not currently a requirement that a vendor implement this, but several vendors have included it into their MLS offering. These vendors include MRIS/BrightMLS, Corelogic Matrix, Corelogic Fusion and Bridge Interactive. This list is not exhaustive – I’m pretty sure that there are other vendors who have implemented RETS 1.8 Update too. It works, it has gone through several iterations and corrected problems with the earlier versions. Battle proven if you will. It includes business rules and layout hints – what might go with other fields based on the knowledge of the MLS staff. Both the business rules and layout hints can be ignored by third party developers, but they are meant to make it less painful for the person entering the records to get it right. There will always be some business rules that cannot be exposed – relationships that exist in the database itself or certain types of complex relationship, but having enough to solve the majority of the data entry errors is a big step forward.

    So what’s wrong with this? Why doesn’t everyone use this right now? Demand. People weren’t demanding that the Create/Update functionality was open. Now they are.

    The RETS 1 standard is fairly heavy – you’ve got to know some things about software development and networking to build systems and applications that use those systems. As well, it has a perception problem that it doesn’t look ‘shiny’. So RETS 1 tends to be more expensive to create software because people expect to get paid well and it is ‘old’. Since there is some confusion, RETS uses the same transport processes as Web API and other update systems. The protocols are different. The use of metadata is different. The availability of supporting libraries is different. I personally am finding that I have to write a lot more code for Web API that is ‘plumbing’ than I ever did for RETS.

    The Web API is an attempt to resolve some of those problems. We’ve written the search portion of the standard. We’re working on writing the update portion of the standard. However, as our friends at Upstream are no doubt enjoying at this very minute, implementing and exposing business rules is hard.

    The first version of Web API create/update will not have business rules built into the standard. This means that the vendors will implement those rules on the back-end system. We are debating to determine if we should just use the full OData create/update methods or expose a set of simplified actions to do one thing – for example ‘Change a list price’, ‘Add a photo’. The trade-offs are many and we take this very seriously. Simple actions mean that it would be easy to develop simple applications to do one thing right. Full OData create/update is complex.

    Which is the best course to follow? Which course gets us to the completed standard document? Which course leads to the best rate of adoption? Serious questions that require serious thought. Which we are doing.

    It should go without mention that every one of us working on this has a full time job that isn’t writing standards. We depend on the support of companies like yours – so thank you Michael for all the time you’ve committed to the standard.

    I appreciate that, for the first time, the folks working on Upstream showed up to our last Web API in-person workgroup meeting. I’d like them to have been there in the beginning and to continue to contribute. I appreciate that Zillow has committed time and resources to working on both RETS and Web API and have done so for many years. I appreciate the other vendors and MLS staff who have and continue to contribute. The volunteer nature of this, committing staff and resources to this work means that we, in RESO, move more slowly than a business with time to market concerns and capital commitments to make that happen.

    I understand your desire to avoid mis-investment. I understand there are many other forces at work here. As I’ve been saying for many, many years, we’ve got update right now and it works.

    It is my opinion that we may not see the Web API as a published standard before 2018. I also suspect that other, competing add/edit systems will be in that same timeframe.

    If your customers are asking, you should have answers. Maybe one of those answers should be “It’s in development right now.”

  3. Michael,

    Thanks for again being the voice of reason and responsibility in our industry. While our industry needs to evolve quickly to stay relevant, we also need to be careful about short-term decisions that will affect the long-term viability of our MLS community and the brokers they serve.

    I, like you, am very interested to see the latest set of innovations to be revealed at the RESO conference next week. I solidly believe that companies that leverage the solid, collaborative foundation built by RESO will be here long after others.

    It’s a very exciting time to be part of the real estate data community right now, but it’s also a time when every MLS organization needs to carefully evaluate the way it stewards the future of data collection and distribution.

    Finally, every MLS needs to remember that they are responsible for providing RESO-certified data feeds via the Web API to be in compliance with NAR MLS policy. To date about 2/3 of the market has complied to the request, but we have a tong way to go to help brokers truly utilize RESO to its best advantage. It’s the responsibility of everyone in the industry to find ways to make it easier for technology companies and brokers to innovate and differentiate themselves with standardized real estate information.

    Can’t wait to see everyone this week at the RESO conference. Should be thought-provoking and fun as always!

  4. Paul Stusiak says:

    I’ve confirmed that RETS Update is part of Paragon and is in production and in active use today.

  5. Michael Wurzer says:

    Thanks for all the comments, everyone.

    Paul, the main point of the post is simple: We need one standard to be required, not two ,three, or, heaven forbid, more. This is the job of standards bodies like RESO and I think it’s a reasonable request. If the industry wants RETS 1.x Update to be that standard, great, then let’s close the Web API Update workgroup and focus our energy on RETS 1.x Update or at least make clear to everyone that 1.x is the update that will be required and Web API will be optional. I wrote the post above stating that 1.x Update is short-term, because the direction from RESO to date has been to push forward with update via the Web API. As you know, RETS 1.x Update has never been required, always optional. The question on the table is what update standard should be required for implementation. I agree with RESO that the Web API is the best long-term direction and that we should focus our energy on implementing that. What I advocate for even more, however, is that we have a single update be required. RESO can have all the optional standards it wants, but it needs to pick one update standard to be required, and that’s the one we’ll invest in on behalf of our customers. We have a long history of delivering the solutions our customers need, but it’s high-time the industry support the standards effort in a meaningful way to solve problems for vendors. So, pick one: 1.x Update or Web API Update.

  6. Turan Tekin says:

    Hi Mike – Just a few clarifying points here. We both know there are real, serious issues that MLSs and brokers are facing when dealing with listing data. Bridge has worked hard to use industry standards to solve many of those problems. For the most part, so have you. While many of the MLS’s listed in our press release are currently using Bridge products for data distribution and contract management, each one mentioned is a NEW partner for our RETS Update and Compose solution. The sole exception being Northstar which has been using our Update tool for some time. This was, admittedly, an oversight on my part when we created the press release.

    Your information about our involvement with GAMLS is inaccurate: GAMLS has never been a Bridge customer prior to their very recent decision to work with us on their RETS Update project. Our new relationship with them is going to yield some pretty exciting developments, so be sure to stay tuned.

    We know standards are crucial to the industry – we’re a charter member of RESO, and have along history of involvement in the organization. Bridge Interactive uses current industry standards and has been quick to adopt new standards like the Data Dictionary and Web API, as they became available. We are working with RESO to define the new “Update API standard” and will support and adopt it when it is finalized. Currently, it simply doesn’t exist. We don’t expect that the new API standard will be implemented by MLS vendors for at least a few years.

    In the meantime, we are focused on helping the industry solve real problems today and using the current standards that are available now, rather that waiting. We’d encourage FBS to do the same thing. Vendors like CoreLogic, Black Knight, and Innovia support the current, working RETS 1.8 standard. We think your customers would also benefit from having solutions that would let them enter a listing once, post to multiple MLSs, and store an unlimited number of photos. Let’s solve the brokers’ and MLS’ listing management problems now.

    • Michael Wurzer says:

      Thanks, Turan. Good information about Georgia MLS. I was just relating what I recall from years ago when I first was told the story of Bridge’s founding and the work it was doing with First MLS. I recall a demo David Harris did way back then at a RESO meeting that I thought was showing what is now your Compose product, but I must have misunderstood what you were doing back then.

      I think you’re overstating the case when you describe RETS 1.x Update as a standard. Yes, it is part of the RETS specification but, as you know, it has never been required and, though some other MLS vendors have coded against it, there has been very little actual adoption and implementation by MLSs. The result is that moving forward with implementing 1.x Update across the country will require investment of a lot of time and resources. If that investment is made, it necessarily will be at the expense of creating and implementing the Web API Update. This trade-off is even more clear for FBS, because we’ve been patiently waiting for the industry to provide some direction on the standard and so we have the opportunity to focus on a single standard. We’re simply asking the industry to work together to pick one.

      Regarding timing, it’s likely a self-fulfilling process for the same reason I outlined above. If everyone is forced to invest in 1.x Update, that will delay Web API update, quite probably for years and years. In fact, once 1.x Update is implemented on a broad scale, we all know that moving people off that approach will take years and years, if it ever happens.

      On the other hand, if we decide as an industry to pursue the Web API update with vigor, it will move forward as quickly as we all want. There’s a real choice to be made here, Turan, that will impact our industry for years to come. I know your company has invested in 1.x Update to a great degree and I’m sure your product is excellent. I understand why you’re advocating for it. The question we must address together is whether that’s where the industry should invest it’s time and money right now. See you next week in Austin.

Leave a Reply