The mission of the OpenFL Project is to build a flexible, secure, scalable, and easy to use Federated Learning library for data scientists and data owners. OpenFL allows decentralized training and validation of AI models across data silos accelerating time to market deployment of Federated Learning. It provides the greatest access to data through enabling secure, privacy preserved data.
OpenFL operates in a transparent, open, collaborative, and ethical manner. The project decisions, timelines (including roadmap), and status is intended to be open and visible to everyone.
The OpenFL community follows the next principles:
- Openness: OpenFL is facilitating open collaborative development. OpenFL is an open source project with the Apache 2.0 license. We welcome contributions from anyone. For specific steps on how to contribute to OpenFL please see our Contributing guidance.
- Respect: OpenFL requires healthy communication and respect to any participant. Please see our Code of Conduct.
- Transparency: work and collaboration should be done in public. The discussions, main decisions, priorities, roadmap of the project are open for everyone.
OpenFL has the following roles in the project:
Users (or Customers): anyone who uses OpenFL. The users contribute to the project by providing feedback in the form of bug reports and feature suggestions.
Contributors: contribute to the project in the form of code or documentation. Anyone can contribute to OpenFL.
Maintainers (or Committers): review and merge pull requests; make short-term decisions for the project; have commit access. Maintainer is an assignable role by the Technical Steering Committee.
Technical Steering Committee (TSC): defines strategic objectives and makes strategic decisions. A TSC member is an elected role by other TSC members.
One of the main OpenFL design principles is a great usability. We aim to build an easily to use library for Federated Learning and bring to users a great developer experience. We believe that our users and customers should guide us in building the great software that solves the data silo and data privacy problems. We encourage users to provide us feedback, ask questions, initiate discussions, propose bug reports and suggest features through the following tools and formats:
- Usage of OpenFL;
- Discussions in our Slack channel;
- Opening Issues and discussion topics in our GitHub;
- Participation in Community Meetings.
Contributors include anyone in the community who contributes code, documentation, or other technical artifacts to OpenFL. If you want to contribute to OpenFL, please see our Contributing guidance. We also welcome you to participate in the discussions through the Slack channel, GitHub Issues and discussions, and Community Meetings. We expect from contributors that they follow our community principles of communication.
Contributors who regularly participate in the project life and make significant contributions may become Maintainers. If you want to become a maintainer, please reach the members of the Technical Steering Committee(#technical-steering-committee).
The Maintainers are a subset of Contributors who have earned the ability to modify (“commit”) source code, documentation or other technical artifacts in a project’s repository. Maintainers also have access to the OpenFL continuous integration (CI) jobs.
The expectation from the Maintainers is that they spend significant time working on the project, agree with long-term strategy of the project (defined by the Technical Steering Committee), and improve the project by making short-term decisions and supporting users and contributors.
The Technical Steering Committee assigns new people and removes the members from the list of Maintainers. The reasons for exclusion from the list of Maintainers may be violating the community principles, prolonged inactivity in the project or other reasons that may harm the project. A member can also voluntarily leave the list of maintainers.
Both maintainers and contributors may propose changes to the OpenFL source code. The mechanism to propose such a change is a GitHub pull request. Maintainers review and merge pull requests.
Two maintainers must approve a pull request before the pull request can be merged. In a case there is a limited number of maintainers in the project (less than 7), one approval is enough. Approving a pull request indicates that the maintainer accepts responsibility for the change. Approval must be from maintainers who are not authors of the change.
If a maintainer opposes a proposed change, then the change cannot be merged. The exception is if the Technical Steering Committee votes to approve the change despite the opposition. Usually, involving the Technical Steering Committee is unnecessary.
Maintainers communicate through a Slack channel, GitHub issues, discussions, and public meetings. Security and sensitive topics should be discussed privately, other topics predominantly should be discussed publicly.
Maintainers’ responsibilities:
- Contribute to the project through code or documentation contributions;
- Review and merge pull requests;
- Participate in discussions through Slack, GitHub or community meetings;
- Answer the questions and provide reasonable assistance to users and contributors.
See the list of Maintainers here. There is no limit on the maximum number of maintainers.
See calendar of the public maintainers meetings here.
The Technical Steering Committee (TSC) is the main decision-making authority of the OpenFL project. The TSC defines the strategic objective of the project, makes business & legal decisions, as well as high-level technical decisions. The TSC consists of elected members. The election takes place every year by the end of the first quarter (Q1) of the year* , but changes in the TSC may be made during the year based on the project needs and the decision by current TSC members.
The current list of TSC members is here. The number of TSC members can be increased, but up to a reasonable size (no more than 9 people). The minimum size of the TSC should not be less than 3 people.
* For 2023 there will be no elections, TSC members and Chair are defined by the founding organizations.
The Technical Steering Committee members are deeply engaged in the life of the project, they share the mission of OpenFL, believe in its success and do everything that is needed to achieve it. They are not only decision-makers, but also evangelists of the project. More specifically, they:
- Share responsibility in the project's success;
- Have made a long-term, recurring time investment to improve the project;
- Spend that time doing whatever needs to be done.
The TSC members pledge to participate in the regular TSC meetings, vote thoughtfully and make right decisions.
The TSC members are responsible for all business, legal and technical oversight of OpenFL. More specifically, they:
- Define the project strategy, including key success metrics and regularly updated roadmap;
- Coordinate the technical direction of the project;
- Organize sub-projects and remove sub-projects;
- Create sub-committees or working groups to focus on cross-project technical issues and requirements;
- Establish community norms, workflows, issuing releases, and security issue reporting policies;
- Evaluate and form list of Maintainers;
- Make decisions about adding new TSC members, replacing or removing current TSC members, as well as electing a TSC Chair;
- Coordinate any marketing events, or communications regarding the project.
The Technical Steering Committee has a Chair. The current TSC Chair is listed here. The election of a new Chair takes place every year (by the end of Q1 of the year).
TSC Chair’s responsibilities:
- Serve as the primary communication contact between OpenFL and the LF AI & Data Foundation;
- Publish and regularly update OpenFL Roadmap;
- Prepare, review and run the agenda for the TSC meetings;
- Take care about the artifacts and outputs of the meetings: translating decisions to the public, tracking the required actions, sending follow-ups, publishing meeting notes and meeting recordings;
- Resolve voting issues: if some decision cannot be made through the voting procedure (for example due to the equal distribution of votes or other reasons), the TSC Chair can make an ultimate decision.
- Adding a new member can be done at any time during a year. Discussion and voting procedure can be done at a TSC meeting or by email. Adding new members should not exceed the maximum size of TSC specified above.
- A TSC member should withdraw from the TSC if it no longer supports the goals or technical direction of OpenFL. In the event of any vacancy on the TSC, the TSC may add a new member as set forth in the bullet above. Alternatively, the TSC may decide not to replace a member, but to reduce the size of the TSC. The minimum size of the TSC should not be less than specified above.
- Upon vote of not less than two-thirds of the TSC, the TSC may remove any member of the TSC upon a good faith determination that such member has materially violated the terms of any OpenFL participation agreement or governing documents, or has engaged in conduct materially disruptive or prejudicial to the goals, purposes, interests or technical direction of OpenFL.
Any meetings of the Technical Steering Committee are intended to be open to the public. Exceptions may apply for security-related topics, legal issues, or other sensitive information.
The TSC members communicate through a public Slack channel, email, GitHub issues and discussions, and public meetings.
Quorum for TSC meetings requires at least two-thirds (⅔) of all voting members of the TSC to be present. The TSC may continue to meet if quorum is not met but will be prevented from making any decisions at the meeting.
Decisions made by electronic vote without a meeting (by email) require a majority vote of all voting members of the TSC.
Decisions regarding TSC member removal should include votes from all the TSC members excluding the member in question. At least two-thirв (⅔) voting members should agree with this decision.
When a vote is required, quorum check should be validated, and if quorum is reached the vote can proceed. Votes can usually be taken during a meeting or via email.
The guidance on how to run a vote during a meeting is here.
A voting procedure through email:
- Discussion about the proposed topic would have already happened in a email thread or during previous meetings to express the issues and opinions.
- The instigator sends the vote email to the TSC members. He or she should describe the issue with no ambiguity, define the date and time for the end of the vote period, and propose the voting options (e.g., “yes”/”no” or a list of alternatives).
- Votes are expressed by replying to the email. Voters can change their vote during the timeframe.
- At the end of the vote period, the instigator tallies the number of final votes and reports the results.
The OpenFL Project has been established as OpenFL a Series of LF Projects, LLC. OpenFL Project participants will comply with the policies of LF Projects as may be adopted and amended by LF Projects, including, without limitation the policies listed at https://lfprojects.org/policies/.
OpenFL Project participants acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the OpenFL Project.
Except as described below, all contributions to the OpenFL Project are subject to the following:
- All new inbound code contributions to the OpenFL Project must be made using the Apache License, Version 2.0 available at http://www.apache.org/licenses/LICENSE-2.0 (the “Project License”).
- All new inbound code contributions must also be accompanied by a Developer Certificate of Origin (http://developercertificate.org) sign-off in the source code system that is submitted through a TSC-approved contribution process which will bind the authorized contributor and, if not self-employed, their employer to the applicable license;
- All outbound code will be made available under the Project License.
- Documentation will be received and made available by the OpenFL Project under the Creative Commons Attribution 4.0 International License (available at http://creativecommons.org/licenses/by/4.0/).
The OpenFL Project may seek to integrate and contribute back to other open source projects (“Upstream Projects”). In such cases, the OpenFL Project will conform to all license requirements of the Upstream Projects, including dependencies, leveraged by the OpenFL Project. Upstream Project code contributions not stored within the OpenFL Project’s main code repository will comply with the contribution process and license terms for the applicable Upstream Project.
The TSC may approve the use of an alternative license or licenses for inbound or outbound contributions on an exception basis. To request an exception, please describe the contribution, the alternative open source license(s), and the justification for using an alternative open source license for the Project. License exceptions must be approved by a two-thirds vote of the entire TSC.
Contributed files should contain license information, such as SPDX short form identifiers, indicating the open source license or licenses pertaining to the file.