Open Source for New York City

Aidan Feldman
Feb 24, 2016 · 10 min read

A couple of weeks ago, I was asked if I would testify in support of two bills being put in front of the New York City Council (NYC’s legislative body), both around use of open source software in the city government.

Image for post
Image for post
me (just some guy), David Moore (creator of CouncilMatic), Council Member Ben Kallos (who is proposing these bills), John Sullivan (Executive Director of the Free Software Foundation), and Paul Tagliamonte (board member of the Open Source Initiative) at City Hall

I was honored to be testifying alongside people and organizations that I deeply respect. Of everything said in the two-and-a-half hour hearing, the testimony that stood out was from Karen Sandler, Executive Director of the Software Freedom Conservancy. The full text is here, but I wanted to pull out one particular section:

I am deeply familiar with the dangers of proprietary software. I have hypertrophic cardiomyopathy (I have a big heart) and have an implanted medical device with software that I cannot review or work with my healthcare professionals to modify. I rely on one company to ensure its safety and hope that they provide the life-critical updates I need. I have no real choice because there is no free and open source software defibrillator. I wonder every day if I will get an inappropriate shock or have my device fail through inaction. I live with proprietary software in my body, knowing that it has vulnerabilities I can do nothing about.

While there is no way I can compete with a story like that, here is the written testimony that I submitted (lightly edited):

Dear Chairperson and Members of the Committee on Contracts-

Thank you for the opportunity to testify to the Committee in support of two important bills:

I am a software developer who has been living and working in NYC for six years, and in that time have been actively engaged with the developer and civic technology communities. I currently work for 18F, a 100% open source team in the federal government, though this testimony is being done in my personal capacity. In and outside of my job, I am a maintainer of dozens of open source projects, and actively contribute to and promote open source across a variety of programming languages. I should make clear that I am not a lawyer nor an expert in procurement or policy, but believe strongly in the value of open source and effectiveness of public services. I will present information as clearly and honestly as possible, and include references where applicable.

I am largely in favor of both bills, though have specific feedback on how each could be improved. In this testimony, I will discuss the general benefits of open source, particularly in the context of government, and then address each bill individually.

Benefits of open source

Interestingly, this bill is a perfect example of permissive licensing in action: the definition for “open source software” in §6–401(b)(1–10) is pulled directly from the Open Source Initiative (OSI) web site. Normally, copyright laws would apply to content published on the web, so text could only be reused with express consent of (and often a fee paid to) the copyright holder. In this case, however, OSI’s site footer specifies that: site content is licensed under a Creative Commons Attribution 4.0 International License.

Therefore, the content can be reused and repurposed without the knowledge or consent of OSI. While the bill should reference the OSI to be compliant with the license, it’s important to note that this bill could not exist (as written) without the existence of permissive licenses for content. The sponsors of the bill didn’t need to come up with a definition of “open source software” from scratch — they could take the canonical definition that has been developed and refined since 1998 by top experts in the field.


Imagine instead that the software carried an open source license. If the software is custom-built, only one procurement would be required, and if it’s available “off-the-shelf”, the entire procurement process could be skipped. Any other agency in any government could then benefit from the existence of that software, skipping their redundant procurement cycles. There is also greater freedom to experiment with what software works best for a given problem, as there are lower financial/legal barriers to evaluate the systems. Agencies can also be more flexible in changing systems when it suits their needs, rather than feeling compelled to wait out the duration of a license.

Additionally, open source software means a reduction in vendor lock-in, because the source code can be read and modified by anyone, including a new contractor. Therefore, money spent on software contracts can be better spent in supporting and improving the software, rather than paying over and over for the same thing.


System security should not depend on the secrecy of the implementation or its components.

Relatedly, the Department of Defense issued a memo in 2009 stating:

The continuous and broad peer-review enabled by publicly available source code supports software reliability and security efforts through the identification and elimination of defects that might otherwise go unrecognized by a more limited core development team.

In other words, source code on popular open source projects is monitored by many people, meaning it is often more secure than its proprietary equivalent.

It’s important to note that source code being public is completely separate from data being public — an open source project is no more likely to reveal sensitive information than one that is closed source.


