Everyone wants to hop on the bandwagon of Open Source application development for the most obvious reason, eliminating commercial software licensing costs. However, an organization’s decision-makers need to consider a much more complicated set of Open Source advantages and disadvantages before making a commitment on its development strategy.
At the start, it seems there are more questions than answers. What are the constraints local government agencies have in embracing the Open Source culture? How do you prepare an organization to move from proprietary, vendor-supported software development practices to a non-commercial, community-based environment? Why should a municipal government agency invest in a new technology practice that many consider risky, and that needs significant upfront investment in new computing environments and training? What are the right Open Source frameworks, code, and systems supported by a robust development community?
This discussion tries to answer these questions by describing one initiative undertaken by the New York City Department of Transportation (NYC DOT). We successfully ventured into Open Source development practices for a major IT system replacement moving from mainframe to web.
Business and Technical Transformation
NYC DOT’s mission is to provide for the safe, efficient, and environmentally responsible movement of people and goods in the City of New York. Traffic signs on the City’s street blocks and intersections collectively define the traffic regulations, and provide information about speed limits, driving direction, parking, and other guidance to motorists and pedestrians. NYC DOT recently replaced its long-serving mainframe traffic sign order management system after more than three decades of use. We replaced it with a new custom developed, Open Source web application: the Sign Information Management System (SIMS). Nearly 11.5 million records were migrated to SIMS, and 100 Android tablets were deployed to field staff for real-time visibility and tracking of work progress. This eliminates paper-based work order tracking and delayed data entry.
“In our case, what started as implementing a common Open Source asset management platform ended up in a new branch of codebase specifically customized for our client workflows”
This was the first major enterprise-level Open Source IT system implemented at NYC DOT.
In our case, what started as implementing a common Open Source asset management platform ended up in a new branch of codebase specifically customized for our client workflows
Change is hard. First, you need a champion who will stand by you to support change, who is willing to take risks for the greater good of the organization, and who is determined to push the enterprise beyond the comfort zone of proprietary systems and vendor lock-ins. Cordell Schachter, the Chief Technology Officer of NYC DOT, was this project’s champion. With experience in government and corporate IT project development, Cordell has charged our IT organization to diversify technology investments, look for opportunities to use Open Source technology, all to avoid vendor lock-ins to increase leverage in contract negotiations. Taxpayers are better served when government organizations have a wide list of technology options for larger projects federated across multiple technology stacks.
Second, you need a team ready to take responsibility for systems built on new technology. A key to our project’s success has been the oversight by the staff on the in-house Open Source DevOps team who supported the most challenging aspects of project execution and now supports the system in production. The DevOps team was formed by the IT & Telecom’s Project Management Office (PMO) that I lead at NYC DOT.
There was skepticism within our organization about using the new technology. Like most municipal government agencies, NYC DOT has significant IT investments involving proprietary vendor technologies. The majority of our customer-facing transactional applications utilize those platforms. Our IT team is trained in those technologies. Introducing new Open Source application frameworks meant that we needed to build in-house expertise to support them and not rely just on vendors. We added Open Source development team members, and provided training opportunities. All were ready to take responsibility for the operation of the system at launch, and were important participants in the Go-Live readiness process.
Third, your government purchasing process needs to be open to procuring Open Source and other non-traditional technologies. We conducted a Request for Proposal (RFP) process. The evaluation team selected an established vendor, Cambridge Systematics, with expertise in building Open Source asset management and work order tracking solutions. We executed a Fixed Firm Price (FFP) contract and used Agile product development.