A few weeks back, I received an email from Dave Eveland, the Transit Systems Information Coordinator for Madison Metro. He wrote:
Hello Erik – We met earlier this year (in January) at Mother Fools to discuss, among other things, the possibility of MetroTransit adding alternative electronic fare payment means (smartcards) to our upcoming farebox replacement procurement. We indicated at that time that it was our intention address this in the procurement but that we would actually implement this capability as part of a future capital purchase.
To that end we have included the following language in a draft RFP for the current purchase:
2.10 FUTURE SMART CARD READER DEVICES
This procurement is for the purchase of a Transit Fare Collection System that is fully capable of having a smartcard reader device installed, as part of a procurement the CITY plans to undertake in the next 2 – 5 years. The Transit Fare Collection System purchased must be fully capable of adding such a device. The CITY must be able to use in-service vehicles as our test-bed during development of a smartcard program. There must be included a complete physical description of the interface housing and connectivity requirements (conforming to SAE J1708/J1587 or SAE J1939 standards) on the farebox.
The CITY would like to access the application programming interface (API) documentation that would provide us with required information. If an educational partnership were to play a role in the development we would need to share that information under contract with a local university or college entity.
We do expect that we will have the flexibility to purchase this future enhancement from a vendor other than the vendor that provides the equipment acquired as part of this procurement.
The proposal shall include the estimated future costs associated with adding proprietarily smartcard readers.
This is a great start from the City – it’s wonderful that they’re including a request for an API in their Request for Proposals (RFP). This is very much in the spirit of the ‘Open Data ordinance’ that is working its way through the City approval process, and I’m excited that its thinking is showing up throughout the city even before the ordinance is passed. I suspect we’re one of the first cities in the nation to talk about APIs in our RFP, and we may not get great responses at this point. However, just by doing so, we’ll start putting API access on the radar of transit vendors, and help future cities with their procurement. Additionally, because we’re only buying part of the system now and are planning on upgrades in the future, signaling what we’ll eventually want is a smart play.
I suspect, however, that the API request in the Madison draft is just a bit too vague, and some more detail would help potential responders understand what it is that we’re looking for.
A complete Transit Fare Collection system has several components. There’s obviously the box that takes money on the bus – but even that is complicated. There’s the box that takes the money, yes, but there’s also the stand that holds the box that takes the money. You’ll note from the City’s draft language that what they’re asking for a system that can add additional devices in the future. Think of it as the city buying a home entertainment system – they need a cabinet and some power strips to hold everything to start with, and then they can add new devices. Imagine the cash-taking machine as a VCR, and the device that you swipe your card in as a DVD player (the ‘SAE J1739’ bit essentially specifics the type of plug the devices need to have.) The city’s RFP says whatever they buy, they need the ability to add in new devices – if it were an entertainment system, they wanted room left for a Blu-Ray player. What might we add in the future? Maybe an RFID card reader or a ‘NFC’ wireless communication box, which is a feature on some Android phones that lets you use your phone as a wallet.
This is probably not the part that we’re really that interested in an API for – it’s not even clear exactly how one would work, especially for consumers. I could imagine the ability of the City to connect to the farebox and perform diagnostics would be useful, or to be able to write custom software that runs on another device, also connected through SAE J1739, that can communicate with the farebox. (Imagine a box that communicates over the 3G/4G network and tells the farecard system ‘Yes’ or ‘No’ when certain cards are swiped). At any rate, I think this is one that I’d love for vendors to tell us about, but I’m not that excited about.
However, another vital part of Transit Fare Collection System is how farecards are provisioned and managed, and this is where I see the most use for an API.
Here’s how it (largely) works today. Besides cash, Metro passengers use a number of different farecards to board the bus. As a UW-Madison Graduate Student, I get a new card once a semester that the current Metro fareboxes know if I swipe I can get on any city bus, any time of the day. It records the fact that a UW card was swiped (possibly even which UW card it was) and once a week or month or so, the UW gets a bill for every swipe. There are other organizations in town that have similar deals – UW Employees, different hospitals, some local businesses, etc. This card is distinct for anything else I carry – it’s not my UW ID, and the only thing I use it for is getting on a Metro bus. The UW knows who I am, and if I lose my pass I can go and ask for a new one.
There are other Metro farecard options, which give you a discount over just paying the $2 fare every time. There are day and month passes, which work like the UW card I carry, but are only good for 1 day or 31 days after you first use it. At the end of the time period, you throw it away. There are also 10-ride cards, which can be used 10 times over whatever time period you so choose. Again, when you’re done with it, you throw it away. If you lose any of those passes before you’re done with them, you’re out of luck.
Compare this with other systems, where you can recharge your card. Sometimes it’s simple, where you just buy a farecard worth $10 or so, and every time you use it some value is deducted from the card. When you get down to your last bit, you buy a new card, and transfer the value over to the new card. The card never knows who you are, so if you lose the card you’re out of luck.
More interesting are the systems where you have some sort of account associated with the card. At a minimum, you have some recourse if you lose your card: you can sometimes go online and get a new card, with your old value transferred over. You can also usually add value to your card online, without having to use a special machine to do so. (The special machines are easy in systems like a subway or bus stations where there are limited stops, but are not as convenient for bus riders on the majority of stops.)
This ability to manage an account online is the API that I think we’re most interested in. I’ve written about some of the different scenarios that this could enable back in January.
So, rather than this:
The CITY would like to access the application programming interface (API) documentation that would provide us with required information.
I’d include something like:
The CITY would like to enable innovative transportation policies and programs and expects future Transit Fare Collection Systems to play a part. The CITY would like access to the application programming interfaces (APIs) documentation of the Transit Fare Collection Systems, including any online account management systems that enable riders to manage their SmartCards. The CITY expects such APIs to include security measures to protect riders’ fare balance, financial information, and privacy.
Obviously, we could detail this section in much greater depth, but hopefully this gets across the important concerns, including the fact that security will be an important issue for us. (You’d hope that’d be able to go without saying, but to keep everyone happy it’s always worth being explicit)
The next part of the City’s request is also a great first step:
If an educational partnership were to play a role in the development we would need to share that information under contract with a local university or college entity.
The intent here is to say that ‘We don’t just want Metro staff to be the only ones trying to use this API, but we want to bring in others who can and want to help.’ This is Government 2.0: that the real win of government is to create an environment where others can build on that work and multiple its effect. One of the obvious groups who could help are those around the UW/Edgewood/MATC – for example, student groups who are looking for a course project. However, we can make this a little broader, and include all of our community. Try this version:
‘The CITY would like fully engage the creativity and energy of the community to enhance the Transit experience. The vendor SHOULD detail how APIs can be securely made available without prejudice to (potentially multiple) interested parties. The Vendor MUST detail its policy on ownership of data the Transit Fare Collection System may collect.”
It’s important to include the mention of multiple parties. We don’t want the vendor to give exclusive access to some company, or to reserve exclusive access to itself. Open Access is one of the key principles that need to be respected in this whole “Government as a Platform/ Gov 2.0” movement. Without it, and the possibility of granting an exclusive contract, we’re straying into outsourced government/privatization, and nothing will kill Gov 2.0 faster in Madison than the appearance of privatization. Keeping the platform open, and letting developers go beyond what the city provides without denying the city the ability to deploy a “public option”, will keep it clear that the city will not allow the public good to become a private benefit.
I threw in a “SHOULD” here, because while I think the selection committee should rank API access very high on its evaluation, I don’t think it’s worth torpedoing the deal over.
We should also be clear that we want to know up-front who owns what data. Ideally, the City should own the data that is collected, and can decide for itself how it wants to manage that data. In this instance, however, I used ‘MUST’ – anyone who won’t answer this question shouldn’t be considered. It’s OK that there might be different answers, we can always negotiate that at a later stage.
All told, I’m very excited to see this come out of Metro. I’m doing this as a blog post and not just email to Metro because I’d love for other cities to find this, to share their ideas with Madison and to build off our eventual RFP. We’ve all learned different parts of these lessons, and we should share our experiences to create better transit and governments everywhere.
