How we track Open Source health


We strive to make our code generally reusable for everyone who would like to solve the same problems as we do, our projects are not all at that level yet. We grade our project on the following scale:

  1. Custom, opaque: Very specific and not easy to learn from. Might lack documentation, have non-English code and documentation, contain copyrighted content or lack an Open Source licence.
  2. Custom, reference: Specific to our case and documented, can be used to learn from.
  3. Adaptable. Documented and possible to adapt.
  4. Reusable, configured. Configured specifically for our use, easily reconfigurable.
  5. Reusable. Fully (externally) configurable and useful for anyone.

As our goal is to make as much of the code we develop as reusable as possible. We would love to collaborate with you on implementing it in your situation, improving the reusability in the process. File an issue in the GitHub repository belonging to the project or send us an email and we’ll try to help you as soon as possible.

Basic project requirements

Any of our Open Source projects should have all of the following:




Community Metrics

A set of metrics to track per project. Most of these can be found in the GitHub repository Insights page.


By measuring both the views the repo is receiving and the amount of clones it is getting we can see how many people discover the project, and how many of those use the project.



Insights into contributions can help understand where the project should be going and what kind of governance structure you need.


Maintainer activity

Track how long it takes to reply to an issue or pull request, if this is longer than 48 hours the likelyhood that the contributor will contribute again drops off.



Friendly bots 🤖 can help you make great reusable code and help you grow a community around it. Automated test and code coverage reports are a great start. Integrating incoming issues and PRs in existing project management software can also make it a lot easier to respond and react timely to incoming contributions by the community. And consider having a bot generate reports on the health of individual products.

Further reading

All Guides


How to contribute to this City of Amsterdam Open Source project

Python backend projects

The style guide to the way we organize our Python back-end projects

How to code for humans

What we should think of when writing code so the most important computer we work with—the human brain—can parse it effectively

How we create cleaned, reproducable data for use in projects and apps

The way we make reusable data etl pipelines

How we create a docker environment for data analysis

How we set up a docker environment for analysis

How we set up logging and monitoring

How to incorporate logging to your applications and how to visualize this data

How we code Python

The style guide to the way we code Python

How we track Open Source health

Understanding the impact and health of Open Source projects

How to write a README

The goto file to see what a project is and how to use it