by G. Sax, Director of Growth Management, RESO
Welcome to “Three Questions,” an interview series that introduces you to real estate industry professionals, their businesses and how they interact with real estate standards with a goal of humanizing the tech side of the industry, fun included.
This week, we delve into the first part of our interview with the illustrious Paul Stusiak, President and Founder of Falcon Technologies and the longtime chair of the RESO Transport Workgroup. We discussed the woolly world of data transport, compared collaboration software and dug deep into the history of RESO. Enjoy!
Q1: Creating enforceable industry standards is cause for some of the more spirited conversations in RESO workgroups. As the chair of the Transport Workgroup, how do you feel about our procedures today and where we are going with data transport standards?
Paul: Before we begin, I find it interesting that this series is called Three Questions, because there are only two things that are hard in software development: naming, cache invalidation and off-by-one errors.
RESO: Wow. Now I want every interview to start with a dad developer joke!
Paul: Yes, it’s true that we can all be in the room and have arguments, but you must support those arguments with facts. And then you have to convince other fact-driven people that your fact is not only sexy but real.
We have major players that are going to have to face the consequences of not being more involved in our efforts.
That sounds daunting when I say it out loud, but I’ve been saying the same thing for the last five years. We are tightening the standards. You can come to the table and affect the standard or deal with what we vote in. We want all voices to be heard, of course.
Nobody is going to pass compliance once some important changes are made. Those who seek to be certified will need to start planning the work to be compliant.
We don’t want anyone to be surprised, so look at the Transport Workgroup page on RESO’s Confluence and look at RESO’s GitHub for Transport-related topics. It’s all right there.
Q2: You’ve touched on an important separation there. The Transport Workgroup recently moved most of its activity outside of meeting agendas and post-meeting notes from RESO’s workgroup collaboration system, Confluence, to the more tech-centric GitHub. Do you feel a noticeable improvement after this move?
Paul: Back to the future, right? We identified problems that we were having with participation and addressed them with the move to GitHub.
It’s good that we were responsive to our constituency, which wanted somewhere more conducive to the kind of collaboration that developers are used to, with spec documentation, branching, pull requests and open-source technical standards that are built for contribution beyond our membership.
We made the conversion, but we didn’t move everything away from the space where most RESO workgroup activity takes place. It wasn’t our purpose to take our ball and go play by ourselves.
We’ve met our goal for this move, which was to go from somewhat responsiveness to our calls for comment to almost immediate responsiveness.
Because there is only one Josh [Darnell, RESO CTO], and there’s only one Sergio [Del Rio, Transport Workgroup Vice-Chair], we have to have good participation from those who attend our meetings. GitHub has certainly helped with that.
Q3: You have been with RESO since the earliest days. Can you give us a little history lesson about where we were to where we are today with data transport?
Paul: In 1998–1999, I contracted for a company called GTE Enterprise Systems which turned into T3. We worked on systems for what is now Stellar MLS and Bright MLS. One of the things I was called to do was to write what we now call an API.
It turned out that five or six other groups were doing this, too. They took my thing and brought in Curt Beardsley [former “shepherd of MLSs” and past VP at Zillow and Move] and mashed them with the other groups. They came back with the Real Estate Transaction Standard (RETS). Sergio and I got involved with that very early on.
At T3, we were building the system. Then, Bell Atlantic merged with T3 and decided it wasn’t a core business and cut the team down from 120 to 8 people. I left that situation before the worst of it.
Meanwhile, Geac was a company that acquired a lot of tech businesses in the 1990s and owned a company called Interealty, which was a system vendor for many years, so I started working with them. MRIS, which is now Bright MLS, was one of their big customers, and it was on a UNIX system that supported their 30,000 members on phone lines and modems.
The CTO of MRIS at the time, Gregg Petch, asked Interealty if they were going to be able to support them. Interealty said yes but they had to switch to their Microsoft SQL Server system. Gregg actually offered to buy the code so he could work on it in-house! Interealty declined.
Dale Ross was the CEO of MRIS at that time. We started with a clean whiteboard and did the preliminary design in his office in four days. We had and implemented plenty of ideas, and some of the code we wrote is still in use today, 20 years later.
Gregg wanted the system to be RETS native. The only way to get data in or out was with RETS. There was no back door/direct database access. Sergio did a lot of that work, and I helped. We started doing a fully scalable system. Sergio was a huge star, because he had gone into MRIS and saved them a bunch of money with his Oracle knowledge.
There were many iterations and improvements, but the original system was RETS. When you made a RETS call, you were basically touching the database. FTP was always breaking, so RETS was a great leap forward.
We architected that whole thing. It was cool. At least we thought so.
So that’s a little history of RETS and an early implementation.
I want to say that a dearly departed colleague, Bruce Toback, deserves a lot of credit for creating the entire foundation of what this is: vendor neutral. We’re trying to make this industry better. Sam [DeBord, RESO CEO] is like Bruce in that regard.
Bruce felt very strongly that this should be community-driven.
Bruce was passionate about the kind of work we are doing today. After Bruce died, I had a phone call with Dale Stinton, who was the CEO of the National Association of REALTORS® (NAR) at the time and who I’d never talked to before. He asked me and industry consultant Steve Verba to carry on Bruce’s work as vice-chairs of a data standards group under Dale.
Mark Lesswing, current chair of the RESO Distributed Ledger Workgroup and who was the CTO of NAR’s Center for REALTOR® Technology (CRT) at the time was a key person who shepherded the RESO cause forward.
Mark was at the first meeting and has been involved with the standards effort since the very beginning. He drove the need to provide the community with open source tools. He backed that up by committing the CRT to write some of those tools that he contributed code to. I’m certain that if anyone is still emitting RETS data, there is at least one client that is using a library that he wrote.
RESO: Mark is still rocking his RESO as the chair of the Distributed Ledger Workgroup while also sitting on the RESO Board of Directors, but why doesn’t Bruce have a picture on a RESO Legends page on our website?
Paul: He should have!
