Open Federated Learning is a framework in wind-down, not a growing one

The README now leads with a retirement notice

The most important line in this repository is a note at the top of the README, and any review of this project has to start there. The Open Federated Learning project, formerly known as OpenFL, is no longer under active development and will soon be archived. For existing users looking for ongoing support, the README recommends the community transition to the Flower framework, using a migration guide created in collaboration between the two teams. That is a specific instruction with a specific destination, not a vague deprecation notice. It also means the project is worth reading for a different reason than a growing framework would be. The code is a settled, documented implementation that a team can study, and the migration path tells you which parts of the ecosystem moved where.

Collaborative training without moving the data

The framework's purpose is stated in the overview as enabling organizations to train and validate machine learning models on sensitive data, increasing privacy by allowing collaborative model training or validation across local private datasets without ever sharing that data with a central server. The mechanism is the standard one for federated learning, and the README explains it in terms of data movement. The minimum data movement needed across a federated training experiment is solely the model parameters and their updates, in contrast to a centralized learning regime where all data has to be moved to a central server or a datacenter for massively parallel training. The examples the project names for the sensitive data are personal information, patient records, financial data and classified information. The framework is hosted by The Linux Foundation, and the package is on both PyPI and conda-forge.

It grew out of a medical imaging collaboration

The project's history explains a lot about its design. Open Federated Learning builds on a collaboration between Intel and the Bakas lab at the University of Pennsylvania to develop the Federated Tumor Segmentation platform, known as FeTS, under a grant from the Informatics Technology for Cancer Research program of the National Cancer Institute. The README calls FeTS a real-world medical federated learning platform with international collaborators, and says the original project and Open Federated Learning are designed to serve as the backend for it, with developers continuing to work closely with Indiana University on FeTS. An example integration is the FeTS-AI Front-End, which combines the group's medical AI work with the framework to produce a federated learning solution for medical imaging. Even so, the README is explicit that although it was developed for medical imaging, the framework is designed to be agnostic to the use case, the industry and the machine learning framework.

Two experiment styles, one marked experimental

There are two ways to set up a federated learning experiment, and the distinction is about the shape of the experiment rather than about convenience. The TaskRunner API uses short-lived components such as the `Aggregator` and the `Collaborator`, which terminate at the end of an experiment, and it supports mutual TLS based secure communication channels and TEE based confidential computing environments. The Workflow API allows experiments beyond the traditional horizontal federated learning paradigm through a pythonic interface, and it lets an experiment be simulated locally and then scaled to a federated setting by switching from a local runtime to a distributed, federated runtime. The README marks that second capability as experimental, which is the qualifier to carry into your planning. If your experiment needs a topology that horizontal federated learning does not cover, the Workflow API is the route, and it is also the less settled one.

Four aggregation algorithms across four backends

The feature table is short enough to read at a glance, and it is the clearest statement of what the framework actually supports. Four aggregation algorithms are listed as available out of the box. FedAvg and FedOpt are supported on the PyTorch, TensorFlow and NumPy backends. FedProx is supported on PyTorch and TensorFlow but not on the NumPy backend. FedCurv is supported on PyTorch only. Each row cites the paper it comes from, from McMahan and others in 2017 for FedAvg through Shoham and others in 2019 for FedCurv. The framework itself is backend-agnostic and comes with support for NumPy based machine learning frameworks such as TensorFlow, PyTorch and Jax, which have to be installed separately, and the README notes that users may extend the list of supported backends if they need to. The pattern in the table is worth noting, since coverage thins out as the algorithms get more specialised.

Installing and the shape of the repository

Installation is a one line operation on either of the two package channels the project publishes to. The latest stable release comes from PyPI:

pip install -U openfl

or from conda-forge:

conda install conda-forge::openfl

The README also points to an installation guide for other options. The repository is laid out for both users and contributors, with an `openfl/` package directory, `openfl-workspace/` holding workspace files, `openfl-tutorials/` and `openfl-docker/` for the tutorial and container workflows, plus `docs/`, `tests/`, `scripts/` and `setup.py` with its own gRPC protobuf build step. The quality tooling is visible in the configuration files: ruff with Bandit security checks, Pyflakes, Bugbear and isort, a coverage configuration, a `.pre-commit-config.yaml`, a `Jenkinsfile` for continuous integration and a `.trivyignore` alongside a `CITATION` file, a `GOVERNANCE.md` and a `TSC.md`.

Apache-2.0, a governance trail and a slowed release line

The licence is Apache-2.0, with a `LICENSE` file at the root and a separate `LICENSE-3RD-PARTY` file for the bundled dependencies. The project carries the usual institutional markers of a Linux Foundation hosted effort, with a `GOVERNANCE.md`, a `CODE_OF_CONDUCT.md`, a `CONTRIBUTING.md` that the README links, a `ROADMAP.md` and a `CITATION` file, and it displays a Core Infrastructure Initiative Best Practices badge. The release history shows the slowdown. The listed versions are v1.7.1 from 2025-02-24, v1.8 from 2025-03-26 and v1.9 from 2025-06-23, the last of which is also the newest tag, and the last push to the repository was on 2026-08-25 with the default branch being `develop`. The documentation is built on Read the Docs and the project has a Slack workspace, so the artefacts that will remain readable after archiving are the docs, the changelog and the tagged releases.

Editorial conclusion

Adopt Open Federated Learning if you already run it, or if you want a readable reference implementation of a federated stack with mutual TLS channels and trusted execution environments, since the framework is mature, documented and hosted by the Linux Foundation. Do not start a new long lived project on it, because the README states plainly that the project is no longer under active development, will soon be archived, and points users to the Flower framework with a migration guide. Verify first where your deployment sits against the TaskRunner or the experimental Workflow API, and read the migration guide before planning the next release of your own system.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. securefederatedai/openfederatedlearning on GitHub