The Mayor’s Office for Economic Opportunity (NYC Opportunity) supports and promotes open-source software development. This repository contains our open–source policy and a list of public repositories on GitHub, including public-facing digital products and packages used by our products. Feel free to ask questions and share feedback. Interested in contributing? See our open positions on buildwithnyc.github.io. For details on maintaining this site refer to the contributing guide.
Open–source policy
We derive inspiration from other public sector open-source policies while also considering the values of our organization. Much of the code that we use and share is publicly available on GitHub within the @CityOfNewYork and @NYCOpportunity organizations. For us, the benefits of being an open-source organization are as follows.
-
Working in public creates mutual benefit, shared understanding, and learning with the civic tech community.
-
We can support other organizations and city agencies that may be attempting to deliver services with similar technologies.
-
It keeps us accountable to our core principle of equity allowing others to take advantage of resources to work to their fullest potential.
We also maintain public APIs and datasets, particularly the NYC Benefits Platform which comprises the Screening API and Benefits and Programs Dataset hosted on the NYC Open Data Portal.
Use of open–source
NYC Opportunity benefits from the availability of open-source software. Particularly,
-
The WordPress Content Management System, plugin ecosystem, PHP programming language, and PHP package ecosystem (Packagist).
-
Node.js programming language and packages on the Node.js package registry (NPM).
-
Design Patterns such as the NYC Core Framework and the U.S. Web Design System.
-
Open-source graphics and typography such as Noto Fonts, Public Sans, and Feather Icons.
-
And much, much more.
Attribution to other’s freely shared work should be considered, whether explicitly or indirectly. Examples of explicit attribution include crediting text and links to sources on our public-facing sites, repository, or wherever the work is used. Indirect attribution includes stating a work as a dependency in a publicly visible package manager file (such as package.json).
Position
Team members may choose to work in private or public repositories. There may be many reasons why someone chooses to work in private whether it be for an extra layer of security or they feel more confident publicly releasing something in a more finished state. However, we encourage everyone to try working in public.
Community
Internal
When contributing to a project the team considers how the contribution will not only benefit and sustain the project but also the team. This consideration has a broader impact on how we share our code as well.
-
Contributions should strive to be reusable with as few barriers to implementation as possible.
-
Documentation should be done proactively, not retroactively, and should consider the broadest reading audience possible.
-
Condescending tone, exclusive terms, and assumptions about understanding should also be avoided in source code and documentation.
-
Standards are highly respected and valued but should not prevent us from adhering to our principles.
External
We encourage those aware of our open–source work to ask questions or contribute constructively to our open–source projects where they are hosted (GitHub). We expect that those who wish to engage in the work also adhere to the principles illustrated here.
Unfortunately, we do not have the capacity to accommodate feature requests although the sharing of constructive ideas is highly encouraged.
Open-source licenses
The GNU General Public License is preferred though it is not a requirement for all of our software.