Aside from what has been mentioned above, open source software (particularly projects with strong communities) has the following benefits:

  • Issues that have been previously encountered are often documented on public sites, meaning that solutions can be found without relying on a support contract.
  • Agencies can benefit from upgrades made by the community “upstream”, without the need for paid upgrades. Conversely, any improvements made by the city will benefit the users of the software, and thus contribute to the greater good.
  • If a piece of software needs to be modified to suit an agency’s needs, the code is immediately available to do so, and there is no risk of violating the terms of a license.
  • Because data formats used by open source (and the code used to generate them) are almost always open, there is generally better access to and portability of data than in proprietary systems.
  • As noted in the preamble to Int. 0366–2014, the availability of the code means greater transparency and ease of auditing.

Int. 0366–2014: Free and Open Source Software

Open vs. closed source

  • Availability, succession, and permanence of the city’s data
  • “Interoperability through adherence to open, platform-neutral standards”
  • Dictate “how, and for how long, the city may use the software it has acquired”
  • Ensuring that software doesn’t, “in addition to its stated function, also transmit data to, or allows control and modification of its systems by, parties outside of the city’s control”

Though these desirable conditions are easier to achieve through open source, it’s important to note that these requirements could be written into contracts for proprietary systems. Therefore, I believe that these points should be included in the text of the bill itself as requirements for all software procured by the city, but separate them from the stated benefits/requirements of the license.

Off-the-shelf vs. custom software

While I clearly have strong feelings about the benefits of open source, I am also pragmatic about the tradeoffs. For example, use of “cloud” software (e.g. Amazon Web Services or Google Apps) can greatly reduce the operational burden/costs of the city, despite the fact that those systems are rarely open source and don’t necessarily provide the same level of control over data as self-deployed solutions would. In such cases, the benefits of using proprietary products may outweigh the fact that they are not open source.

My suggestion would be that each software need be evaluated on a case-by-case basis for its effectiveness in completing the stated objectives, with the following (possibly weighted?) considerations:


  • Open source
  • Available off-the-shelf
  • Commodity software (i.e. is a similar offering available from multiple providers, and would the switching cost be relatively low?)
  • Cloud-based
  • Large community
  • Comprehensive documentation


  • Closed source
  • Needs custom development/maintenance
  • Offering unique to that provider
  • Needs to be deployed by/for the city

Additional suggested requirements

  • Any software that is custom-developed for or by the city should be released under a license approved by the Open Source Initiative, if not dedicated to the public domain through something like CC0.
  • Any contract for custom software should require transfer any copyright in the work to the government.
  • The public release of custom software should include all design documents and documentation pertaining to the project.
  • All software should use open, standard, and well-documented data transfer and storage formats. There should be no restriction on the ability to read/write/convert to/from these formats.
  • All custom software should be developed in the open from the start, and allow/foster participation/collaboration with the broader government community and the public.

This last point is in contrast to the “throw it over the wall” approach to open source, where the code is developed behind closed doors, and only publicly released once, or at infrequent intervals. This all but guarantees that the project will receive no outside contributions, and may contribute to fragmentation around the project community. More information at Civic Commons.

One open question: does there need to be any language in the bill pertaining to patents? This is an issue that can often complicate the use of open source software.

Int 0365–2014: Collaborative Software Purchasing


coordinate with jurisdictions outside of the city of new york regarding the procurement of software

I don’t know of any initiative like this from any other government — I think it will be the most impactful piece of the entire bill, and also the most difficult to accomplish.

Implementation details

That being said, is a wonderful resource, which would largely benefit from use and contribution by the city government. These kinds of open guides are practically zero-cost to run and maintain, but can be hugely beneficial.

In general, this bill may place too much emphasis on the implementation details (e.g. building a portal), rather than setting desired outcomes and allowing the program office to identify the best solution. There may be research that went into this bill that I’m not aware of, but the user-centered approach would be to ask the question, “what are the biggest obstacles for procurement specialists and/or program offices to adopt open source software?” The answer may be discoverability of existing options, which a portal would solve, though it’s worth investigating if there are other large hurdles.

Source code

Additional feedback

  • Point out that the agency in charge of developing the portal will also be responsible for maintenance.
  • The agency responsible for the platform should encourage community engagement for the projects and overall platform, with city and external government users, as well as the public.
  • The agency (and the platform itself) should encourage modern/forward-thinking development workflows for the software listed on the platform.
  • Ensure there are clear instructions about how to build/deploy each piece of software.
  • Making it clear where to go with support questions, feedback, contributions, etc.
  • Using package management, build tools, containerization, and other strategies for making deployment as easy as possible.
  • What software is required to be listed on the portal, if any?



Aidan Feldman

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store