So who will #WMATA pick? A conventional over-priced solution from a big-name transit IT firm, or an emerging open solution?
— Kurt Raschke (@kurtraschke) March 3, 2012
Last week, I asked if WMATA would entertain the idea of using a modern, open-architecture, open source system to power real-time signs at Metrobus stops. Unfortunately, I can now conclusively say that that will not be the case. When I first read the RFP, WMATA had yet to post the complete technical specifications. They’ve now updated the RFP with the complete technical specifications (albeit in an inaccessible, untagged PDF which is itself a scan of a printout).
The specifications state, in part:
Because of the criticality of meeting the firm deadlines, WMATA wants only to procure standard, proven products, from a Vendor with successful existing and fully operational implementations, in multiple transit agencies.
WMATA specifically does not want to assist a Vendor in developing new products for its product line for this RFP.
Furthermore, WMATA wants to select a Vendor that has clearly made a long-term commitment to providing contemporary customer information systems to the transit industry.
So, that’s that. I could go on at great length about how MTA New York City Transit’s success with OneBusAway, and how we could do the same for real-time signs, but I’ve already made that argument.
I’ve long known that WMATA is an agency which is deeply suspicious of change and innovation, and it pains me to see the agency continue to behave in ways that are manifestly counterproductive and which will in all likelihood only deepen the agency’s budget deficit.
The RFP requires delivery 90 days after the contract is awarded. MTA New York City Transit spent a lot longer than that on the OneBusAway pilot which lead to the present BusTime implementation. Naturally, I’m curious as to why the timeline is so tight. Considering the interjurisdictional coordination required to install things at bus stops, the testing required by WMATA, etc., I wonder if it’s even feasible for a major vendor to meet that timeframe. It might take longer than 90 days to productize something like the Mobility Lab’s existing work, but I sincerely think the payoff is there, in terms of up-front cost, long-term maintainability, innovation and quality.
We’ve already seen what happens when you choose the established vendor with a “long-term commitment”: you get a mess, like Montgomery County did with its bus passenger information system (more on that here). It’s time for a different approach.