Thoughts on “One Bike Registry” in the War on Bike Theft
I wanted to take a minute to address a topic that came up a couple of times in discussion – namely, “Why isn’t there just one bike registry?” It was suggested that the existence of more than one registry is materially less effective than multiple and should be a top priority for those working on the tech side of the problem. In fact, it came up again in a recap post from the event last night, “Bike Index’s entire business model is based on open-source code that can be easily used and implemented by anyone with the coding chops to make it happen. So, why don’t they team up and integrate their data?”
Since it’s come up a couple of times now, and perhaps my abbreviated answer last night was incomplete, I thought I’d take a moment to address a few thoughts on this multi-layered topic. It’s a simple question and a simple suggestion, but underneath the surface there’s a very textured set of issues to consider.
First, I believe in the advantage of multiple registries at this phase of the problem, and arguably, as I believe with any market, long-term as well. It’s basic economic theory. Multiple parties attacking a problem almost always result in greater choice for the customers, lower cost and greater coverage of the problem domain. And, as none of us have any hope of controlling others’, it’s more constructive start from the point-of-view that “there will be multiple” and to consider how multiple can be a force multiplier in the war on theft.
Consider – would the world be better served with one operating system? One bike component manufacturer? One religion? One social network? One news network? Before going too far down the path of advocating “one,” consider the ramifications if there was just “one” and how that might play out for the cycling community long-term. There aren’t a lot of single solutions / monopolies that I experience as a consumer that I’m excited about.
Surface area is another consideration.
I’ve been in high-tech for 30 years now and there’s always overlap in the tech world (and always will be). I always bias activity on the “gaps” vs. the “overlaps.” Bike theft is a massive problem estimated at > $400M and that doesn’t factor in the huge number of unreported thefts and the rampant component vandalism in urban areas. There isn’t one approach, solution or company that is going to “solve it,” and those that try will inevitably have some basic overlap in what they need to build. If you really believe in “one registry”, why stop there? Why not have “one” company produce all locks, all racks, one registration database, one mobile application, one key design, one… for the totality of the bike security sector? We’ve all experienced the benefit of competition – multiple companies with different philosophies means tackling gaps in the solutions available in different ways. For example, we have all benefitted from the fact that ABUS and Kryptonite have been competing in the bike lock space and I look forward to some of the fresh blood on Kickstarter that are trying to disrupt the category. I’m glad that all locks aren’t the same and that there isn’t just one choice or solution in the market. While I can imagine benefits of “one” lock design (integration with racks, bags, panniers, replacement parts and repairs), the benefits of choice overshadow “one.”
The size of most organizations involved in taking this on (we’re a small team… as are all of the bike registry efforts) cannot possibly implement every idea – it takes time to design effective solutions and write robust code to implement them. There’s generally a lack of appreciation for how much effort it takes to translate an “idea” into “code that works” – a lot of people believe software is inexpensive to build (because the industry has shifted away from charging consumers and instead selling your data and selling ads), but it’s simply not. Software is expensive to build and services are expensive to operate.
The way to make a dent in an epidemic with scarce resources is for the community to tackle it from multiple different angles to discover what works. When there is evidence that something works, everyone should turn up the heat on it. There’s decades of evidence that recording serial numbers and reporting thefts makes a meaningful difference in getting bikes back to owners. So, it makes sense for anyone working on this to embrace that, promote that and integrate that concept into their solutions.
Back to the refrain, “Why not just integrate the data? There’s an API!” While it may be on the surface appear “simple” to just “merge the data,” one must also consider the rights to the data. We’ve taken a pretty firm stance that our users’ bike data is their data. One could argue that we’re extreme on the privacy front, but as Facebook and other online services have demonstrated, it’s very difficult to add privacy controls when you start from a perspective of “everything is public.” We felt it was a lot easier to relax our privacy over time (if the community asks for it) than to try to impose it later. What does that mean when applied to the 529 Garage policy today?
It means that our members determine the degree to which they share their data. When a 529 members’ bike goes missing, they decide if it gets published to Facebook, Twitter, the 529 Hotsheet or goes out as a real-time alert to our community. They decide if their name, phone number or e-mail is visible in the alert or printed on their Missing Posters. They have the option to direct their report to the authorities or to their insurance carrier. This isn’t a judgement about other registries’ policies, but as this is the commitment we made to our users before they trusted us with their data, we need to ask their permission before we just copy it elsewhere. As another example, we don’t allow for anyone to search for non-stolen bikes in our service. We decidedly have not taken a stance that “all data should be open,” based on our experience as a team having worked on many commercial online services prior to this effort.
Before “merging” anything, it’s critical to be clear with members what the ramifications of that are in terms of their rights and policy. Taking the merge concept further, once you “merge” it, you get to consider if the data is editable from multiple services as well, factor in synchronization issues and also consider service level agreements that might be in place with other partners that attach to your service. It’s not as simple as “there’s an API.” We’re talking about real cyclists personal information, not just abstract “data” and that requires some pretty careful consideration for us to do responsibly. This isn’t a long-winded way of saying “no,” rather it’s putting some texture around “why don’t you just merge?” And, while there were two registries represented in the room last night, also consider others such as the National Bike Registry and Bike Shepherd which both pre-date Bike Index and 529 Garage. Imagine the complexity of all of them “just merging!”
At 529 we have a couple unique hypotheses that we’ve emphasized in our initial product and tried to deliver some innovative solutions around to see how well they impact the problem. We believe that mobile is critical. We believe that crowd-sourcing of recovery efforts and getting tips from the community is a necessary innovation. We believe that where the owners’ data goes should be the decision of that owner and that while there are benefits to open and public, there’s also risks and challenges associated. We believe that having visible unique ID’s on bikes is important. We believe that it’s important to be open with our users about our business model and have chosen to do our best to avoid advertising and do not sell our customer data to third parties. Many of these principles will get refined as we learn more and we may choose to revisit them completely, but at the moment, our principles are not wholesale “compatible” with all other registries out there and that needs to be considered.
In the 6 months since we launched our service do we have conclusive, scale proof that we’re right about any of these? No! Not yet. But once there is more evidence, we expect that others will follow suit or work with us as we will with them when they discover something that works. Would the community today be better served by us trying to put our finite resources against merging into “one registry” or should we complete our Android application, our features for University campuses and improve the quality of our 529 Shields? Should we direct scarce time, energy and money focused on getting more bikes registered towards merging the bikes that are? We’re of the strong opinion that we need to learn more and put more and new ideas out there and see what works after our first year on this journey.
I’d argue that until an effort has critical mass, energies should be applied towards getting more traction versus “tidying up” the modest traction the collective has made – focus on gaps vs. overlaps. While I applaud everyone that has done work on bike registration efforts (like Bryan Hance and National Bike Registry who have both been doing it for nearly a decade), I was struck last night as I was headed over to the event. In my hands was a petition signed by 51,203 cyclists in about 6 months asking Craigslist and eBay to require serial numbers on bike listings. Yet, I believe in the decade or so of all online bike registries, the collective has probably not proactively registered 51,203 bikes here in the states. In the US where there are 18M bikes sold a year, 1M bikes stolen a year and 51k cyclists frustrated enough to sign a petition in six months, it’s clear that collectively we haven’t cracked the nut on motivating riders to register their bikes before they are stolen.
Perhaps, as a community, our #1 priority should be to get people to register their bikes and to leverage the solutions that have been built. Metaphorically, I see a number of skyscrapers that have hardly been filled with tenants! The most meaningful thing we can do with these technologies is not to figure out how to merge the modest number of bikes registered, but on filling up the registries with as many bikes as possible.
Finally, there’s the topic of “one” and how to approach an integrated solution where it has been suggested that “merging the data” is the right solution by some. The beautiful thing about software is how malleable it is and how many ways you can tackle customer needs. Unlike say, manufacturing of physical goods, there are a lot of ways to deliver integrated benefit without welding everything together into “one” product and dealing with the many, many ramifications that has. If you believe that your car is registered exclusively in “one” database, you’d be very wrong. The VIN to your car is in many, many databases.
The motor vehicle world works – there is not “one” registry. There are 50 (in the US alone). Each have slightly different requirements, restrictions, fees, policies and license plate designs (and yes, a lot of redundancy). Yet, the industry has standardized on a couple of key things that allow our 50 states to register and license vehicles and also police their legal use cross-boarder. The industry has standardized on VINs and license plate size and placement. Aspects of registration databases connect to one another. Third parties (like CarFax) have built solutions on top of the infrastructure and even next-tier registries (parking on a college campus for example) add even more registries! The system works, not because there’s “one registry,” but because there are a few key standards in place that the players have agreed to and rallied around. Granted, this is an antiquated system and we should definitely be able improve upon it with our bike solutions, but it points out how interoperability and standardization is a viable alternative to having a single solution to a given problem.
Knowing only what I’ve learned in the last year of really working on the problem (and researching it a bit longer), a few things that I would love to see some unification on across parties. Imagine if:
- every constituency in the industry and community were committed to education and promotion of bike registration (without this happening at scale, this whole integration discussion is pretty meaningless).
- the industry came together on a “BIN” standard (bicycle identification number) endorsed by all manufacturers for future bikes starting in 2016.
- other interoperability standards were created that allowed for a collaborative international online registration network, especially for missing bikes. Formats, APIs, privacy disclosure standards, transfer standards, terminology, etc… were all thoughtfully considered and agreed upon by multiple parties.
Just because I don’t believe there will ever be “one” registry for bikes, all is not lost. Give yourself the luxury of embracing the idea of multiple registries (it’s inevitable!) and shift the conversation towards innovation and interoperability. Urge the tech companies to work together to solve real problems that the multiple registries pose and let them figure out the best ways to do it and hold them accountable to putting victims of theft ahead of individual company or personal agendas. Consider the benefits of innovation that some interoperability standards will motivate that we haven’t considered yet (like CarFax in the automotive world).
In closing, the one “one” that I would advocate strongly for in this discussion is a “one team” mentality. It’s natural, okay and actually beneficial to have different philosophies, companies, initiatives and efforts to attack this solution, but its critical to remember that we’re all on the same side. We at 529 are trying to do our part to engage with other efforts out there and explore how we can integrate where it can help the most and believe this is a 10 year quest. We have some thoughts, we have some plans, we even have some code and we will release it when it’s fully baked and up to our standards and the expectations of our members.
People often ask me about my thoughts on the “competition” and my answer is always the same.
Bike thieves suck.