Transit Agency Resources

More and more transit agencies are turning to OneBusAway to deliver real-time transit information to their riders.  There are many reasons:

  • It is open-source software that can be deployed without any license fees.
  • The web and mobile web applications are modern, slick, 508/ADA compliant, and easily branded and customized.
  • It provides native mobile apps for Android and iOS (iPhone).
  • It provides enterprise-level features that provide outstanding scalability and reliability.  (If it can handle New York’s 2.4M riders and 6,000 buses, it can meet your needs, too!)
  • It includes rich application programming interfaces (APIs) that enable third-party developers to offer innovative apps to riders, and in-house developers to do custom integration.
  • It can leverage simple GPS data feeds and does not require expensive AVL equipment.
  • It has the support of a broad community of agencies, universities, developers, and users.

Many transit agencies are deploying OneBusAway using in-house developers, or with the assistance of universities, production firms, or independent developers.  Some are hosting the system in-house, while others are leveraging cloud hosting options like Amazon Web Services.

If you’re thinking about OneBusAway as an option for your agency, we have the following suggestions:

  • Spend time here on OneBusAway.org to learn as much as you can.
  • Try it out – see our list of live OneBusAway deployments.
  • Have your in-house technical team visit the OneBusAway page at GitHub (they’ll know what that means).
  • Talk to the transit agencies who already use OneBusAway as their platform for real time customer information.
  • Contact one of the universities, transit agencies, commercial, or independent developers who work regularly with the OneBusAway platform.
  • Reach out to the OneBusAway community on the onebusaway-developers Google Group.

Finally, here are two suggestions regarding using the OneBusAway code in your deployment:

  • If you put out an RFP for a vendor to deploy and maintain the system, in the RFP specify that any changes to the system shall continue to be open source and should be contributed back to OTSF and the OneBusAway community in the form of well-documented GitHub pull requests. (They might or might not be ready for prime time, but please ensure that they will be available, rather than tied up with a proprietary license of some kind.)
  • Avoid permanently forking the code (that is, making a copy of the code and then customizing that without a plan to contribute the changes back to the community). Forking the code is tempting as a way to bring up the system quickly, but in the longer term it will make code maintenance a headache, since then you will need to repeatedly merge in updates to the main branch of the code with your own version.
  • Instead, if there is some customization to be done, do that in such a way that it will work for everyone, and contribute it back to the main code base. In particular, please see this blog post for information on doing this for the OneBusAway apps using a “white label” facility, which lets agencies customize the apps with their own branding while still sharing the main code base.