Open Technology Fund - F3 - (July 2022)

Updated version with @aschrijver proposal included. Excellent.


Hi [redacted],

In order to elaborate on the high-level concept note, I chose to answer with concrete examples, facts and details. Please let me know if this answers your open questions. I’d be happy to provide additional information.

I would like to emphasize that the software forge centralization problem F3 addresses, although widely acknowledged, is not funded and only handful of people worldwide are making concrete work to solve it. It is not just relevant to Internet Freedom, but impacts the entire corpus of Free Software. In this regard F3 covers the same breadth of concerns that the reproducible software project does.

Our society, and especially our communication and information sources, depend on complex technology, which is often and increasingly centralized. The power to control them is in the hands of governments and large corporations, that may not have the best interests and needs of the human citizens and users in mind. For underprivileged people living in oppression the need for empowerment is most urgent. Open information access is at the basis of the ability for people to be informed, to reveal injustices and expose censorship. Freedom of expression and other fundamental human rights depend on the control over the technology one uses, and having the ability to participate in its creation. The means for affected people in the region to wield the full range of software development tools is crucial to support important activism work. The F3 specification is an important enabler of that, and part of a larger vision of “Liberating Free Software Development”. Making software be Free is a step toward setting people free.

Cheers

Why this effort is needed in the Internet Freedom space?

The entire software development landscape is overly dominated by just two major players, Github and Gitlab. In particular the position of Github, owned by Microsoft, is problematic when it comes to securing Internet Freedom. Github’s role in the success of open source is often lauded, and partly warranted. For Microsoft / Github providing free access was just a very successful strategy to gain market share and establish network effects. Their centralized platform lies at the heart of a huge ecosystem of software tool vendors that optimized their products to integrate with Github services.

Nowadays literally thousands of projects and millions of software developers are subjected to a strong form of de-facto vendor lock-in. Often without even realizing it. For the Free Software movement this is a threat, as Microsoft does not have their best interest at heart. They follow commercial incentives, and are bound by US regulation. By extension here we find substantial threats to Internet Freedom.

There are numerous examples on how these threats materialize in practice.

  • Geopolitical affiliation: Github as US-based corporation must comply to foreign policy and Trade Control and block people and projects from countries that are at odds with USA from accessing their platform. They apply a broad brush to assure they are in compliance, as this Tweet by Sebastian Slomski demonstrates. Once blocked it is very hard to find recourse or reparation.

  • Corporate, governmental and military influences: As a for-profit US enterprise Microsoft / Github is intent to maximize revenue and profits. Their most lucrative contracts are with partners that are not known to be favorable to the same Internet Freedoms we as humanity crave. How controversial these often secretive and shady deals are is detailed in this Article by The Atlantic.

  • Surveillance capitalism: Like all Big Tech companies Microsoft / Github is a significant player in the widespread harvesting and trade of people’s personal data. Interactions of Internet Freedom activists on the platform are no exception to that, and may provide a wealth of information. Not only do US intelligence agencies likely have backdoors to the platform, but once information enters the Wild West information markets it can end up anywhere. Like in the hands of oppressive regimes.

  • Artificial intelligence: The rise of AI has brought data collection to new heights. Github recently launched CoPilot to help with coding, and in the process ingested all open source project on their platform regardless of their license. Under “fair use” regulation you may find your open source code being regurgitated in proprietary projects. AI systems are also monitoring Terms of Service breaches, making many mistakes in the process. Policy is to err on the side of caution. Microsoft is involved the in the ongoing AI arms race and works on numerous different AI projects, where there’s no telling how they’ll affect our Internet Freedom in the long run. Not having our data available, especially for oppressed people and activists is not more than prudent.

  • Market dominance: Microsoft continues to increase and fortify their dominant position. Known for their Embrace, Extend and Extinguish (EEE) strategies they will not hesitate to bend open ecosystems to their will, thwart open standards, and increasingly monetize the services for those who are captive to their platform. Many vendor lock-in aspects are directly detrimental to the conditions needed to assure Internet Freedom:

    • Unilateral changes to development features, such as deprecating API functionality, occur at rapid pace and are hard to adapt to by open projects that have only limited resources at their disposal.

    • Proprietary nature of large parts of the product portfolio as well as the services offered by 3rd-party vendors hamper reproducible builds. For instance the continuous integration / continuous deployment Security First umbrella tools rely on CircleCI. And the anti-censorship nthLink project depends on Github Actions.

    • Github does not offer a migration path for software projects to move off their platform. There are no open data formats to export to. For example, having an intricate project, Gitea found it impossible to move off of Github and self-host their own software project. After five years the migration effort is still ongoing. Other forge software, like Github and Gitea only provide partial migration from Github for specific use cases.

To a much lesser extent the points listed above also apply to Gitlab. Its positioning is already more directed towards enterprises, and they are limiting free services they offer. Gitlab is a prime candidate for acquisition by another tech giant in the future, triggering a disruption in many open projects now using this code forge.

Stacked against these 2 giant players we find a small number of Free Software projects, like the aforementioned Gitea. Projects that have huge potential. But also ones that are deployed as lonely hard to find self-hosted islands. F3 is instrumental for bridging divides. In addition efforts are underway to make individual code forges part of the decentralized Fediverse, and thus glue them together. The F3 open data exchange format is also part of that effort.

How could this project impact the FOSS community?

Long term it would transform the FOSS online development environment from being centralized and proprietary into being a constellation of federated Free Software forges communicating with each other. It has been twenty years since SourceForge was created, with the same centralization problem as GitHub. F3 is a stepping stone for the FOSS community to reclaim ownership of the tools that they use daily to develop software.

Short term it would allow:

  • A software project to be exported in the F3 format from GitHub and imported into GitLab or Gitea using the same format
  • A developer to file a bug report on GitHub using the F3 format and importing it into GitHub without creating an account on GitHub
  • Mirroring issues from GitHub into GitLab or Gitea to receive notifications without requiring a GitHub account

How would this project provide long-term support to users at risk?

Durable self contained distribution on read-only media

It is common for people living in authoritarian regimes to procure software using physical media like CDs and flash drives. In such cases, only the source code is available since bug tracker history and pull request histories are not available in a downloadable format. F3 will allow developers in authoritarian regimes to setup self-contained, self-sustainable development shops with the full knowledge and experience of the project’s global community. When combined with Git, F3 not only provides a downloadable format but it also supports an efficient synchronization method.

Long term preservation of the software supply chain

Here is an hypothetical use case relevant to human right defenders in need of long term support:

  • In 2022 https://www.nthlink.com/ is used to setup on mobile phones and used by human right defenders in a country that is under an oppressive regime
  • Five years later, in 2027, the mobile phones need to be replaced and the application re-installed, with small modifications because the operating system has changed

With F3, the entire project including the build process that makes nthlink reproducible, has been stored in 2022. It only relies on Free Software that was also stored to make the build process durable. In 2027 they can be re-used to build a new version with small modifications and be re-installed on new phones. The effort is minimal.

Without F3, the build environment provided by GitHub has changed and it is no longer possible to use the deprecated 2022 build process. The nthlink application as it existed in 2022 can no longer be used: it is not supported for newer phones. Upgrading the application would require training the users with the new interface and functionalities. The mobile phones that broke down cannot be easily replaced, a larger effort is required although the 2022 application is still relevant and useful in this particular context. The solution designed in 2022 was made obsolete because the software project could not be archived together with its build process using an Open Standard.

What differences will this project make for developers on a practical level?

Free Software developers will be able to:

Track issues relevant to their software project across software forges and processes (see the 2021 user research report on this topic).

Migrate and mirror software projects from one software forge to another.

Reduce the complexity of implementing software forge migrations. Instead of maintaining a migration process from

  • GitHub to Gitea,
  • GitHub to GitLab,
  • GitHub to GitHub
  • Gitea to GitHub,
  • Gitea to GitLab,
  • Gitea to Gitea
  • GitLab to GitHub,
  • GitLab to Gitea,
  • GitLab to GitLab
  • etc.

With F3 it will only be necessary to maintain a migration process from:

  • GitHub to F3
  • Gitea to F3
  • GitLab to F3
  • F3 to GitHub
  • F3 to GitLab
  • F3 to Gitea

What are your thoughts on the adoption efforts?

Wide adoption of F3 is extremely difficult, long term. But can be done incrementally.

The ultimate adoption of F3 requires:

  • a concise, precise and unambiguous documentation
  • endorsement by a standard body
  • complete and reliable reference implementations in multiple programming languages
  • native integration in all major software forges

The primary adoption blocker is that GitHub is unlikely to support F3 or any other Open Format facilitating software project migration.

An incremental adoption should start by:

  • limiting the scope, with a bottom up approach, using the existing Gitea format
  • providing a reference implementation in Go
  • focusing on practical advantages this reference implementation bring to Free Software developers (i.e. cross forges issue tracking)

Further iterations would expand the scope of the F3 specifications and provide additional practical advantages to drive the change.

Can you detail the community consultation you engaged with that would support this idea/project? What specific communities are in need of this project and have expressed that need?

  • Software forge developers, system administrators and Free Software developers were interviewed as part of the user research conducted in 2021. They expressed the need for communication between software forges. They explained, by providing concrete examples from their personal experience, the practical problems that arise because such communication does not exist.
  • The communities referenced in the State of the Forge Federation: 2021 to 2023 were consulted and reviewed the document which explains F3 in context. They include software forge developers (Gitea), software forge system administrators (Codeberg) and Free Software developers
  • In 2021 the relevance of an interchange format (not yet named F3) in the context of the federation of software forges was explained during the Next Generation Internet webinar on Linked Data
  • In January 2022 the idea matured and was explained as an incremental import/export during a webinar on Forge Federation

Submitted as a reply September 20th, 2022.


Hi [redacted],

In order to elaborate on the high-level concept note, I chose to answer with concrete examples, facts and details. Please let me know if this answers your open questions. I’d be happy to provide additional information.

I would like to emphasize that the software forge centralization problem F3 addresses, although widely acknowledged, is not funded and only a handful of people worldwide are making concrete work to solve it. It is not just relevant to Internet Freedom, but impacts the entire corpus of Free Software. In this regard F3 covers the same breadth of concerns that the reproducible software project does.

Our society, and especially our communication and information sources, depend on complex technology, which is often and increasingly centralized. The power to control them is in the hands large corporations, that may not have the best interests and needs of the human citizens and users in mind. For underprivileged people living in oppression the need for empowerment is most urgent. Open information access is at the basis of the ability for people to be informed, to reveal injustices and expose censorship. Freedom of expression and other fundamental human rights depend on the control over the technology one uses, and having the ability to participate in its creation. The means for affected people in the region to wield the full range of software development tools is crucial to support activism work. The F3 specification is a critical enabler of that, and part of a larger vision of “Liberating Free Software Development”. Making software be Free is a step toward setting people free.

Cheers

Why this effort is needed in the Internet Freedom space?

The entire software development landscape is overly dominated by just two major players, Github and Gitlab. In particular the position of Github, owned by Microsoft, is problematic when it comes to securing Internet Freedom. Github’s role in the success of Free Software is often lauded, and partly warranted. For Microsoft / Github providing free access was just a very successful strategy to gain market share and establish network effects. Their centralized platform lies at the heart of a huge ecosystem of software tool vendors that optimized their products to integrate with Github services.

Nowadays literally thousands of projects and millions of software developers are subjected to a strong form of de-facto vendor lock-in. Often without even realizing it. For the Free Software movement this is a threat, as Microsoft does not have their best interest at heart. They follow commercial incentives, and are bound by US regulation. By extension here we find substantial threats to Internet Freedom.

There are numerous examples on how these threats materialize in practice.

  • Geopolitical affiliation: Github as US-based corporation must comply to foreign policy and Trade Control and block people and projects from countries that are at odds with USA from accessing their platform. They apply a broad brush to assure they are in compliance, as this Tweet by Sebastian Slomski demonstrates. Once blocked it is very hard to find recourse or reparation.

  • Corporate, governmental and military influences: As a for-profit US enterprise Microsoft / Github intends to maximize revenue and profits. Their most lucrative contracts are with partners that are not known to be favorable to the same Internet Freedoms we, as humanity, crave. How controversial these often secretive and shady deals are is detailed in this Article by The Atlantic.

  • Surveillance capitalism: Like all Big Tech companies Microsoft / Github is a significant player in the widespread harvesting and trade of people’s personal data. Interactions of Internet Freedom activists on the platform are no exception to that, and may provide a wealth of information. Not only do US intelligence agencies likely have backdoors to the platform, but once information enters the Wild West information markets it can end up anywhere. Like in the hands of oppressive regimes.

  • Artificial intelligence: The rise of AI has brought data collection to new heights. Github recently launched CoPilot to help with coding, and in the process ingested all Free Software projects on their platform. Under “fair use” regulation you may find your code being regurgitated in proprietary projects. AI systems are also monitoring Terms of Service breaches, making many mistakes in the process. Policy is to err on the side of caution. Microsoft is involved in the the ongoing AI arms race and works on numerous different AI projects. There’s no telling how they’ll affect our Internet Freedom in the long run. Not having our data available, especially for oppressed people and activists is not more than prudent.

  • Market dominance: Microsoft continues to increase and fortify their dominant position. Known for their Embrace, Extend and Extinguish (EEE) strategies they will not hesitate to bend open ecosystems to their will, thwart open standards, and increasingly monetize the services for those who are captive to their platform. Many vendor lock-in aspects are directly detrimental to the conditions needed to assure Internet Freedom:

    • Unilateral changes to development features, such as deprecating API functionality, occur at rapid pace and are hard to adapt to by open projects that have only limited resources at their disposal.

    • Proprietary nature of large parts of the product portfolio as well as the services offered by 3rd-party vendors hamper reproducible builds. For instance the continuous integration / continuous deployment Security First umbrella tools rely on CircleCI. And the anti-censorship nthLink project depends on Github Actions.

    • Github does not offer a migration path for software projects to move off their platform. There are no open data formats to export to. For example, having an intricate project, Gitea found it impossible to move off of Github and self-host their own software project. After five years the migration effort is still ongoing. Other forge software, like GitLab and Gitea only provide partial migration from Github for specific use cases.

To a much lesser extent the points listed above also apply to Gitlab. Its positioning is already more directed towards enterprises, and they are limiting free services they offer. GitLab is a prime candidate for acquisition by another tech giant in the future, triggering a disruption in many projects now using this code forge.

Stacked against these two giant players we find a small number of Free Software projects, like the aforementioned Gitea. Projects that have huge potential. But also ones that are deployed as lonely hard to find self-hosted islands. F3 is instrumental for bridging divides. In addition efforts are underway to make individual code forges part of the decentralized Fediverse, and thus glue them together. The F3 open data exchange format is also part of that effort.

How could this project impact the FOSS community?

Long term it would transform the FOSS online development environment from being centralized and proprietary into being a constellation of federated Free Software forges communicating with each other. It has been twenty years since SourceForge was created, with the same centralization problem as GitHub. F3 is a stepping stone for the FOSS community to reclaim ownership of the tools that they use daily to develop software, to no longer be under the influence of two global corporation, Microsoft an GitLab.

Short term it would allow:

  • A software project to be exported in the F3 format from GitHub and imported into a self hostead GitLab or Gitea using the same format
  • A developer to file a bug report on GitHub using the F3 format without the need to create an account, provide personal data and agree to restrictive terms and conditions
  • Mirroring of issues from GitHub into a self hosted GitLab or Gitea and receive notifications when they change

How would this project provide long-term support to users at risk?

Durable self contained distribution on read-only media

It is common for people living in authoritarian regimes to procure software using physical media like CDs and flash drives. In such cases, only the source code is available since bug tracker, pull request etc. are not available in a downloadable format. F3 will allow developers in authoritarian regimes to setup self-contained, self-sustainable development shops with the full knowledge and experience of the project’s global community. When combined with Git, F3 not only provides a downloadable format but it also supports an efficient synchronization method.

Long term preservation of the software supply chain

Here is an hypothetical use case relevant to human right defenders in need of long term support:

  • In 2022 https://www.nthlink.com/ is used to setup on mobile phones and used by human right defenders in a country that is under an oppressive regime
  • Five years later, in 2027, the mobile phones need to be replaced and the application re-installed, with small modifications because the operating system has changed

With F3, the entire project including the build process that makes nthlink reproducible, has been stored in 2022. It only relies on Free Software that was also stored to make the build process durable. In 2027 they can be re-used to build a new version with small modifications and be re-installed on new phones. The effort is minimal.

Without F3, the build environment provided by GitHub has changed and it is no longer possible to use the now deprecated 2022 build process. The nthlink application as it existed in 2022 can no longer be used: it is not supported for newer phones. Upgrading the application would require training the users with the new interface and functionalities. The mobile phones that broke down cannot be easily replaced, a larger effort is required although the 2022 application is still relevant and useful in this particular context. The solution designed in 2022 was made obsolete because the software project could not be archived together with its build process using an Open Standard.

What differences will this project make for developers on a practical level?

Free Software developers will be able to:

Track issues relevant to their software project across software forges and processes (see the 2021 user research report on this topic).

Migrate and mirror software projects from one software forge to another.

Reduce the complexity of implementing software forge migrations. Instead of maintaining a migration process from

  • GitHub to Gitea,
  • GitHub to GitLab,
  • GitHub to GitHub
  • Gitea to GitHub,
  • Gitea to GitLab,
  • Gitea to Gitea
  • GitLab to GitHub,
  • GitLab to Gitea,
  • GitLab to GitLab
  • etc.

With F3 it will only be necessary to maintain a migration process from:

  • GitHub to F3
  • Gitea to F3
  • GitLab to F3
  • F3 to GitHub
  • F3 to GitLab
  • F3 to Gitea

What are your thoughts on the adoption efforts?

Wide adoption of F3 is difficult to achieve, it requires a long term effort. But can be done incrementally.

The adoption of F3 will require:

  • endorsement by a standard body
  • a concise, precise and unambiguous documentation
  • complete and reliable reference implementations in multiple programming languages
  • native integration in all major software forges

At present the primary adoption blocker is that GitHub is unlikely to support F3 or any other Open Format facilitating software project migration and mirroring.

An incremental adoption should start by:

  • creating the format with a bottom up approach, using the existing Gitea format
  • providing a reference implementation in one language only Go chosen to be linkable with other languages
  • focusing on practical advantages this reference implementation brings to Free Software developers (i.e. cross forges issue tracking)

Further iterations will then expand the scope of the F3 specifications and provide additional practical advantages to drive the change.

Can you detail the community consultation you engaged with that would support this idea/project? What specific communities are in need of this project and have expressed that need?

The Free Software community at large has been aware that centralized software forges is a problem for the entire corpus of FLOSS for over two decades:

In 2021 User Research was conducted to identify the need. It has never been done before and involved software forge developers, system administrators and Free Software developers. The result was published in June 2021 in a report. They expressed the need for communication between software forges. They explained, by providing concrete examples from their personal experience, the practical problems that arise because such communication does not exist.

The communities referenced in the State of the Forge Federation: 2021 to 2023 were consulted and reviewed the document which explains F3 in context. They include software forge developers (Gitea), software forge system administrators (Codeberg) and Free Software developers.

In 2021 the relevance of an interchange format (not yet named F3) in the context of the federation of software forges was explained during the Next Generation Internet webinar on Linked Data. In January 2022 the idea matured and was explained as an incremental import/export during a webinar on Forge Federation

Sent today:


Hi [redacted],

This is my first time and I’m not sure what to expect in terms of timeline. Would you be so kind as to give me a hint regarding the expected delay before a determination is made?

Thanks a lot for the help

Received today:

image

image


From: OTF
Subject: Your application to Open Technology Fund: Friendly Forge Format (F3) - an Open Standard for autonomous Free Software

Dear Loïc Dachary,

We’ve reviewed your Concept note and think it could be a good fit for OTF funding. We would like to invite you to submit a Proposal with more details about your project. You will receive a second email linking to a determination message with detailed feedback.

Please review our Proposal Guide at General Funding Guidelines - OTF Application Guidebook to learn more about the information we’d like to see. In the proposal please also address the feedback we provided in the concept note determination.

Here is the link to start creating your proposal: OTF Apply | Login
If you have any questions, please submit them here: OTF Apply | Login

The system will allow you to save a draft of your proposal as you work on it. When you feel it is ready for our review, please click the “Submit” button and we’ll know to take a look at it. We’ll reply to you with feedback on your Proposal as quickly as possible.

If you have any issues accessing the submission system or other general inquiries, please email us at hello@opentech.fund

Kind Regards,
The OTF Team


From: OTF
Subject: Your application to Open Technology Fund: Friendly Forge Format (F3) - an Open Standard for autonomous Free Software

Dear Loïc Dachary,

Your application has been reviewed and the outcome is: Approved

We very much appreciate your submission to Open Technology Fund for consideration. Upon evaluation of your submission, we have decided to invite you to submit a full proposal. The deadline for submitting your proposal is 31 October. Please review the feedback at the bottom of this email carefully, and integrate it into your proposal as needed. Meeting the deadline is essential. Proposals that are received after the proposed deadline may be considered in the next round of review. For significant delays, a proposal may be declined and required to re-apply for further consideration. Please note that the word limits on the application are advisory, and while we don’t recommend exceeding them significantly, you can still submit your proposal if you go over the limits.
You can access your proposal draft via the application link included in this message. The application system will allow you to save a draft of your Proposal as you work on it. When you feel it is ready for our review, please click “Submit” and we’ll know to take a look at it.
You can find more information about what we’d like to see in your proposal in our Proposal Guide (Appendix II: Proposal Guide - OTF Application Guidebook). If you have any questions or comments about the feedback provided below, please use the communications tab on your proposal page.
Feedback:

We appreciate very much your engagement with your feedback and thank you for the additional input. Please make sure to integrate your feedback into the proposal also, and please elaborate on the community engagement plan.

Read the full determination here: https://apply.opentech.fund/apply/submissions/13789/determination/9004/

Link to your application: https://apply.opentech.fund/apply/submissions/13789/
If you have any questions, please submit them here: https://apply.opentech.fund/apply/submissions/13789/#communications

See our guide for more information: General Funding Guidelines - OTF Application Guidebook

If you have any issues accessing the submission system or other general inquiries, please email us at hello@opentech.fund

Kind Regards,
The OTF Team


Open Technology Fund
https://www.opentech.fund

1 Like

Sent today via the web interface.


Hi,

Thanks a lot for the opportunity to submit a proposal, I’ll work on it right away. After reviewing the Guide, I have a few questions and would very appreciate your answers to help me move forward as efficiently as possible.

Thanks a lot for your help!

Where does the “community engagement plan” belong?

In the mail inviting me to write the proposal it is suggested to “make sure to integrate your feedback into the proposal also, and please elaborate on the community engagement plan”. I’m unsure in which section to include this and would appreciate your guidance on the matter. Maybe it should be split into multiple sections instead of a single one?

  • Section “describe your project’s objectives and related activities, and resulting deliverables if applicable.”. The community engagement plan requires work and describing the objectives and activities in a concrete way seem sensible. That’s where I would be inclined to include it.
  • Section “describe your approach to monitoring and evaluating the outcomes and impact of this effort.”. There should be a part about the community engagement here too.
  • Section “What’s your long term strategy for this project beyond OTF support?”. Engagement of the community is how F3 will be sustainable long term, after OTF allowed to bootstrap the work. Maybe the community does not belong here. But even in this case it should include a paragraph explaining how it relates.

What is the timeline?

In order to plan for the project it would be useful to get an idea of how long it would take for the proposal to be accepted or declined. For instance, is it realistic to think that the project could start in March 2023 in the best case scenario? Or September 2023?

What is the expected granularity of the task descriptions?

Here is an example to illustrate my question using a high level task:“Go package reference implementation”. The tasks could be described as a bullet list (let say this is level one):

  • An API for integration in a forge written in Go
  • Validation of a F3 archive (JSON Schema validation, VCS sanity checks)
  • Import and Export support for Gitea and GitLab
  • Dataset generators and fixtures to verify the conformance with the specifications

Each task could be further refined (let say this is level two):

Is level one expected? Or level two? Or something different?

Should tasks be associated with precise deliverables?

For instance the task “Go implementation to import / export milestones” could be associated to a deliverable such as “A merged pull request that implements the feature together with tests and documentation, publicly available at example.com”.

Is it expected in the proposal? Or is it to be detailed when and if the proposal is accepted?

1 Like

As a first step I consolidated the concept note and the answers to the followup questions within the template required for submitting the proposal. For each section I also added links to the corresponding guide.

Consolidated proposal draft

Project Title*

Friendly Forge Format (F3) - an Open Standard for autonomous Free Software

What is your name?*

Loïc Dachary

What email address should we use to contact you?*

loic@dachary.org

How much funding do you estimate you will need? (In US Dollars)

60000

Please include a full description of your project, including the problem statement, your approach, and the main beneficiaries.

Please succinctly describe the key objectives of the proposed effort, the challenges it intends to address and what gap it fills. Please also describe how this will benefit people living in repressive environments and what outcome and impact it will have.

See the corresponding guide section

Most software designed to protect HRD, journalists and whistleblowers is FLOSS. Each binary release is carefully verified by a sophisticated supply chain to spot vulnerabilities and regressions.

When a feature is missing, developers living under an oppressive regime have a strong motivation to modify the source code. But they are missing the information to run the supply chain independently. Their sub-standard release may put at risk the very people they are trying to help.

F3 is a new Open File Format that combines the source code with all the information that enables developers to produce high quality releases.

The software forge centralization problem F3 addresses, although widely acknowledged, is not funded and only a handful of people worldwide are making concrete work to solve it. It is not just relevant to Internet Freedom, but impacts the entire corpus of Free Software. In this regard F3 covers the same breadth of concerns that the reproducible software project does.

Our society, and especially our communication and information sources, depend on complex technology, which is often and increasingly centralized. The power to control them is in the hands large corporations, that may not have the best interests and needs of the human citizens and users in mind. For underprivileged people living in oppression the need for empowerment is most urgent. Open information access is at the basis of the ability for people to be informed, to reveal injustices and expose censorship. Freedom of expression and other fundamental human rights depend on the control over the technology one uses, and having the ability to participate in its creation. The means for affected people in the region to wield the full range of software development tools is crucial to support activism work. The F3 specification is a critical enabler of that, and part of a larger vision of “Liberating Free Software Development”. Making software be Free is a step toward setting people free.

Problem statement

There is no standard file format to share the content of a software forge (e.g. git repository, issues, etc.), and only some of them provide an undocumented internal format. It is possible to use the forgefed vocabulary to send a message about a particular detail (i.e. an individual commit or an issue) via the ActivityPub protocol. But the receiving forge may not know the context in which this information can be interpreted because it cannot conveniently obtain it. As a whole, a software project is a large dataset that is made of numerous interconnected elements stored in a strongly consistent state. Without a standardized file format, interoperability between forges is very difficult.

The Friendly Forge Format (abbreviated F3) is an Open File Format for storing the information from a forge such as issues, pull/merge requests, milestones, release assets, etc. as well as the associated VCS (Git, Mercurial, etc.).

F3 is designed to exchange the state of a software project between GitHub, GitLab, Gitea, etc. for backup, mirroring or federation.

F3 is essential for a forge to provide key requirements:

  • Portability: the entire state of a software project can be dumped and restored at a later time, on a different development environment.
  • Versatility: when published and updated as a F3 archive, a software project effectively is Open Data on which an unlimited range of applications can rely, even outside of the forge domain
  • Consistency: it provides a common language to use when talking about the forge related domains
  • Trust: cryptographic signatures on each F3 dump guard against malicious or unintentional tampering that could compromise the integrity of a software project

And it unlocks the following use cases:

  • Analytics: data mining the contents of files is more practical than issuing a large number of queries to an API
  • Mirror: issues and all other aspects of a software project can be conveniently mirrored from a forge to another by publishing a F3 archive in a VCS and acting on the changes
  • Archival: storing F3 archives in a VCS makes it easier for them to be preserved in long term archives such as Software Heritage
  • Reporting: forgefed messages can be created from F3 and sent via the ActivityPub protocol

Why this effort is needed in the Internet Freedom space?

The entire software development landscape is overly dominated by just two major players, Github and Gitlab. In particular the position of Github, owned by Microsoft, is problematic when it comes to securing Internet Freedom. Github’s role in the success of Free Software is often lauded, and partly warranted. For Microsoft / Github providing free access was just a very successful strategy to gain market share and establish network effects. Their centralized platform lies at the heart of a huge ecosystem of software tool vendors that optimized their products to integrate with Github services.

Nowadays literally thousands of projects and millions of software developers are subjected to a strong form of de-facto vendor lock-in. Often without even realizing it. For the Free Software movement this is a threat, as Microsoft does not have their best interest at heart. They follow commercial incentives, and are bound by US regulation. By extension here we find substantial threats to Internet Freedom.

There are numerous examples on how these threats materialize in practice.

  • Geopolitical affiliation: Github as US-based corporation must comply to foreign policy and Trade Control and block people and projects from countries that are at odds with USA from accessing their platform. They apply a broad brush to assure they are in compliance, as this Tweet by Sebastian Slomski demonstrates. Once blocked it is very hard to find recourse or reparation.
  • Corporate, governmental and military influences: As a for-profit US enterprise Microsoft / Github intends to maximize revenue and profits. Their most lucrative contracts are with partners that are not known to be favorable to the same Internet Freedoms we, as humanity, crave. How controversial these often secretive and shady deals are is detailed in this Article by The Atlantic.
  • Surveillance capitalism: Like all Big Tech companies Microsoft / Github is a significant player in the widespread harvesting and trade of people’s personal data. Interactions of Internet Freedom activists on the platform are no exception to that, and may provide a wealth of information. Not only do US intelligence agencies likely have backdoors to the platform, but once information enters the Wild West information markets it can end up anywhere. Like in the hands of oppressive regimes.
  • Artificial intelligence: The rise of AI has brought data collection to new heights. Github recently launched CoPilot to help with coding, and in the process ingested all Free Software projects on their platform. Under “fair use” regulation you may find your code being regurgitated in proprietary projects. AI systems are also monitoring Terms of Service breaches, making many mistakes in the process. Policy is to err on the side of caution. Microsoft is involved in the the ongoing AI arms race and works on numerous different AI projects. There’s no telling how they’ll affect our Internet Freedom in the long run. Not having our data available, especially for oppressed people and activists is not more than prudent.
  • Market dominance: Microsoft continues to increase and fortify their dominant position. Known for their Embrace, Extend and Extinguish (EEE) strategies they will not hesitate to bend open ecosystems to their will, thwart open standards, and increasingly monetize the services for those who are captive to their platform. Many vendor lock-in aspects are directly detrimental to the conditions needed to assure Internet Freedom:
    • Unilateral changes to development features, such as deprecating API functionality, occur at rapid pace and are hard to adapt to by open projects that have only limited resources at their disposal.
    • Proprietary nature of large parts of the product portfolio as well as the services offered by 3rd-party vendors hamper reproducible builds. For instance the continuous integration / continuous deployment Security First umbrella tools rely on CircleCI. And the anti-censorship nthLink project depends on Github Actions.
    • Github does not offer a migration path for software projects to move off their platform. There are no open data formats to export to. For example, having an intricate project, Gitea found it impossible to move off of Github and self-host their own software project. After five years the migration effort is still ongoing. Other forge software, like GitLab and Gitea only provide partial migration from Github for specific use cases.

To a much lesser extent the points listed above also apply to Gitlab. Its positioning is already more directed towards enterprises, and they are limiting free services they offer. GitLab is a prime candidate for acquisition by another tech giant in the future, triggering a disruption in many projects now using this code forge.

Stacked against these two giant players we find a small number of Free Software projects, like the aforementioned Gitea. Projects that have huge potential. But also ones that are deployed as lonely hard to find self-hosted islands. F3 is instrumental for bridging divides. In addition efforts are underway to make individual code forges part of the decentralized Fediverse, and thus glue them together. The F3 open data exchange format is also part of that effort.

Beneficiaries

Human Right Defenders, journalists and whistleblowers who have specific needs to protect the privacy of their communication.

During my time at the Freedom of the Press Foundation and La Maison des Lanceurs d’Alerte (2017 to 2021), I provided custom development and the digital infrastructure they required. This experience allowed me to witness first hand the problem that centralized forges such as GitHub pose to the supply chain of a software protecting the privacy of communications.

When a nation state has the means to coerce an intermediary such as GitHub to provide information about its users, attempting to develop a particular feature designed to evade surveillance in a given regional context is hazardous. The state will have advance warning of this attempt and can work around it.

The software developers who are the most motivated to work on adapting software to address the threat from an oppressive regime are the one living in the country. Thanks to numerous Free Software projects such as Tor or SecureDrop, they do not need to start from scratch. They can get the source code. They can also setup a self-hosted forge such as GitLab or Gitea and dedicate machines to continuous integration that could carefully verify their modifications is not introducing a vulnerability that would expose the very people they are trying to protect.

But here lies the problem: they have no way to conveniently get a copy of the quality assurance process that includes CI (continuous integration), CD (continuous delivery), pull requests, issues, releases. They are missing a large part of what makes the software reliable and resistant to attackers: it stays on the centralized forges. Since a software release is only as good as the tools involved in the quality & assurance process, their work is made significantly more difficult.

With F3 they will be able to get a software project as a whole, including the configuration of the CI and CD process. Every change they make will undergo the same verification than the original software and the outcome will be as robust and reliable. More importantly, they will be able to do that in complete autonomy, without frequent interactions with a centralized forge that could expose the

How would this project provide long-term support to users at risk?

Durable self contained distribution on read-only media

It is common for people living in authoritarian regimes to procure software using physical media like CDs and flash drives. In such cases, only the source code is available since bug tracker, pull request etc. are not available in a downloadable format. F3 will allow developers in authoritarian regimes to setup self-contained, self-sustainable development shops with the full knowledge and experience of the project’s global community. When combined with Git, F3 not only provides a downloadable format but it also supports an efficient synchronization method.

Long term preservation of the software supply chain

Here is an hypothetical use case relevant to human right defenders in need of long term support:

  • In 2022 https://www.nthlink.com/ is used to setup on mobile phones and used by human right defenders in a country that is under an oppressive regime
  • Five years later, in 2027, the mobile phones need to be replaced and the application re-installed, with small modifications because the operating system has changed

With F3, the entire project including the build process that makes nthlink reproducible, has been stored in 2022. It only relies on Free Software that was also stored to make the build process durable. In 2027 they can be re-used to build a new version with small modifications and be re-installed on new phones. The effort is minimal.

Without F3, the build environment provided by GitHub has changed and it is no longer possible to use the now deprecated 2022 build process. The nthlink application as it existed in 2022 can no longer be used: it is not supported for newer phones. Upgrading the application would require training the users with the new interface and functionalities. The mobile phones that broke down cannot be easily replaced, a larger effort is required although the 2022 application is still relevant and useful in this particular context. The solution designed in 2022 was made obsolete because the software project could not be archived together with its build process using an Open Standard.

How could this project impact the FOSS community?

Long term it would transform the FOSS online development environment from being centralized and proprietary into being a constellation of federated Free Software forges communicating with each other. It has been twenty years since SourceForge was created, with the same centralization problem as GitHub. F3 is a stepping stone for the FOSS community to reclaim ownership of the tools that they use daily to develop software, to no longer be under the influence of two global corporation, Microsoft an GitLab.

Short term it would allow:

  • A software project to be exported in the F3 format from GitHub and imported into a self hostead GitLab or Gitea using the same format
  • A developer to file a bug report on GitHub using the F3 format without the need to create an account, provide personal data and agree to restrictive terms and conditions
  • Mirroring of issues from GitHub into a self hosted GitLab or Gitea and receive notifications when they change

What differences will this project make for developers on a practical level?

Free Software developers will be able to:

Track issues relevant to their software project across software forges and processes (see the 2021 user research report on this topic).

Migrate and mirror software projects from one software forge to another.

Reduce the complexity of implementing software forge migrations. Instead of maintaining a migration process from

  • GitHub to Gitea,
  • GitHub to GitLab,
  • GitHub to GitHub
  • Gitea to GitHub,
  • Gitea to GitLab,
  • Gitea to Gitea
  • GitLab to GitHub,
  • GitLab to Gitea,
  • GitLab to GitLab
  • etc.

With F3 it will only be necessary to maintain a migration process from:

  • GitHub to F3
  • Gitea to F3
  • GitLab to F3
  • F3 to GitHub
  • F3 to GitLab
  • F3 to Gitea

Please describe your project’s objectives and related activities, and resulting deliverables if applicable.

What are the activities that will accomplish the project’s goals? What are the outputs or deliverables of each activity? Please be as concrete as possible, so that we understand what you are planning to do.

See the corresponding guide section

Go package reference implementation

A reference implementation of F3 in Go provides:

  • An API for integration in a forge written in Go
  • Validation of a F3 archive (JSON Schema validation, VCS sanity checks)
  • Import and Export support for Gitea and GitLab
  • Dataset generators and fixtures to verify the conformance with the specifications

Milestone: The Go package is published https://pkg.go.dev/

Python package reference implementation

A reference implementation of F3 in Python provides:

  • An API for integration in a forge written in Python
  • Continuous deployment of the F3 documentation
  • The same features as the Go package reference implementation

Milestone: The Python package is published https://pypi.org/

Specification and documentation

The F3 Specification includes:

  • An introduction
  • JSON Schema with embedded documentation
  • Release notes
  • A normative file hierarchy
  • A glossary of terms and their definition

Milestones:

First release

The first F3 release is a bundle that includes:

  • The specifications and documentation
  • The Go reference implementation
  • The Python reference implementation

They are verified to be consistent and tagged with the same version number.

Milestone: simultaneous publication of F3 version 1.0.0 at:

Integration in the Gitea codebase

The F3 Go reference implementation is used as a replacement of the internal format used for repositories dump and restore features in the Gitea codebase.

Milestones: pull request merged in https://forgefriends.org or https://gitea.io

How long will it take? (In Months)

12 months

Please elaborate on the technical feasibility of this effort.

The applicant is expected to provide a succinct description of the technical objectives of the effort, using appropriate terminology. The applicant should also provide any research/documentation of the feasibility/novelty of their technical approach, any hurdles or technical challenges they might encounter in implementation, and what they plan to do about it.

See the corresponding guide section

… we want to understand what the technical objectives of your efforts are, what technology design decisions you’ve made, and why you made those decisions.

An Open Standard is ultimately a single document easily distributed. Updating and publishing the document conveniently requires the tooling provided by software forges. A proposed change is proposed on the forge, discussed and merged. The continuous integration pipeline verifies there are no formatting errors and the development branch is updated. Upon release of the specifications, the continuous delivery pipeline updates the website so the newer version of F3 is distributed to the general public.

This workflow is familiar in the context of a Free Software project but it is less common when developing a standard. It is however more likely to facilitate participation from a large community of developers, a facet that is essential to the long term sustainability of F3.

… you are aware of known challenges you might face implementing those technical objectives, and that you have a plan to address those challenges, and how they may affect the output of the effort.

F3 is a format that contains non trivial information and an ever growing number of objects. A reference implementation with a well defined API is both essential to its adoption and a technical challenge. To reduce the likelyhood of fragmentation (diverging implementations of the F3 format) and minimize the development effort, the choice was made to develop the reference implementation in Go. The Go package can then conveniently be re-used as a module in libraries for other programming languages such as Python or Ruby. It will then be easier for forges such as Gitea (written in Go), GitLab (written in Ruby) or Pagure (written in Python) to rely on this reference implementation instead of implementing its own.

Please describe your usability/UX and accessibility practice for developing this tool.

Does the proposal demonstrate clear external demand for the proposed end product? Does the project demonstrate a high degree of usability and/or accessibility? Is the project targeting a small number of high value or at-risk users, or a broader population? Is the proposed effort appropriate for the intended audience?

See the corresponding guide section

Please describe the scope of this project’s alternative analysis. If the project has been audited before, please briefly describe the scope and outcome of those assessments, providing links to reports if available.

Does the project identify potential unintended consequences? Does it identify how an adversary might use the solution to further their own goals? Does the proposal consider potential illicit uses of the project? Does the proposal identify appropriate tactics for a potentially asymmetric position in relation to an adversary? Does the proposal consider sufficiently whether its approach is offensive or defensive in relation to the problem it is addressing? Does it explain why it has selected this approach (effort, cost, time, etc.)? Does the proposal discuss how the project could be undermined, identify its own deficiencies and limitation, or does it presume there are none? Does the proposal explore short-, medium-, and long‐term strategies from the adversary’s point of view? Does the project increase or decrease known attack surfaces?

See the corresponding guide section

Are there other efforts similar to you what you are proposing? Does your work build on their work? What makes your approach different?

List other similar efforts to this proposed project. OTF expects this to include a review of any available technologies or programs and events that are similar to the project described. We want to understand how your project relates to others or how it can be distinguished from those that already exist. We are also looking for proof of the applicant’s understanding of the current landscape in the domain this project is situated.

See the corresponding guide section

The State of the Forge Federation: 2021 to 2023 published in June 2022 contains a detailed description of the projects related to F3. It is designed to be a building block that can be reused by all of them to facilitate the implementation of forge federation features.

F3 is different from ForgeFed. ForgeFed is an ActivityPub extension with its own vocabulary and models represented in JSON-LD. F3 is an JSON based Open File Format providing a strongly consistent representation of a software project at a given point in time. Despite these differences, there are overlaps: they both need to define a glossary of terms and explain concepts that are common between forges. This already led to contributions to Forgefed and more are expected in the future.

The forgefriends and ForgeFlux forge federation proxies will include F3 in their upcoming releases. This integration will be a showcase demonstrating how the Go and Python API can be used for integration in other software forges.

Deploying F3 in production is challenging because it does not yet have a reassuring reputation of stability and robustness. When problems are discovered, they will require a level of understanding and an investment in time from system administrators that most service providers consider too costly. The Hostea service provider is committed to advance forge federation and will deploy F3 as soon as it is available. It will likely be the first production instance supporting F3.

Please describe your approach to monitoring and evaluating the outcomes and impact of this effort.

Describe how the project’s success will be evaluated and any metrics that will be collected related to the project’s outcomes and impact. By what metrics will you define the successful completion of the project? By what means will you determine that the project was successful in reaching its goals? OTF relies on these mechanisms to track and record the success of the project.

See the corresponding guide section

By what metrics will you define the successful completion of the project?

  • The frequency of stable releases of the F3 format
  • The frequency of stable releases of the F3 reference implementation
  • The number of forge service providers supporting F3
  • The number of developers using F3
  • The number of forges natively supporting F3
  • The number of people (paid staff and volunteers) participating in the evolution of F3 (format and reference implementation)
  • The funding obtained to sustain F3 as a whole

How are you planning to collect that information? And how will you document it?

The Frequency of stable releases is collected from the registry where they are published.

Lists of forge service providers, software forges and service providers are maintained in a repository, sorted to record those using or implementing F3 to keep track of them over time. As F3 becomes more popular it may be difficult to maintain such lists and the only way to collect that information would be to actively poll organizations and people.

People participating in the evolution of F3 are conveniently listed in the changes they authored in the repositories. Some people provide advices instead of authoring a change that is recorded, which makes them more difficult to account for. Such mentoring is however important and relies on the memory of the people collecting the information manually.

The funding is systematically and publicly recorded in a spreadsheet and a forum and can be collected from there.

By what means will you determine that the project was successful in reaching its goals?

  • The F3 stable releases are published at least twice a year
  • All forges natively support F3 (hence all developers and forge providers)
  • There are more volunteers than paid staff
  • The funding covers the cost of the paid staff participating in the making of F3

How will you collect and share learnings from this project?

In the first few years all information worth learning from is expected to be published in the F3 forum. Once a month all messages are browsed and a report is written as a digest. Something similar is done with the pull requests from the F3 specifications and the reference implementation. The authors of the report will do their best to write it in an objective and dispationate way but they will inevitably make choices that reflect their own interest.

This monthly report allows for participation from people who are not engaged daily in the project by providing them with a high level view. In addition to the synchronous communication channel (Matrix chatroom) and the asynchronous communication channel (Forum), a recuring meeting is organized to share learnings with all stakeholders:

  • A monthly report is published to reflect the progress of the F3
  • A monthly videconference is organized and open to the public to discuss the monthly report
  • A presentation of the progress of F3 is made in a synthetic way during a webinar once a year

Do you expect any major milestones during this project?

The first stable release of the F3 format and the Go reference implementation.

What instrument or process will you use to document the impact of this project on your local community, beneficiaries, or Internet freedom ecosystem?

The projects supported by OTF and their dependencies will be approached and invited to participate in User Research initially. Their input will define themes that matter to them and when the implementation is stable, they will be invited to use F3 to solve the problem they have. The impact will be positive if the need observed during the User Research phase is fulfilled by the F3 release.

What’s your long term strategy for this project beyond OTF support?

Sustainability can be measured in different ways. Please explain how this effort will achieve sustainability. This can include funding received from other funders or other revenue models, collaborations with organizations beyond the funding phase, an active community network and others.

From the mail inviting to send an application: “make sure to integrate your feedback into the proposal also, and please elaborate on the community engagement plan”

See the corresponding guide section

… how this effort will achieve sustainability over the funding period and beyond.

F3 needs to evolve to keep up with the evolution of software forges. As new development methods and tools are implemented, F3 must be updated to represent them. If it is to succeed, it will require an active engagement from dozens if not hundred of developers over decades. A likely scenario involves a few full time paid staff whose mission is partly to advance F3 on a technical level (release cycle, online resources, etc.) and partly to enpower a larger community of volunteers (onboarding, training, meetings, roadmaps, etc.).

… funding received from other funders or other revenue models.

During the first years, F3 is bootstraped by seeking funding with OTF, NLnet and European R&D tax relief schemes. The goal is to create the conditions for F3 to be natively supported by each forge and facilitate participation in the maintenance of the F3 by all stakeholders. At which point the organizations developing the forges as well as the service providers selling services based on Free Software forges will have a vested interest in devoting a fraction of their revenue to keep F3 going.

… collaborations with other organizations and your role and relation to communities around your project.

F3 is developped bottom up to become a de-facto standard. As it matures a dialog with standard bodies such as OASIS or W3C will be engaged. The goal is that ultimately one of them supports F3. In the meantime relationships with organizations and people developing software forges (Gitea, GitLab, etc.) are the primary focus because they are involved in making the native support of F3 a reality. Organizations running forges (Framasoft, Codeberg, Gna!, etc.) as well as Free Software providers (Webarchitects, Easter-Eggs, Bearstech, etc.) have an incentive to be early adopters of the F3 reference implementation (to migrate and mirror software projects, for instance). Finally, the Free Software developer community is the primary community involved in User Research to sort out F3 priorities.

… how this project provides resources to others or how others can reuse the resources you develop.

F3 is developped in the context of the forgefriends project, a horizontal community with a radically transparent governance. Anyone and everyone has access to all the resources of the project, subject to their acceptance of the Code of Conduct. The resources developped by F3 are all released under a Free Software license.

Adoption efforts

Wide adoption of F3 is difficult to achieve, it requires a long term effort. But can be done incrementally.

The adoption of F3 will require:

  • endorsement by a standard body
  • a concise, precise and unambiguous documentation
  • complete and reliable reference implementations in multiple programming languages
  • native integration in all major software forges

At present the primary adoption blocker is that GitHub is unlikely to support F3 or any other Open Format facilitating software project migration and mirroring.

An incremental adoption should start by:

  • creating the format with a bottom up approach, using the existing Gitea format
  • providing a reference implementation in one language only Go chosen to be linkable with other languages
  • focusing on practical advantages this reference implementation brings to Free Software developers (i.e. cross forges issue tracking)

Further iterations will then expand the scope of the F3 specifications and provide additional practical advantages to drive the change.

Community consultation and User Research

The Free Software community at large has been aware that centralized software forges is a problem for the entire corpus of FLOSS for over two decades:

In 2021 User Research was conducted to identify the need. It has never been done before and involved software forge developers, system administrators and Free Software developers. The result was published in June 2021 in a report. They expressed the need for communication between software forges. They explained, by providing concrete examples from their personal experience, the practical problems that arise because such communication does not exist.

The communities referenced in the State of the Forge Federation: 2021 to 2023 were consulted and reviewed the document which explains F3 in context. They include software forge developers (Gitea), software forge system administrators (Codeberg) and Free Software developers.

In 2021 the relevance of an interchange format (not yet named F3) in the context of the federation of software forges was explained during the Next Generation Internet webinar on Linked Data. In January 2022 the idea matured and was explained as an incremental import/export during a webinar on Forge Federation

Why are you, and your team members, the right people to work on this project?

You can describe your previous work, link to relevant past projects, or explain other forms of knowledge of the subject matter. We are also interested in learning about your experience in working with users described. Have you worked with them before, how are you connected? Do you consider yourself part of the target audience? Ideally, you can also describe your connections to partners and other relevant actors in the field.

See the corresponding guide section

In 2017 and 2018 I worked on SecureDrop and authored hundreds of commits. I spearheaded the internationalization of the codebase and organized a team of translators in cooperation with Localization Lab. During this time I occasionally worked with journalists and whistleblowers, addressing their needs with training or software development. I spearheaded the User Research effort in SecureDrop in cooperation with Open Source Design.

In 2020 I worked for La Maison des Lanceurs d’Alerte and setup their information system from scratch, training and supporting the legal team, the staff as well as the volunteers. In this context I also provided technical support to whistleblowers in France and abroad when there was a suspicion they could be targeted by state actors or powerful adversaries.

Since January 2021 I worked full time with https://forgefriends.org, https://forgefed.org, https://gitea.io and https://www.softwareheritage.org/ to advance forge federation. I made contributions to the forgefed specification and played an active role in reviving the project with a broader community.

The forgefriends project is a proxy designed to enable federation for software forges that do not yet implement it natively. I participated in forgefriends from the start, in January 2021. I authored most of the code and documentation that exist today. I published activity reports on a monthly basis and organized videoconferences to keep the larger community up to date.

I have worked with the Gitea project since late 2021 to natively implement federation with code contributions.

Please provide a budget narrative explaining the budget required to execute your proposed project.

Please include in your narrative the budget associated with individual objectives, activities and their associated deliverables. Please also include and describe major budget categories associated with this project. In addition to hourly or daily rates for labor, please include estimates of any expenses that would be supported by the requested funds, e.g.consultants, supplies, travel, etc.

See the corresponding guide section

1 Like

Here is first draft of the proposal.

Draft version 1

Project Title*

Friendly Forge Format (F3) - an Open Standard for autonomous Free Software

What is your name?*

Loïc Dachary

What email address should we use to contact you?*

loic@dachary.org

How much funding do you estimate you will need? (In US Dollars)

60000

Please include a full description of your project, including the problem statement, your approach, and the main beneficiaries.

Please succinctly describe the key objectives of the proposed effort, the challenges it intends to address and what gap it fills. Please also describe how this will benefit people living in repressive environments and what outcome and impact it will have.

See the corresponding guide section

Most software designed to protect HRD, journalists and whistleblowers is FLOSS. Each binary release is carefully verified by a sophisticated supply chain to spot vulnerabilities and regressions.

When a feature is missing, developers living under an oppressive regime have a strong motivation to modify the source code. But they are missing the information to run the supply chain independently. Their sub-standard release may put at risk the very people they are trying to help.

F3 is a new Open File Format that combines the source code with all the information that enables developers to produce high quality releases.

The software forge centralization problem F3 addresses, although widely acknowledged, is not funded and only a handful of people worldwide are making concrete work to solve it. It is not just relevant to Internet Freedom, but impacts the entire corpus of Free Software. In this regard F3 covers the same breadth of concerns that the reproducible software project does.

Our society, and especially our communication and information sources, depend on complex technology, which is often and increasingly centralized. The power to control them is in the hands large corporations, that may not have the best interests and needs of the human citizens and users in mind. For underprivileged people living in oppression the need for empowerment is most urgent. Open information access is at the basis of the ability for people to be informed, to reveal injustices and expose censorship. Freedom of expression and other fundamental human rights depend on the control over the technology one uses, and having the ability to participate in its creation. The means for affected people in the region to wield the full range of software development tools is crucial to support activism work. The F3 specification is a critical enabler of that, and part of a larger vision of “Liberating Free Software Development”. Making software be Free is a step toward setting people free.

Problem statement

There is no standard file format to share the content of a software forge (e.g. git repository, issues, etc.), and only some of them provide an undocumented internal format. It is possible to use the forgefed vocabulary to send a message about a particular detail (i.e. an individual commit or an issue) via the ActivityPub protocol. But the receiving forge may not know the context in which this information can be interpreted because it cannot conveniently obtain it. As a whole, a software project is a large dataset that is made of numerous interconnected elements stored in a strongly consistent state. Without a standardized file format, interoperability between forges is very difficult.

The Friendly Forge Format (abbreviated F3) is an Open File Format for storing the information from a forge such as issues, pull/merge requests, milestones, release assets, etc. as well as the associated VCS (Git, Mercurial, etc.).

F3 is designed to exchange the state of a software project between GitHub, GitLab, Gitea, etc. for backup, mirroring or federation.

F3 is essential for a forge to provide key requirements:

  • Portability: the entire state of a software project can be dumped and restored at a later time, on a different development environment.
  • Versatility: when published and updated as a F3 archive, a software project effectively is Open Data on which an unlimited range of applications can rely, even outside of the forge domain
  • Consistency: it provides a common language to use when talking about the forge related domains
  • Trust: cryptographic signatures on each F3 dump guard against malicious or unintentional tampering that could compromise the integrity of a software project

And it unlocks the following use cases:

  • Analytics: data mining the contents of files is more practical than issuing a large number of queries to an API
  • Mirror: issues and all other aspects of a software project can be conveniently mirrored from a forge to another by publishing a F3 archive in a VCS and acting on the changes
  • Archival: storing F3 archives in a VCS makes it easier for them to be preserved in long term archives such as Software Heritage
  • Reporting: forgefed messages can be created from F3 and sent via the ActivityPub protocol

Why this effort is needed in the Internet Freedom space?

The entire software development landscape is overly dominated by just two major players, Github and Gitlab. In particular the position of Github, owned by Microsoft, is problematic when it comes to securing Internet Freedom. Github’s role in the success of Free Software is often lauded, and partly warranted. For Microsoft / Github providing free access was just a very successful strategy to gain market share and establish network effects. Their centralized platform lies at the heart of a huge ecosystem of software tool vendors that optimized their products to integrate with Github services.

Nowadays literally thousands of projects and millions of software developers are subjected to a strong form of de-facto vendor lock-in. Often without even realizing it. For the Free Software movement this is a threat, as Microsoft does not have their best interest at heart. They follow commercial incentives, and are bound by US regulation. By extension here we find substantial threats to Internet Freedom.

There are numerous examples on how these threats materialize in practice.

  • Geopolitical affiliation: Github as US-based corporation must comply to foreign policy and Trade Control and block people and projects from countries that are at odds with USA from accessing their platform. They apply a broad brush to assure they are in compliance, as this Tweet by Sebastian Slomski demonstrates. Once blocked it is very hard to find recourse or reparation.
  • Corporate, governmental and military influences: As a for-profit US enterprise Microsoft / Github intends to maximize revenue and profits. Their most lucrative contracts are with partners that are not known to be favorable to the same Internet Freedoms we, as humanity, crave. How controversial these often secretive and shady deals are is detailed in this Article by The Atlantic.
  • Surveillance capitalism: Like all Big Tech companies Microsoft / Github is a significant player in the widespread harvesting and trade of people’s personal data. Interactions of Internet Freedom activists on the platform are no exception to that, and may provide a wealth of information. Not only do US intelligence agencies likely have backdoors to the platform, but once information enters the Wild West information markets it can end up anywhere. Like in the hands of oppressive regimes.
  • Artificial intelligence: The rise of AI has brought data collection to new heights. Github recently launched CoPilot to help with coding, and in the process ingested all Free Software projects on their platform. Under “fair use” regulation you may find your code being regurgitated in proprietary projects. AI systems are also monitoring Terms of Service breaches, making many mistakes in the process. Policy is to err on the side of caution. Microsoft is involved in the the ongoing AI arms race and works on numerous different AI projects. There’s no telling how they’ll affect our Internet Freedom in the long run. Not having our data available, especially for oppressed people and activists is not more than prudent.
  • Market dominance: Microsoft continues to increase and fortify their dominant position. Known for their Embrace, Extend and Extinguish (EEE) strategies they will not hesitate to bend open ecosystems to their will, thwart open standards, and increasingly monetize the services for those who are captive to their platform. Many vendor lock-in aspects are directly detrimental to the conditions needed to assure Internet Freedom:
    • Unilateral changes to development features, such as deprecating API functionality, occur at rapid pace and are hard to adapt to by open projects that have only limited resources at their disposal.
    • Proprietary nature of large parts of the product portfolio as well as the services offered by 3rd-party vendors hamper reproducible builds. For instance the continuous integration / continuous deployment Security First umbrella tools rely on CircleCI. And the anti-censorship nthLink project depends on Github Actions.
    • Github does not offer a migration path for software projects to move off their platform. There are no open data formats to export to. For example, having an intricate project, Gitea found it impossible to move off of Github and self-host their own software project. After five years the migration effort is still ongoing. Other forge software, like GitLab and Gitea only provide partial migration from Github for specific use cases.

To a much lesser extent the points listed above also apply to Gitlab. Its positioning is already more directed towards enterprises, and they are limiting free services they offer. GitLab is a prime candidate for acquisition by another tech giant in the future, triggering a disruption in many projects now using this code forge.

Stacked against these two giant players we find a small number of Free Software projects, like the aforementioned Gitea. Projects that have huge potential. But also ones that are deployed as lonely hard to find self-hosted islands. F3 is instrumental for bridging divides. In addition efforts are underway to make individual code forges part of the decentralized Fediverse, and thus glue them together. The F3 open data exchange format is also part of that effort.

Beneficiaries

Human Right Defenders, journalists and whistleblowers who have specific needs to protect the privacy of their communication.

During my time at the Freedom of the Press Foundation and La Maison des Lanceurs d’Alerte (2017 to 2021), I provided custom development and the digital infrastructure they required. This experience allowed me to witness first hand the problem that centralized forges such as GitHub pose to the supply chain of a software protecting the privacy of communications.

When a nation state has the means to coerce an intermediary such as GitHub to provide information about its users, attempting to develop a particular feature designed to evade surveillance in a given regional context is hazardous. The state will have advance warning of this attempt and can work around it.

The software developers who are the most motivated to work on adapting software to address the threat from an oppressive regime are the one living in the country. Thanks to numerous Free Software projects such as Tor or SecureDrop, they do not need to start from scratch. They can get the source code. They can also setup a self-hosted forge such as GitLab or Gitea and dedicate machines to continuous integration that could carefully verify their modifications is not introducing a vulnerability that would expose the very people they are trying to protect.

But here lies the problem: they have no way to conveniently get a copy of the quality assurance process that includes CI (continuous integration), CD (continuous delivery), pull requests, issues, releases. They are missing a large part of what makes the software reliable and resistant to attackers: it stays on the centralized forges. Since a software release is only as good as the tools involved in the quality & assurance process, their work is made significantly more difficult.

With F3 they will be able to get a software project as a whole, including the configuration of the CI and CD process. Every change they make will undergo the same verification than the original software and the outcome will be as robust and reliable. More importantly, they will be able to do that in complete autonomy, without frequent interactions with a centralized forge that could expose the

How would this project provide long-term support to users at risk?

Durable self contained distribution on read-only media

It is common for people living in authoritarian regimes to procure software using physical media like CDs and flash drives. In such cases, only the source code is available since bug tracker, pull request etc. are not available in a downloadable format. F3 will allow developers in authoritarian regimes to setup self-contained, self-sustainable development shops with the full knowledge and experience of the project’s global community. When combined with Git, F3 not only provides a downloadable format but it also supports an efficient synchronization method.

Long term preservation of the software supply chain

Here is an hypothetical use case relevant to human right defenders in need of long term support:

  • In 2022 https://www.nthlink.com/ is used to setup on mobile phones and used by human right defenders in a country that is under an oppressive regime
  • Five years later, in 2027, the mobile phones need to be replaced and the application re-installed, with small modifications because the operating system has changed

With F3, the entire project including the build process that makes nthlink reproducible, has been stored in 2022. It only relies on Free Software that was also stored to make the build process durable. In 2027 they can be re-used to build a new version with small modifications and be re-installed on new phones. The effort is minimal.

Without F3, the build environment provided by GitHub has changed and it is no longer possible to use the now deprecated 2022 build process. The nthlink application as it existed in 2022 can no longer be used: it is not supported for newer phones. Upgrading the application would require training the users with the new interface and functionalities. The mobile phones that broke down cannot be easily replaced, a larger effort is required although the 2022 application is still relevant and useful in this particular context. The solution designed in 2022 was made obsolete because the software project could not be archived together with its build process using an Open Standard.

How could this project impact the FOSS community?

Long term it would transform the FOSS online development environment from being centralized and proprietary into being a constellation of federated Free Software forges communicating with each other. It has been twenty years since SourceForge was created, with the same centralization problem as GitHub. F3 is a stepping stone for the FOSS community to reclaim ownership of the tools that they use daily to develop software, to no longer be under the influence of two global corporation, Microsoft an GitLab.

Short term it would allow:

  • A software project to be exported in the F3 format from GitHub and imported into a self hosted GitLab or Gitea using the same format
  • A developer to file a bug report on GitHub using the F3 format without the need to create an account, provide personal data and agree to restrictive terms and conditions
  • Mirroring of issues from GitHub into a self hosted GitLab or Gitea and receive notifications when they change

What differences will this project make for developers on a practical level?

Free Software developers will be able to:

Track issues relevant to their software project across software forges and processes (see the 2021 user research report on this topic).

Migrate and mirror software projects from one software forge to another.

Reduce the complexity of implementing software forge migrations. Instead of maintaining a migration process from

  • GitHub to Gitea,
  • GitHub to GitLab,
  • GitHub to GitHub
  • Gitea to GitHub,
  • Gitea to GitLab,
  • Gitea to Gitea
  • GitLab to GitHub,
  • GitLab to Gitea,
  • GitLab to GitLab
  • etc.

With F3 it will only be necessary to maintain a migration process from:

  • GitHub to F3
  • Gitea to F3
  • GitLab to F3
  • F3 to GitHub
  • F3 to GitLab
  • F3 to Gitea

Please describe your project’s objectives and related activities, and resulting deliverables if applicable.

What are the activities that will accomplish the project’s goals? What are the outputs or deliverables of each activity? Please be as concrete as possible, so that we understand what you are planning to do.

See the corresponding guide section

In the following the objectives and activities are roughly listed in chronological order (the Go implementation must happen before the release) but some of them can be conducted in parallel (the User Research can happen at the same time as the Go implementation independent of the API).

Objectives

User Research

In the spirit of focusing on what the user needs and not the product, we prepare our research starting with finding participants among software developers, organizations and forge maintainers.

The findings of the User Research are summarized in a report concluded by recommendations for that should be followed by the F3 specification implementors.

Community engagement

The long term sustainability of the F3 specifications and reference implementation require a strong engagement from a diverse community of volunteers. It requires a technical infrastructure that allows for quick onboarding, a curated lists of easy tasks and more generally all the best practices recommended for Free Software projects.

Although it can be expected to happen over time, an effort will be made to reach this objective sooner rather than later. It is transversal to all activities, from the evolution of the documentation to the release process itself up to the governance of the project. The best volunteers should be empowered with a clear path to participation, from the smallest task achievable within a few hours up to a daily involvement to transform the governance of the F3 project itself.

This objective is not achieved by specific activities, it is achieved by accomplishing each activity with this particular state of mind.

Specification and documentation

This is the core of the project and will be released as a reference document explaining the F3 format. A bottom up approach is preferred because it is usable within a reasonable time frame. By contrast, a top down approach that would consist of designing a theoretical format would be very challenging as it would require a consensus from all forge implementors to be effective. F3 starts with the internal format used by the Gitea project because it has a better chance of being implemented natively and reach a significant audience.

Go package reference implementation

The Go reference implementation for F3 is meant to cover all aspects of the specifications. It is developed at the same time as the specifications, in a short feedback loop that allows to quickly identify aspects of the specification that are either ambiguous or difficult to implement.

It provides three interfaces:

  • The command line interface which is most convenient for exporting and importing a software project from and to a software forge that does not yet natively implement the format.
  • The F3 API which is meant to be used for high level import, export and mirror operations.
  • The F3 driver API which is meant to be used by forge implementors to natively support F3.

The simpler native integration using the F3 API would rely on the REST API of the forge and require little work from the implementor. But it would also be subject to the limitations imposed by the API (such as assigning identifiers to objects like issues or milestones). The better native integration requires writing a F3 driver to use the internals of the forge.

Python package reference implementation

The Python reference implementation demonstrates how the Go package can be used from another language. It could be used by the Pagure forge to provide basic import, export and mirroring features. Such an integration would not require the implementor to know the details of the F3 specifications as the bulk of the work is already implemented in the Go package. Only the F3 API is available in this context.

The value of this implementation is primarily to encourage developers to prefer sharing a single implementation of the format rather than fragmenting its interpretation by working on multiple implementations.

First release

The release of the F3 format is published simultaneously with the Go reference implementation, under the same semantic version. It provides the following guarantees to the user:

  • Backward compatibility
    • Every effort is made for a version to be compatible with the previous versions
    • If a breaking change cannot be avoided, the reference implementation provides a conversion method to upgrade existing F3 archives
  • Non ambiguous: each aspect of the specifications is precisely documented, the reader does not need to interpret ambiguous statement
  • Semantic versioning: the user knows if a breaking change is introduced by reading the version number
  • Detailed release notes: each modification to the specification is explained in detail in release notes so the reader is able to understand their consequences

The development releases happen once a month but do not provide the same guarantees. The stable releases of the reference implementation may receive security patches and bug fixes but will not receive new features. Similarly, the stable releases of the specifications my receive patches when an error is found or an ambiguity requires rewording but their semantic will remain exactly the same.

Integration in the Gitea codebase

The Go reference implementation is the basis of a native integration in the Gitea codebase which is also written in Go. Ideally such a native integration is implemented by the developers of the software forge. But since F3 is an emerging standard, there is not enough incentive for that to happen. This integration is meant to be a feature addition to the Gitea codebase as well as an example to show how F3 can be natively integrated in other forges.

Submission to a standard body

Although it is premature to expect that F3 is accepted by an standard body, the process to develop a new standard within OASIS or W3C is very involved and it should be engaged as soon as possible. The objective is to properly apply to at least one standard body and share the required knowledge with all members of the community working on the F3 specifications and reference implementation.

Activities

User Research

Deliverable: A User Research report
Effort: 10 days

Specification and documentation

The F3 Specification includes:

  • An introduction
  • JSON Schema with embedded documentation
  • Release notes
  • A normative file hierarchy
  • A glossary of terms and their definition

Deliverables:

Effort: 30 days

Go package reference implementation

A reference implementation of F3 in Go provides:

  • An API for integration in a forge written in Go
  • Validation of a F3 archive (JSON Schema validation, VCS sanity checks)
  • Import and Export support for Gitea and GitLab
  • Dataset generators and fixtures to verify the conformance with the specifications

Deliverable: The Go package is published https://pkg.go.dev/
Effort: 70 days

Python package reference implementation

A reference implementation of F3 in Python provides:

  • An API for integration in a forge written in Python
  • Continuous deployment of the F3 documentation
  • The same features as the Go package reference implementation

Deliverable: The Python package is published https://pypi.org/
Effort: 5 days

First release

The first F3 release is a bundle that includes:

  • The specifications and documentation
  • The Go reference implementation
  • The Python reference implementation

They are verified to be consistent and tagged with the same version number.

Deliverable: simultaneous publication of F3 version 1.0.0 at:

Effort: 5 days

Integration in the Gitea codebase

The F3 Go reference implementation is used as a replacement of the internal format used for repositories dump and restore features in the Gitea codebase.

Deliverables: pull request merged in https://forgefriends.org or https://gitea.io
Effort: 5 days

Submission to a standard body

Reach out to OASIS and propose F3 as a new standard

Deliverable: A submitted application acknowledged as received by OASIS
Effort: 5 days

How long will it take? (In Months)

12 months

Please elaborate on the technical feasibility of this effort.

The applicant is expected to provide a succinct description of the technical objectives of the effort, using appropriate terminology. The applicant should also provide any research/documentation of the feasibility/novelty of their technical approach, any hurdles or technical challenges they might encounter in implementation, and what they plan to do about it.

See the corresponding guide section

… we want to understand what the technical objectives of your efforts are, what technology design decisions you’ve made, and why you made those decisions.

An Open Standard is ultimately a single document easily distributed. Updating and publishing the document conveniently requires the tooling provided by software forges. A proposed change is proposed on the forge, discussed and merged. The continuous integration pipeline verifies there are no formatting errors and the development branch is updated. Upon release of the specifications, the continuous delivery pipeline updates the website so the newer version of F3 is distributed to the general public.

This workflow is familiar in the context of a Free Software project but it is less common when developing a standard. It is however more likely to facilitate participation from a large community of developers, a facet that is essential to the long term sustainability of F3.

… you are aware of known challenges you might face implementing those technical objectives, and that you have a plan to address those challenges, and how they may affect the output of the effort.

F3 is a format that contains non trivial information and an ever growing number of objects. A reference implementation with a well defined API is both essential to its adoption and a technical challenge. To reduce the likelihood of fragmentation (diverging implementations of the F3 format) and minimize the development effort, the choice was made to develop the reference implementation in Go. The Go package can then conveniently be re-used as a module in libraries for other programming languages such as Python or Ruby. It will then be easier for forges such as Gitea (written in Go), GitLab (written in Ruby) or Pagure (written in Python) to rely on this reference implementation instead of implementing its own.

Please describe your usability/UX and accessibility practice for developing this tool.

Does the proposal demonstrate clear external demand for the proposed end product? Does the project demonstrate a high degree of usability and/or accessibility? Is the project targeting a small number of high value or at-risk users, or a broader population? Is the proposed effort appropriate for the intended audience?

See the corresponding guide section

Past community consultation and User Research

The Free Software community at large has been aware that centralized software forges is a problem for the entire corpus of FLOSS for over two decades:

In 2021 User Research was conducted to identify the need. It has never been done before and involved software forge developers, system administrators and Free Software developers. The result was published in June 2021 in a report. They expressed the need for communication between software forges. They explained, by providing concrete examples from their personal experience, the practical problems that arise because such communication does not exist.

The communities referenced in the State of the Forge Federation: 2021 to 2023 were consulted and reviewed the document which explains F3 in context. They include software forge developers (Gitea), software forge system administrators (Codeberg) and Free Software developers.

In 2021 the relevance of an interchange format (not yet named F3) in the context of the federation of software forges was explained during the Next Generation Internet webinar on Linked Data. In January 2022 the idea matured and was explained as an incremental import/export during a webinar on Forge Federation

Future User Research and UX design

User Research will be conducted to identify the need of three personae using F3:

  • Free Software developers who are unlikely to read the F3 specifications but likely to use the reference implementation API
  • Software forge devops who will face challenges on behalf of the Free Software developers using their forges when F3 is used to export/import or mirror software projects, either automatically or manually
  • Software forge developers who will depend on the F3 specifications to natively implement F3, either from scratch or by using the reference implementation

The User Research report will determine the content of the specifications on each release, the backward compatibility process, how the community is engaged etc. It will also set priorities for the API of the reference implementation, either via the command line or programmatically.

The adoption of F3 is expected to be significantly improved with the answers collected by user research for questions such as:

  • Is the quality of the documentation important?
  • How much work is required from users when the release of a format is not backward compatible?
  • What format transformations are use most?
  • etc.

Internationalization and accessibility

Free Software developers all read English because most of the documentation they need for their work is only available in English, which lowers the requirement for internationalization. But not all of them are fluent and when the documentation is not available in their native language it makes it significantly more difficult to understand. Internationalization is therefore useful to:

  • Lower the barrier of entry for F3 users
  • Reduce the risk of incorrect interpretation of the specifications

The specifications will be translated in French and the project submitted to LocalizationLab to foster a community of translators for other languages.

The reference implementation will be internationalized and a workflow similar to the one in place for the SecureDrop project documented.

A self-hosted Weblate instance will be used to host both localization efforts (specifications and reference implementations).

Since the reference implementation has no user interface other than the command line and the programmatic API, internationalization is the only accessibility requirement.

Please describe the scope of this project’s alternative analysis. If the project has been audited before, please briefly describe the scope and outcome of those assessments, providing links to reports if available.

Does the project identify potential unintended consequences? Does it identify how an adversary might use the solution to further their own goals? Does the proposal consider potential illicit uses of the project? Does the proposal identify appropriate tactics for a potentially asymmetric position in relation to an adversary? Does the proposal consider sufficiently whether its approach is offensive or defensive in relation to the problem it is addressing? Does it explain why it has selected this approach (effort, cost, time, etc.)? Does the proposal discuss how the project could be undermined, identify its own deficiencies and limitation, or does it presume there are none? Does the proposal explore short-, medium-, and long‐term strategies from the adversary’s point of view? Does the project increase or decrease known attack surfaces?

See the corresponding guide section

Does the proposal discuss how the project could be undermined, identify its own deficiencies and limitation?

For the past twenty years, from SourceForge in 2001 to GitHub in 2022, the dominant actors providing centralized software forges developed undocumented specific formats to store the data they contain. The F3 effort to create an open standard is undermined when the dominant forge software makers do not participate. It is likely that they will keep refusing to participate in the next few years.

GitHub and GitLab strategy is to actively prevent and control communication between software forges and passively preventing a standardization effort like F3 is part of this strategy. Their primary goal is to ensure lock users in. Although the side effects of this strategy threatens internet freedom, it is not a goal in itself for these organizations.

There currently is a status quo: most Free Software development happens on a single software forge (GitHub). But there is no practical or theoretical limitation to replace GitHub with a multitude of software forges.

Does the project identify potential unintended consequences?

If a group of developers work in autonomy and rely on a set of software projects stored in F3, it significantly changes the threat model. For instance, instead of a network of online actors, linked to GitHub, providing real time tooling for the supply chain to build the software, F3 creates a situation where the entire supply chain could be run offline. Threat modeling for a particular use case may uncover new threats that have not yet been taken into account.

Once F3 is usable, feedback from actors facing security threats must be collected by participating in their security audit and analysing the reports. The recommendations related to F3 will then be incorporated into the specifications and the reference implementation. This feedback loop is how unintended consequences are discovered and addressed.

Does the proposal identify appropriate tactics for a potentially asymmetric position in relation to an adversary?

This would have to be considered in collaboration with an actor using F3 in a specific context. The F3 format and the reference implementation are not always used by an actor in an asymmetric position in relation to an adversary.

Does it identify how an adversary might use the solution to further their own goals?

If F3 archives are made available on a repository that does not provide cryptographic signature verification or does not require them, malicious content can be distributed. Similar to what happens on a daily basis on PyPI with name squatting, for instance.

Are there other efforts similar to you what you are proposing? Does your work build on their work? What makes your approach different?

List other similar efforts to this proposed project. OTF expects this to include a review of any available technologies or programs and events that are similar to the project described. We want to understand how your project relates to others or how it can be distinguished from those that already exist. We are also looking for proof of the applicant’s understanding of the current landscape in the domain this project is situated.

See the corresponding guide section

The State of the Forge Federation: 2021 to 2023 published in June 2022 contains a detailed description of the projects related to F3. It is designed to be a building block that can be reused by all of them to facilitate the implementation of forge federation features.

F3 is different from ForgeFed. ForgeFed is an ActivityPub extension with its own vocabulary and models represented in JSON-LD. F3 is an JSON based Open File Format providing a strongly consistent representation of a software project at a given point in time. Despite these differences, there are overlaps: they both need to define a glossary of terms and explain concepts that are common between forges. This already led to contributions to Forgefed and more are expected in the future.

The forgefriends and ForgeFlux forge federation proxies will include F3 in their upcoming releases. This integration will be a showcase demonstrating how the Go and Python API can be used for integration in other software forges.

Deploying F3 in production is challenging because it does not yet have a reassuring reputation of stability and robustness. When problems are discovered, they will require a level of understanding and an investment in time from system administrators that most service providers consider too costly. The Gna! service provider is committed to advance forge federation and will deploy F3 as soon as it is available. It will likely be the first production instance supporting F3.

Please describe your approach to monitoring and evaluating the outcomes and impact of this effort.

Describe how the project’s success will be evaluated and any metrics that will be collected related to the project’s outcomes and impact. By what metrics will you define the successful completion of the project? By what means will you determine that the project was successful in reaching its goals? OTF relies on these mechanisms to track and record the success of the project.

See the corresponding guide section

By what metrics will you define the successful completion of the project?

  • The frequency of stable releases of the F3 format
  • The frequency of stable releases of the F3 reference implementation
  • The number of forge service providers supporting F3
  • The number of developers using F3
  • The number of forges natively supporting F3
  • The number of people (paid staff and volunteers) participating in the evolution of F3 (format and reference implementation)
  • The funding obtained to sustain F3 as a whole

How are you planning to collect that information? And how will you document it?

The Frequency of stable releases is collected from the registry where they are published.

Lists of forge service providers, software forges and service providers are maintained in a repository, sorted to record those using or implementing F3 to keep track of them over time. As F3 becomes more popular it may be difficult to maintain such lists and the only way to collect that information would be to actively poll organizations and people.

People participating in the evolution of F3 are conveniently listed in the changes they authored in the repositories. Some people provide advice’s instead of authoring a change that is recorded, which makes them more difficult to account for. Such mentoring is however important and relies on the memory of the people collecting the information manually.

The funding is systematically and publicly recorded in a spreadsheet and a forum and can be collected from there.

By what means will you determine that the project was successful in reaching its goals?

  • The F3 stable releases are published at least twice a year
  • All forges natively support F3 (hence all developers and forge providers)
  • There are more volunteers than paid staff
  • The funding covers the cost of the paid staff participating in the making of F3

How will you collect and share learnings from this project?

In the first few years all information worth learning from is expected to be published in the F3 forum. Once a month all messages are browsed and a report is written as a digest. Something similar is done with the pull requests from the F3 specifications and the reference implementation. The authors of the report will do their best to write it in an objective and dispassionate way but they will inevitably make choices that reflect their own interest.

This monthly report allows for participation from people who are not engaged daily in the project by providing them with a high level view. In addition to the synchronous communication channel (Matrix chatroom) and the asynchronous communication channel (Forum), a recurring meeting is organized to share learnings with all stakeholders:

  • A monthly report is published to reflect the progress of the F3
  • A monthly videconference is organized and open to the public to discuss the monthly report
  • A presentation of the progress of F3 is made in a synthetic way during a webinar once a year

Do you expect any major milestones during this project?

The first stable release of the F3 format and the Go reference implementation.

What instrument or process will you use to document the impact of this project on your local community, beneficiaries, or Internet freedom ecosystem?

The projects supported by OTF and their dependencies will be approached and invited to participate in User Research initially. Their input will define themes that matter to them and when the implementation is stable, they will be invited to use F3 to solve the problem they have. The impact will be positive if the need observed during the User Research phase is fulfilled by the F3 release.

What’s your long term strategy for this project beyond OTF support?

Sustainability can be measured in different ways. Please explain how this effort will achieve sustainability. This can include funding received from other funders or other revenue models, collaborations with organizations beyond the funding phase, an active community network and others.

From the mail inviting to send an application: “make sure to integrate your feedback into the proposal also, and please elaborate on the community engagement plan”

See the corresponding guide section

… how this effort will achieve sustainability over the funding period and beyond.

F3 needs to evolve to keep up with the evolution of software forges. As new development methods and tools are implemented, F3 must be updated to represent them. If it is to succeed, it will require an active engagement from dozens if not hundred of developers over decades. A likely scenario involves a few full time paid staff whose mission is partly to advance F3 on a technical level (release cycle, online resources, etc.) and partly to empower a larger community of volunteers (on-boarding, training, meetings, roadmaps, etc.).

… funding received from other funders or other revenue models.

During the first years, F3 is bootstrapped by seeking funding with OTF, NLnet and European R&D tax relief schemes. The goal is to create the conditions for F3 to be natively supported by each forge and facilitate participation in the maintenance of the F3 by all stakeholders. At which point the organizations developing the forges as well as the service providers selling services based on Free Software forges will have a vested interest in devoting a fraction of their revenue to keep F3 going.

… collaborations with other organizations and your role and relation to communities around your project.

F3 is developed bottom up to become a de-facto standard. As it matures a dialog with standard bodies such as OASIS or W3C will be engaged. The goal is that ultimately one of them supports F3. In the meantime relationships with organizations and people developing software forges (Gitea, GitLab, etc.) are the primary focus because they are involved in making the native support of F3 a reality. Organizations running forges (Framasoft, Codeberg, Gna!, etc.) as well as Free Software providers (Webarchitects, Easter-Eggs, Bearstech, etc.) have an incentive to be early adopters of the F3 reference implementation (to migrate and mirror software projects, for instance). Finally, the Free Software developer community is the primary community involved in User Research to sort out F3 priorities.

… how this project provides resources to others or how others can reuse the resources you develop.

F3 is developed in the context of the forgefriends project, a horizontal community with a radically transparent governance. Anyone and everyone has access to all the resources of the project, subject to their acceptance of the Code of Conduct. The resources developed by F3 are all released under a Free Software license.

Adoption efforts

Wide adoption of F3 is difficult to achieve, it requires a long term effort. But can be done incrementally.

The adoption of F3 will require:

  • endorsement by a standard body
  • a concise, precise and unambiguous documentation
  • complete and reliable reference implementations in multiple programming languages
  • native integration in all major software forges

At present the primary adoption blocker is that GitHub is unlikely to support F3 or any other Open Format facilitating software project migration and mirroring.

An incremental adoption should start by:

  • creating the format with a bottom up approach, using the existing Gitea format
  • providing a reference implementation in one language only Go chosen to be linkable with other languages
  • focusing on practical advantages this reference implementation brings to Free Software developers (i.e. cross forges issue tracking)

Further iterations will then expand the scope of the F3 specifications and provide additional practical advantages to drive the change.

Why are you, and your team members, the right people to work on this project?

You can describe your previous work, link to relevant past projects, or explain other forms of knowledge of the subject matter. We are also interested in learning about your experience in working with users described. Have you worked with them before, how are you connected? Do you consider yourself part of the target audience? Ideally, you can also describe your connections to partners and other relevant actors in the field.

See the corresponding guide section

In 2017 and 2018 I worked on SecureDrop and authored hundreds of commits. I spearheaded the internationalization of the codebase and organized a team of translators in cooperation with Localization Lab. During this time I occasionally worked with journalists and whistleblowers, addressing their needs with training or software development. I spearheaded the User Research effort in SecureDrop in cooperation with Open Source Design.

In 2020 I worked for La Maison des Lanceurs d’Alerte and setup their information system from scratch, training and supporting the legal team, the staff as well as the volunteers. In this context I also provided technical support to whistleblowers in France and abroad when there was a suspicion they could be targeted by state actors or powerful adversaries.

Since January 2021 I worked full time with https://forgefriends.org, https://forgefed.org, https://gitea.io and https://www.softwareheritage.org/ to advance forge federation. I made contributions to the forgefed specification and played an active role in reviving the project with a broader community.

The forgefriends project is a proxy designed to enable federation for software forges that do not yet implement it natively. I participated in forgefriends from the start, in January 2021. I authored most of the code and documentation that exist today. I published activity reports on a monthly basis and organized videoconferences to keep the larger community up to date.

I have worked with the Gitea project since late 2021 to natively implement federation with code contributions.

Please provide a budget narrative explaining the budget required to execute your proposed project.

Please include in your narrative the budget associated with individual objectives, activities and their associated deliverables. Please also include and describe major budget categories associated with this project. In addition to hourly or daily rates for labor, please include estimates of any expenses that would be supported by the requested funds, e.g.consultants, supplies, travel, etc.

See the corresponding guide section

The funds will exclusively be spent on paying for my time, at an hourly rate of 60USD. The global estimated effort is 130 days (as detailed in the list of activities) over a period of twelve months. There will be no other expenses and no sub-contractors.

Here is the final version, used to fill the proposal template. I will gently ping OTF November 20th if there are no news.

image

Final version

Project Title*

Friendly Forge Format (F3) - an Open Standard for autonomous Free Software

What is your name?*

Loïc Dachary

What email address should we use to contact you?*

loic@dachary.org

How much funding do you estimate you will need? (In US Dollars)

60000

Please include a full description of your project, including the problem statement, your approach, and the main beneficiaries.

Please succinctly describe the key objectives of the proposed effort, the challenges it intends to address and what gap it fills. Please also describe how this will benefit people living in repressive environments and what outcome and impact it will have.

See the corresponding guide section

Most software designed to protect HRD, journalists and whistleblowers is FLOSS. Each binary release is carefully verified by a sophisticated supply chain to spot vulnerabilities and regressions. When a feature is missing, developers living under an oppressive regime have a strong motivation to modify the source code. But they are missing the information to run the supply chain independently. Their sub-standard release may put at risk the very people they are trying to help. F3 is a new Open File Format that combines the source code with all the information that enables developers to produce high quality releases.

The software forge centralization problem F3 addresses, although widely acknowledged, is not funded and only a handful of people worldwide are making concrete work to solve it. It is not just relevant to Internet Freedom, but impacts the entire corpus of Free Software. In this regard F3 covers the same breadth of concerns that the reproducible software project does.

Our society, and especially our communication and information sources, depend on complex technology, which is often and increasingly centralized. The power to control them is in the hands large corporations, that may not have the best interests and needs of the human citizens and users in mind. For underprivileged people living in oppression the need for empowerment is most urgent. Open information access is at the basis of the ability for people to be informed, to reveal injustices and expose censorship. Freedom of expression and other fundamental human rights depend on the control over the technology one uses, and having the ability to participate in its creation. The means for affected people in the region to wield the full range of software development tools is crucial to support activism work. The F3 specification is a critical enabler of that, and part of a larger vision of “Liberating Free Software Development”. Making software be Free is a step toward setting people free.

Problem statement

There is no standard file format to share the content of a software forge (e.g. git repository, issues, etc.), and only some of them provide an undocumented internal format. It is possible to use the forgefed vocabulary to send a message about a particular detail (i.e. an individual commit or an issue) via the ActivityPub protocol. But the receiving forge may not know the context in which this information can be interpreted because it cannot conveniently obtain it. As a whole, a software project is a large dataset that is made of numerous interconnected elements stored in a strongly consistent state. Without a standardized file format, interoperability between forges is very difficult.

The Friendly Forge Format (abbreviated F3) is an Open File Format for storing the information from a forge such as issues, pull/merge requests, milestones, release assets, etc. as well as the associated VCS (Git, Mercurial, etc.).

F3 is designed to exchange the state of a software project between GitHub, GitLab, Gitea, etc. for backup, mirroring or federation.

F3 is essential for a forge to provide key requirements:

  • Portability: the entire state of a software project can be dumped and restored at a later time, on a different development environment.
  • Versatility: when published and updated as a F3 archive, a software project effectively is Open Data on which an unlimited range of applications can rely, even outside of the forge domain
  • Consistency: it provides a common language to use when talking about the forge related domains
  • Trust: cryptographic signatures on each F3 dump guard against malicious or unintentional tampering that could compromise the integrity of a software project

And it unlocks the following use cases:

  • Analytics: data mining the contents of files is more practical than issuing a large number of queries to an API
  • Mirror: issues and all other aspects of a software project can be conveniently mirrored from a forge to another by publishing a F3 archive in a VCS and acting on the changes
  • Archival: storing F3 archives in a VCS makes it easier for them to be preserved in long term archives such as Software Heritage
  • Reporting: forgefed messages can be created from F3 and sent via the ActivityPub protocol

Why is this effort needed in the Internet Freedom space?

The entire software development landscape is overly dominated by just two major players, Github and Gitlab. In particular the position of Github, owned by Microsoft, is problematic when it comes to securing Internet Freedom. Github’s role in the success of Free Software is often lauded, and partly warranted. For Microsoft / Github providing free access was just a very successful strategy to gain market share and establish network effects. Their centralized platform lies at the heart of a huge ecosystem of software tool vendors that optimized their products to integrate with Github services.

Nowadays literally thousands of projects and millions of software developers are subjected to a strong form of de-facto vendor lock-in. Often without even realizing it. For the Free Software movement this is a threat, as Microsoft does not have their best interest at heart. They follow commercial incentives, and are bound by US regulation. By extension here we find substantial threats to Internet Freedom.

There are numerous examples on how these threats materialize in practice.

  • Geopolitical affiliation: Github as US-based corporation must comply to foreign policy and Trade Control and block people and projects from countries that are at odds with USA from accessing their platform. They apply a broad brush to assure they are in compliance, as this Tweet by Sebastian Slomski demonstrates. Once blocked it is very hard to find recourse or reparation.
  • Corporate, governmental and military influences: As a for-profit US enterprise Microsoft / Github intends to maximize revenue and profits. Their most lucrative contracts are with partners that are not known to be favorable to the same Internet Freedoms we, as humanity, crave. How controversial these often secretive and shady deals are is detailed in this Article by The Atlantic.
  • Surveillance capitalism: Like all Big Tech companies Microsoft / Github is a significant player in the widespread harvesting and trade of people’s personal data. Interactions of Internet Freedom activists on the platform are no exception to that, and may provide a wealth of information. Not only do US intelligence agencies likely have backdoors to the platform, but once information enters the Wild West information markets it can end up anywhere. Like in the hands of oppressive regimes.
  • Artificial intelligence: The rise of AI has brought data collection to new heights. Github recently launched CoPilot to help with coding, and in the process ingested all Free Software projects on their platform. Under “fair use” regulation you may find your code being regurgitated in proprietary projects. AI systems are also monitoring Terms of Service breaches, making many mistakes in the process. Policy is to err on the side of caution. Microsoft is involved in the the ongoing AI arms race and works on numerous different AI projects. There’s no telling how they’ll affect our Internet Freedom in the long run. Not having our data available, especially for oppressed people and activists is not more than prudent.
  • Market dominance: Microsoft continues to increase and fortify their dominant position. Known for their Embrace, Extend and Extinguish (EEE) strategies they will not hesitate to bend open ecosystems to their will, thwart open standards, and increasingly monetize the services for those who are captive to their platform.

Many vendor lock-in aspects are directly detrimental to the conditions needed to assure Internet Freedom:

  • Unilateral changes to development features, such as deprecating API functionality, occur at rapid pace and are hard to adapt to by open projects that have only limited resources at their disposal.
  • Proprietary nature of large parts of the product portfolio as well as the services offered by 3rd-party vendors hamper reproducible builds. For instance the continuous integration / continuous deployment Security First umbrella tools rely on CircleCI. And the anti-censorship project nthLink depends on Github Actions.
  • Github does not offer a migration path for software projects to move off their platform. There are no open data formats to export to. For example, having an intricate project, Gitea found it impossible to move off of Github and self-host their own software project. After five years the migration effort is still ongoing. Other forge software, like GitLab and Gitea only provide partial migration from Github for specific use cases.

To a much lesser extent the points listed above also apply to Gitlab. Its positioning is already more directed towards enterprises, and they are limiting free services they offer. GitLab is a prime candidate for acquisition by another tech giant in the future, triggering a disruption in many projects now using this code forge.

Stacked against these two giant players we find a small number of Free Software projects, like the aforementioned Gitea. Projects that have huge potential. But also ones that are deployed as lonely hard to find self-hosted islands. F3 is instrumental for bridging divides. In addition efforts are underway to make individual code forges part of the decentralized Fediverse, and thus glue them together. The F3 open data exchange format is also part of that effort.

Beneficiaries and the supply chain replication problem

Human Right Defenders, journalists and whistleblowers who have specific needs to protect the privacy of their communication.

During my time at the Freedom of the Press Foundation and the Maison des Lanceurs d’Alerte (2017 to 2021), I provided custom development and the digital infrastructure they required. This experience allowed me to witness first hand the problem that centralized forges such as GitHub pose to the supply chain of a software protecting the privacy of communications.

When a nation state has the means to coerce an intermediary such as GitHub to provide information about its users, attempting to develop a particular feature designed to evade surveillance in a given regional context is hazardous. The state will have advance warning of this attempt and can work around it.

The software developers who are the most motivated to work on adapting software to address the threat from an oppressive regime are the one living in the country. Thanks to numerous Free Software projects such as Tor or SecureDrop, they do not need to start from scratch. They can get the source code. They can also setup a self-hosted forge such as GitLab or Gitea and dedicate machines to continuous integration that could carefully verify their modifications is not introducing a vulnerability that would expose the very people they are trying to protect.

But here lies the problem: they have no way to conveniently get a copy of the quality assurance process that includes CI (continuous integration), CD (continuous delivery), pull requests, issues, releases, etc. They are missing a large part of what makes the software reliable and resistant to attackers: it stays on the centralized forges. Since a software release is only as good as the tools involved in the quality & assurance process, their work is made significantly more difficult.

With F3 they will be able to get a software project as a whole, including the configuration of the CI and CD process. Every change they make will undergo the same verification than the original software and the outcome can then be as robust and reliable. More importantly, they will be able to do that in complete autonomy, without frequent interactions with a centralized forge that could expose them.

How would this project provide long-term support to users at risk?

Durable self contained distribution on read-only media

It is common for people living in authoritarian regimes to procure software using physical media like CDs and flash drives. In such cases, only the source code is available since bug tracker, pull request etc. are not conveniently downloadable. F3 will allow developers in authoritarian regimes to setup self-contained, self-sustainable development shops with the full knowledge and experience of the project’s global community. When combined with Git, F3 not only provides a downloadable format but it also benefits from an efficient synchronization method.

Long term preservation of the software supply chain

Here is an hypothetical use case relevant to human right defenders in need of long term support:

  • In 2022 https://www.nthlink.com/ is used to setup mobile phones and provided to human right defenders in a country that is under an oppressive regime
  • Five years later, in 2027, the mobile phones need to be replaced and the application re-installed, with small modifications because the operating system has changed

With F3, the entire project including the build process that makes nthlink reproducible, has been stored in 2022. It only relies on Free Software that was also stored to make the build process durable. In 2027 they can be re-used to build a new version with small modifications and be re-installed on new phones. The effort is minimal.

Without F3, the build environment provided by GitHub has changed and it is no longer possible to use the now deprecated 2022 build process. The nthlink application as it existed in 2022 can no longer be used: it is not supported for newer phones. Upgrading the application would require training the users with the new interface and functionalities. The mobile phones that broke down cannot be easily replaced, a larger effort is required although the 2022 application is still relevant and useful in this particular context. The solution designed in 2022 was made obsolete because the software project could not be archived together with its build process using an Open Standard.

How could this project impact the FOSS community?

Long term it would transform the FOSS online development environment from being centralized and proprietary into being a constellation of federated Free Software forges communicating with each other. It has been twenty years since SourceForge was created, with the same centralization problem as GitHub. F3 is a stepping stone for the FOSS community to reclaim ownership of the tools that they use daily to develop software, to no longer be under the influence of two global corporation, Microsoft and GitLab.

Short term it would allow:

  • A software project to be exported in the F3 format from GitHub and imported into a self hosted GitLab or Gitea using the same format
  • A developer to file a bug report on GitHub using the F3 format without the need to create an account, provide personal data and agree to restrictive terms and conditions
  • To mirror issues from GitHub into a self hosted GitLab or Gitea and to receive notifications when they change

What differences will this project make for developers on a practical level?

Free Software developers will be able to:

Track issues relevant to their software project across software forges and processes. This is an actual need that was discovered by conducting User Research (see the 2021 user research report on this topic).

Migrate and mirror software projects from one software forge to another.

Reduce the complexity of implementing software forge migrations. Instead of maintaining a migration process from

  • GitHub to Gitea,
  • GitHub to GitLab,
  • GitHub to GitHub
  • Gitea to GitHub,
  • Gitea to GitLab,
  • Gitea to Gitea
  • GitLab to GitHub,
  • GitLab to Gitea,
  • GitLab to GitLab
  • etc.

With F3 it will only be necessary to maintain a migration process from:

  • GitHub to F3
  • Gitea to F3
  • GitLab to F3
  • F3 to GitHub
  • F3 to GitLab
  • F3 to Gitea

Please describe your project’s objectives and related activities, and resulting deliverables if applicable.

What are the activities that will accomplish the project’s goals? What are the outputs or deliverables of each activity? Please be as concrete as possible, so that we understand what you are planning to do.

See the corresponding guide section

In the following the objectives and activities are roughly listed in chronological order (the Go implementation must happen before the release) but some of them can be conducted in parallel (the User Research can happen at the same time as the Go implementation up to the point where the API must be implemented).

Objectives

User Research

In the spirit of focusing on what the user needs and not the product, we prepare our research starting with finding participants among software developers, organizations and forge maintainers.

The findings of the User Research are summarized in a report concluded by recommendations that should be followed by the F3 specification implementors.

Community engagement

The long term sustainability of the F3 specifications and reference implementation require a strong engagement from a diverse community of volunteers coordinated by paid staff. It requires a technical infrastructure that allows for quick onboarding, a curated lists of easy tasks and more generally all the best practices recommended for Free Software projects.

Although it can be expected to happen over time, an effort will be made to reach this objective sooner rather than later. It is transversal to all activities, from the evolution of the documentation to the release process itself up to the governance of the project. The best volunteers should be empowered with a clear path to participation, from the smallest task achievable within a few hours up to a daily involvement to transform the governance of the F3 project itself.

This objective is not achieved by specific activities, it is done by accomplishing each activity with this particular state of mind.

Specification and documentation

This is the core of the project and will be released as a reference document explaining the F3 format. A bottom up approach is preferred because it is usable within a reasonable time frame. F3 starts with the internal format used by the Gitea project because it has a better chance of being implemented natively and reach a significant audience. From there, the format is generalized, the documentation improved until it can be applied in the context of other forges. The “bottom” is the Gitea internal format and it is incrementally improved “up” to the point where it fits all existing forges.

By contrast, a top down approach that would consist of designing a theoretical format would be very challenging as it requires a consensus from all forge implementors to be approved.

Go package reference implementation

The Go reference implementation for F3 is meant to cover all aspects of the specifications. It is developed at the same time as the specifications, in a short feedback loop that allows to quickly identify aspects of the specification that are either ambiguous, difficult to implement or understand.

It provides three interfaces:

  • The command line interface which is most convenient for exporting and importing a software project from and to a software forge that does not yet natively implement the F3 format.
  • The F3 API which is meant to be used for high level import, export and mirror operations.
  • The F3 driver API which is meant to be used by forge implementors to natively support F3.

The simpler native integration using the F3 API would rely on the REST API of the forge and require little work from the implementor. But it would also be subject to the limitations imposed by the API (such as assigning identifiers to objects like issues or milestones). The better native integration requires writing a F3 driver to use the internals of the forge and use functions not available from the API.

Python package reference implementation

The Python reference implementation demonstrates how the Go package can be used from another language. It could be used by the Pagure forge to provide basic import, export and mirroring features. Such an integration would not require the implementor to know the details of the F3 specifications as the bulk of the work is already implemented in the Go package. Only the F3 API is available in this context.

The value of this implementation is primarily to encourage developers to share a single implementation of the format rather than fragmenting its interpretation by working on multiple implementations in many languages.

First release

The release of the F3 format is published simultaneously with the Go reference implementation, under the same semantic version. It provides the following guarantees to the user:

  • Backward compatibility:
    • Every effort is made for a version to be compatible with the previous versions
    • If a breaking change cannot be avoided, the reference implementation provides a conversion method to upgrade existing F3 archives
  • Non ambiguous: each aspect of the specifications is precisely documented, the reader does not need to interpret ambiguous statements
  • Semantic versioning: the user knows if a breaking change is introduced by reading the version number
  • Detailed release notes: each modification to the specification is explained in detail in the release notes so the reader can to understand their consequences without exploring other sources of information

The development releases happen once a month but do not provide the same guarantees. The stable releases of the reference implementation may receive security patches and bug fixes but will not receive new features. Similarly, the stable releases of the specifications may receive patches when an error is found or an ambiguity requires rewording but their semantic will not change.

Integration in the Gitea codebase

The Go reference implementation is the basis of a native integration in the Gitea codebase which is also written in Go. Ideally such a native integration is implemented by the developers of the software forge. But since F3 is an emerging standard, there is not enough incentive for that to happen. This integration is meant to be a feature addition to the Gitea codebase as well as an example to show how F3 can be natively integrated in other forges.

Submission to a standard body

Although it is premature to expect that F3 is accepted by an standard body, the process to develop a new standard within OASIS or W3C is very involved and it should be engaged as soon as possible. The objective is to properly apply to at least one standard body and share the required knowledge with all members of the community working on the F3 specifications and reference implementation.

Activities

User Research

Deliverable: A User Research report including recommendations for developing F3
Effort: 10 days

Specification and documentation

The F3 Specification includes:

  • An introduction
  • JSON Schema with embedded documentation
  • Release notes
  • A normative file hierarchy
  • A glossary of terms and their definition

Deliverables:

  • JSON Schema for F3 are published in a dedicated repository
  • The documentation is published on a public web site

Effort: 30 days

Go package reference implementation

A reference implementation of F3 in Go provides:

  • An API for integration in a forge written in Go
  • Validation of a F3 archive (JSON Schema validation, VCS sanity checks)
  • Import, Export and Mirror support for Gitea and GitLab
  • Dataset generators and fixtures to verify the conformance with the specifications

Deliverable: The Go package is published at https://pkg.go.dev/
Effort: 70 days

Python package reference implementation

A reference implementation of F3 in Python provides:

  • An API for integration in a forge written in Python
  • The same features as the Go package reference implementation

Deliverable: The Python package is published https://pypi.org/
Effort: 5 days

First release

The first F3 release is a bundle that includes:

  • The specifications and documentation
  • The Go reference implementation
  • The Python reference implementation

They are verified to be consistent and tagged with the same version number.

Deliverable: simultaneous publication of F3 version 1.0.0 at:

Effort: 5 days

Integration in the Gitea codebase

The F3 Go reference implementation is proposed as an alternative to the internal format used for repositories dump and restore features in the Gitea codebase.

Deliverables: pull request merged in https://forgefriends.org or https://gitea.io
Effort: 5 days

Submission to a standard body

Reach out to OASIS and propose F3 as a new standard.

Deliverable: A submitted application acknowledged as received by OASIS
Effort: 5 days

How long will it take? (In Months)

12 months

Please elaborate on the technical feasibility of this effort.

The applicant is expected to provide a succinct description of the technical objectives of the effort, using appropriate terminology. The applicant should also provide any research/documentation of the feasibility/novelty of their technical approach, any hurdles or technical challenges they might encounter in implementation, and what they plan to do about it.

See the corresponding guide section

… we want to understand what the technical objectives of your efforts are, what technology design decisions you’ve made, and why you made those decisions.

An Open Standard is ultimately a single document easily distributed. Updating and publishing the document conveniently requires the tooling provided by software forges. A change is proposed on the forge, discussed there and merged. The continuous integration pipeline verifies there are no formatting errors and the development branch is updated. Upon release of the specifications, the continuous delivery pipeline updates the website so the newer version of F3 is distributed to the general public.

This workflow is familiar in the context of a Free Software project but it is less common when developing a standard. It is however more likely to facilitate participation from a larger community of developers, a facet that is essential to the long term sustainability of F3.

… you are aware of known challenges you might face implementing those technical objectives, and that you have a plan to address those challenges, and how they may affect the output of the effort.

F3 is a format that contains non trivial information and an ever growing number of objects. A reference implementation with a well defined API is both essential to its adoption and a technical challenge. To reduce the likelihood of fragmentation (diverging implementations of the F3 format) and minimize the development effort, the choice was made to develop the reference implementation in Go. The Go package can then conveniently be re-used as a module in libraries for other programming languages such as Python or Ruby. It will then be easier for forges such as Gitea (written in Go), GitLab (written in Ruby) or Pagure (written in Python) to rely on this reference implementation instead of implementing its own.

Please describe your usability/UX and accessibility practice for developing this tool.

Does the proposal demonstrate clear external demand for the proposed end product? Does the project demonstrate a high degree of usability and/or accessibility? Is the project targeting a small number of high value or at-risk users, or a broader population? Is the proposed effort appropriate for the intended audience?

See the corresponding guide section

Past community consultation and User Research

The Free Software community at large has been aware that centralized software forges is a problem for the entire corpus of FLOSS for over two decades:

In 2021 User Research was conducted to identify the need. It has never been done before and involved software forge developers, system administrators and Free Software developers. The result was published in June 2021 in a report. They expressed the need for communication between software forges. They explained, by providing concrete examples from their personal experience, the practical problems that arise because such communication does not exist.

The communities referenced in the State of the Forge Federation: 2021 to 2023 were consulted and reviewed the document which explains F3 in context. They include software forge developers (Gitea), software forge system administrators (Codeberg) and Free Software developers.

Future User Research and UX design

User Research will be conducted to identify the need of three personae using F3:

  • Free Software developers who are unlikely to read the F3 specifications but likely to use the reference implementation API
  • Software forge devops who will face challenges on behalf of the Free Software developers using their forges when F3 is involved in export/import or to mirror software projects, either automatically or manually
  • Software forge developers who will depend on the F3 specifications to natively implement F3, either from scratch or by using the reference implementation

The User Research report will influence the content of the specifications on each release, the backward compatibility process, the community engagement etc. It will also set priorities for the APIs of the reference implementation, either via the command line or programmatically.

The adoption of F3 is expected to be significantly improved with the answers collected by user research for questions such as:

  • Is the quality of the documentation important?
  • How much work is required from users when the release of a format is not backward compatible?
  • What format transformations are used most?
  • etc.

Internationalization and accessibility

Free Software developers all read English because most of the documentation they need for their work is only available in English, which lowers the requirement for internationalization. But not all of them are fluent and when the documentation is not available in their native language it makes it significantly more difficult to understand. Internationalization is therefore useful to:

  • Lower the barrier of entry for F3 users
  • Reduce the risk of incorrect interpretation of the specifications

The specifications will be translated in French and the project submitted to LocalizationLab to foster a community of translators for other languages.

The reference implementation will be internationalized and a workflow similar to the one in place for the SecureDrop project documented.

A self-hosted Weblate instance will be used to host both localization efforts (specifications and reference implementations).

Since the reference implementation has no user interface other than the command line and the programmatic API, internationalization is the only accessibility requirement.

Please describe the scope of this project’s alternative analysis. If the project has been audited before, please briefly describe the scope and outcome of those assessments, providing links to reports if available.

Does the project identify potential unintended consequences? Does it identify how an adversary might use the solution to further their own goals? Does the proposal consider potential illicit uses of the project? Does the proposal identify appropriate tactics for a potentially asymmetric position in relation to an adversary? Does the proposal consider sufficiently whether its approach is offensive or defensive in relation to the problem it is addressing? Does it explain why it has selected this approach (effort, cost, time, etc.)? Does the proposal discuss how the project could be undermined, identify its own deficiencies and limitation, or does it presume there are none? Does the proposal explore short-, medium-, and long‐term strategies from the adversary’s point of view? Does the project increase or decrease known attack surfaces?

See the corresponding guide section

Does the proposal discuss how the project could be undermined, identify its own deficiencies and limitation?

For the past twenty years, from SourceForge in 2001 to GitHub in 2022, the dominant actors providing centralized software forges developed undocumented specific formats to store the data they contain. The F3 effort to create an open standard is undermined when the dominant forge software makers do not participate. It is likely that they will keep refusing to participate in the next few years.

GitHub and GitLab strategy is to actively prevent and control communication between software forges and passively preventing a standardization effort like F3 is part of this strategy. Their primary goal is to facilitate user lock-in. Although the side effects of this strategy effectively threatens internet freedom globally, it is not a goal in itself for these organizations. It is therefore unlikely that they will actively work to undermine the F3 project.

There currently is a status quo: most Free Software development happens on a single software forge (GitHub). But there is no practical or theoretical limitation to replace GitHub with a multitude of software forges.

Does the project identify potential unintended consequences?

If a group of developers work in autonomy and rely on a set of software projects stored as F3 archives, it significantly changes the threat model. For instance, instead of a network of online actors, linked via GitHub, providing real time tooling for the supply chain to build the software, F3 creates a situation where the entire supply chain could be run offline. Threat modeling for a particular use case may uncover new threats that have not yet been taken into account.

Once F3 is usable, feedback from actors facing security threats should be collected by participating in their security audit and analysing the reports. The recommendations related to F3 will then be incorporated into the specifications and the reference implementation. This feedback loop is how unintended consequences could be discovered and addressed.

Does the proposal identify appropriate tactics for a potentially asymmetric position in relation to an adversary?

This would have to be considered in collaboration with an actor using F3 in a specific context. The F3 format and the reference implementation are not always used by an actor in an asymmetric position in relation to an adversary.

Does it identify how an adversary might use the solution to further their own goals?

If F3 archives are made available on a public repository that does not provide cryptographic signature verification or does not require them, malicious content can be distributed. Similar to what happens on a daily basis on PyPI with name squatting, for instance.

Are there other efforts similar to you what you are proposing? Does your work build on their work? What makes your approach different?

List other similar efforts to this proposed project. OTF expects this to include a review of any available technologies or programs and events that are similar to the project described. We want to understand how your project relates to others or how it can be distinguished from those that already exist. We are also looking for proof of the applicant’s understanding of the current landscape in the domain this project is situated.

See the corresponding guide section

The State of the Forge Federation: 2021 to 2023 published in June 2022 contains a detailed description of the projects related to F3. It is designed to be a building block that can be reused by all of them to facilitate the implementation of forge federation features.

F3 is different from ForgeFed. ForgeFed is an ActivityPub extension with its own vocabulary and models represented in JSON-LD. F3 is an JSON based Open File Format providing a strongly consistent representation of a software project at a given point in time. Despite these differences, there are overlaps: they both need to define a glossary of terms and explain concepts that are common between forges. This already led to contributions to Forgefed and more are expected in the future.

The forgefriends and ForgeFlux forge federation proxies will include F3 in their upcoming releases. This integration will be a showcase demonstrating how the Go and Python API can be used for integration in other software forges.

Deploying F3 in production is challenging because it does not yet have a reassuring reputation of stability and robustness. When problems are discovered, they will require a level of understanding and an investment in time from system administrators that most forge providers would consider too costly. However, the Gna! service provider is committed to advance forge federation and will deploy F3 as soon as it is available. It will likely be the first forge provider supporting F3.

Please describe your approach to monitoring and evaluating the outcomes and impact of this effort.

Describe how the project’s success will be evaluated and any metrics that will be collected related to the project’s outcomes and impact. By what metrics will you define the successful completion of the project? By what means will you determine that the project was successful in reaching its goals? OTF relies on these mechanisms to track and record the success of the project.

See the corresponding guide section

By what metrics will you define the successful completion of the project?

  • The frequency of stable releases of the F3 format
  • The frequency of stable releases of the F3 reference implementation
  • The number of forge service providers supporting F3
  • The number of developers using F3
  • The number of forges natively supporting F3
  • The number of people (paid staff and volunteers) participating in the evolution of F3 (format and reference implementation)
  • The funding obtained to sustain F3 as a whole

How are you planning to collect that information? And how will you document it?

The Frequency of stable releases is collected from the registry where they are published.

Lists of forge service providers, software forges and service providers are maintained in a repository, sorted to record those using or implementing F3 to keep track of them over time. As F3 becomes more popular it may be difficult to maintain such lists and the only way to collect that information would be to actively poll organizations and people.

People participating in the evolution of F3 are conveniently listed in the changes they authored in the VCS repositories. Some people provide advice’s instead of authoring a change that is recorded, which makes them more difficult to account for. Such mentoring is however important and relies on the memory of the people collecting the information manually.

The funding is systematically and publicly recorded in a spreadsheet and a forum and can be collected from there.

By what means will you determine that the project was successful in reaching its goals?

  • The F3 stable releases are published at least twice a year
  • All forges natively support F3 (hence all developers and forge providers)
  • There are more volunteers participating in F3 than paid staff
  • The funding covers the cost of running F3, including the paid staff salary

How will you collect and share learnings from this project?

In the first few years all information worth learning from is expected to be published in the F3 forum. Once a month all messages are browsed and a report is written as a digest. Something similar is done with the pull requests from the F3 specifications and the reference implementation. The authors of the report will do their best to write it in an objective and dispassionate way but they will inevitably make choices that reflect their own interest.

The monthly report allows for participation from people who are not engaged daily in the project by providing them with a high level view. In addition to the synchronous communication channel (Matrix chatroom) and the asynchronous communication channel (Forum), a recurring meeting is organized to share learnings with all stakeholders:

  • A monthly report is published to reflect the progress of F3
  • A monthly videconference is organized and open to the public to discuss the monthly report
  • A presentation of the progress of F3 is made in a synthetic way during a webinar once a year

Do you expect any major milestones during this project?

The first stable release of the F3 format and the Go reference implementation.

What instrument or process will you use to document the impact of this project on your local community, beneficiaries, or Internet freedom ecosystem?

The projects supported by OTF and their dependencies will be approached and invited to participate in User Research initially. Their input will define themes that matter to them and when the implementation is stable, they will be invited to use F3 to solve the problem they have. The impact will be positive if the need observed during the User Research phase is fulfilled by the F3 release.

What’s your long term strategy for this project beyond OTF support?

Sustainability can be measured in different ways. Please explain how this effort will achieve sustainability. This can include funding received from other funders or other revenue models, collaborations with organizations beyond the funding phase, an active community network and others.

From the mail inviting to send an application: “make sure to integrate your feedback into the proposal also, and please elaborate on the community engagement plan”

See the corresponding guide section

… how this effort will achieve sustainability over the funding period and beyond.

F3 needs to evolve to keep up with the evolution of software forges. As new development methods and tools are implemented, F3 must be updated to represent them. If it is to succeed, it will require an active engagement from dozens if not hundred of developers over decades. A likely scenario involves a few full time paid staff whose mission is partly to advance F3 on a technical level (release cycle, online resources, etc.) and partly to empower a larger community of volunteers (on-boarding, training, meetings, roadmaps, etc.).

… funding received from other funders or other revenue models.

During the first years, F3 is bootstrapped by seeking funding with OTF, NLnet and European R&D tax relief schemes. The goal is to create the conditions for F3 to be natively supported by each forge and facilitate participation in the maintenance of the F3 by all stakeholders. At which point the organizations developing the forges as well as the service providers selling services based on Free Software forges will have a vested interest in devoting a fraction of their revenue to keep F3 going.

… collaborations with other organizations and your role and relation to communities around your project.

F3 is developed bottom up (see above for a detailed explanation) to become a de-facto standard. As it matures a dialog with standard bodies such as OASIS or W3C will be engaged. The goal is that ultimately one of them supports F3. In the meantime relationships with organizations and people developing software forges (Gitea, GitLab, etc.) are the primary focus because they are involved in making the native support of F3 a reality. Organizations running forges (Framasoft, Codeberg, Gna!, etc.) as well as Free Software providers (Webarchitects, Easter-Eggs, Bearstech, etc.) have an incentive to be early adopters of the F3 reference implementation (to migrate and mirror software projects, for instance). Finally, the Free Software developer community is the primary community involved in User Research to sort out F3 priorities.

… how this project provides resources to others or how others can reuse the resources you develop.

F3 is developed in the context of the forgefriends project, a horizontal community with a radically transparent governance. Anyone and everyone has access to all the resources of the project, subject to their acceptance of the Code of Conduct. The resources developed by F3 are all released under a Free Software license.

Adoption efforts

Wide adoption of F3 is difficult to achieve, it requires a long term effort. But can be done incrementally.

The adoption of F3 will require:

  • endorsement by a standard body
  • a concise, precise and unambiguous documentation
  • complete and reliable reference implementations in multiple programming languages
  • native integration in all major software forges

At present the primary adoption blocker is that GitHub is unlikely to support F3 or any other Open Format facilitating software project migration and mirroring.

An incremental adoption should start by:

  • creating the format with a bottom up approach (see above for a detailed explanation)
  • providing a reference implementation
  • focusing on practical advantages this reference implementation brings to Free Software developers (e.g. cross forges issue tracking)

Further iterations will then expand the scope of the F3 specifications and provide additional practical advantages via the reference implementation to drive the change.

Why are you, and your team members, the right people to work on this project?

You can describe your previous work, link to relevant past projects, or explain other forms of knowledge of the subject matter. We are also interested in learning about your experience in working with users described. Have you worked with them before, how are you connected? Do you consider yourself part of the target audience? Ideally, you can also describe your connections to partners and other relevant actors in the field.

See the corresponding guide section

In 2017 and 2018 I worked on SecureDrop and authored hundreds of commits. I spearheaded the internationalization of the codebase and organized a team of translators in cooperation with Localization Lab. During this time I occasionally worked with journalists and whistleblowers, addressing their needs with training or software development. I spearheaded the User Research effort in SecureDrop in cooperation with Open Source Design.

In 2020 I worked for La Maison des Lanceurs d’Alerte and setup their information system from scratch, training and supporting the legal team, the staff as well as the volunteers. In this context I also provided technical support to whistleblowers in France and abroad when there was a suspicion they could be targeted by state actors or powerful adversaries.

Since January 2021 I worked full time with https://forgefriends.org, https://forgefed.org, https://gitea.io to advance forge federation. I made contributions to the forgefed specification and played an active role in reviving the project with a broader community.

The forgefriends project is a proxy designed to enable federation for software forges that do not yet implement it natively. I participated in forgefriends from the start, in January 2021. I authored most of the code and documentation that exist today. I published activity reports on a monthly basis and organized videoconferences to keep the larger community up to date.

Back in 2001 I created and maintained https://savannah.gnu.org as an alternative to SourceForge.

Please provide a budget narrative explaining the budget required to execute your proposed project.

Please include in your narrative the budget associated with individual objectives, activities and their associated deliverables. Please also include and describe major budget categories associated with this project. In addition to hourly or daily rates for labor, please include estimates of any expenses that would be supported by the requested funds, e.g.consultants, supplies, travel, etc.

See the corresponding guide section

The funds will exclusively be spent on paying for my time, at an hourly rate of 60USD. The global estimated effort is 130 days (as detailed in the list of activities) over a period of twelve months. There will be no other expenses and no sub-contractors.

Received today.

image


Dear Loïc Dachary,

Your application is now in “OTF Review” status (progressed from “Proposal Received”).

Please submit any questions related to your application here: OTF Apply | Login

Link to your application: OTF Apply | Login
If you have any questions, please submit them here: https://apply.opentech.fund/apply/submissions/14026/#communications

See our guide for more information: General Funding Guidelines - OTF Application Guidebook

If you have any issues accessing the submission system or other general inquiries, please email us at hello@opentech.fund

Kind Regards,
The OTF Team

1 Like

Sent today:


To: OTF

Hi,

Just making sure all is well and I’ve not missed anything from you.

Cheers

Sent today:


To: OTF

Hi,

Would you be so kind as to let me know if the review is in progress? I’m a little worried that I missed a step.

Thanks a lot!

Received today:


Hi Loïc,

Please forgive our delay in getting back to you, it has been a rather busy winter season.

Your proposal has been received and is being reviewed, thanks very much also for the questions you put together, our reviewers are taking those into consideration as they assess your proposal. Again, apologies for the delay in responding, I hope it hasn’t caused you too much stress.

We’ll provide you an update as soon as possible.

Best,


And replied


Hi,

Thanks for the update ! I’ll be patient no worries. Any insight as to how long it is likely to take?

Cheers

Sent today


Hi,

A gentle ping :slight_smile:

Happy new year

Received today:


Hi Loïc,

We are currently reviewing your application and should get back to you by end of this week.

Best,

Sent today


Hi,

This topic is still very relevant and it would make a significant difference to get more support.

Thanks in advance

Received today, with a 18 April 2023 deadline


The reviewers very much appreciate the concept of F3 and providing FLOSS alternatives to commercial software. We would ask that revise your original problem statement to emphasize the needs of HRDs, journalist, and activists that rely on software that can be developed in a secure, portable, and surveillance-free environment.

In addition we urge you to revisit your budget and factor in the true costs of development beyond the hourly cost of your labor.


Hi Loïc,

Many apologies for the delay in my response. We are still interested in your project and would like a bit more information. Would it be possible to set up a quick call in the next few days to talk about the feedback we sent to you?

Thanks again for your patience.

Best,


I replied:


Hi [redacted],

This is great news. I’m available most of the time, in the UTC+1 timezone. What about these?

  • 4pm UTC+1 5 April 2023
  • 4pm UTC+1 6 April 2023

At Jitsi Meet

If other times better fit your schedule, there is a very good chance I’m available.

Cheers

Received today:


Hi Loïc,

Apologies for the back and forth the team was in meeting all last week and I was slow to check my messages. Please let me know if you are available for a short call, Monday 17 April at 9:00. Or feel free to suggest a time. Also don’t worry about the deadline as we can extend it so you have enough time to respond.


Replied


Hi [redacted],

This time slot works for me too.

Monday 17 April at 9am UTC+1 at Jitsi Meet

See you then and have a nice weekend!

During today’s call (15 minutes) the questions were clarified as follows:

  • “We would ask that revise your original problem statement to emphasize the needs of HRDs, journalist, and activists that rely on software that can be developed in a secure, portable, and surveillance-free environment.” It is about providing a concrete example based on my previous experience working on SecureDrop and the MLA.
  • “factor in the true costs of development beyond the hourly cost of your labor.” Just making sure I did not forget to factor in taxes, which I did

I’ll work on the examples later today so they can be sent tomorrow, before the deadline expires.

Here is the reply I sent today.


Thanks for today’s conversation, it was very useful. Here are the answers to the questions, please let me know if they need more work.

The reviewers very much appreciate the concept of F3 and providing
FLOSS alternatives to commercial software. We would ask that revise
your original problem statement to emphasize the needs of HRDs,
journalist, and activists that rely on software that can be developed
in a secure, portable, and surveillance-free environment.

As suggested during our call, here is a concrete example to illustrate how F3 would have helped in the recent past, based on my first hand experience while working as a developer with the Freedom of the Press Foundation on the SecureDrop project.

In 2017 I began working on developing SecureDrop, attending weekly meetings and landing patches as a volunteer contributor. I also travelled around Europe to meet activists and journalists which allowed me to better understand their need and adapt SecureDrop accordingly. I focused on internationalization and localization because the human right defenders and journalist I met were often not fluent in English.

Over time I established a working relationship with a journalist who specializes in investigations involving state secrets. Together we built a threat model based on his past publications, current investigations and his usage of technical tools. It confirmed that they were targeted by intelligence services and that all their communications as well as the people surrounding them were monitored.

To improve the protection of their communications with sources, a new SecureDrop hardware was installed for their exclusive usage, as well as a dedicated Qubes OS laptop. everything in the setup was using off-the-shelves components, including a vanilla SecureDrop distribution. The architecture in place was entirely specific to their needs but no software component was modified.

As can be expected when someone uses a software such as SecureDrop on a daily basis, feature requests emerged from our discussions. One of them was to enable daily notifications to be sent, informing the journalist that messages were waiting to be picked up. Doing so in a way that did not leak information was delicate and it took weeks for the algorithm to be designed. The associated tests were carefully crafted to ensure future modifications did not introduce regressions that would weaken this protection. It all happened on GitHub and in public because it was generally useful.

Another feature request was specific to this journalist and unfit for inclusion in the standard SecureDrop. Because of my familiarity with the SecureDrop codebase, I had the technical ability to make a custom development. But I also became conscious that by engaging in this development I would expose the journalist I was trying to protect if the state actor monitoring them became aware of my work. I decided to implement the feature on an airgap machine to make sure it was not monitored. Although I was able to download the content of the git repositories to prepare the environment, I was not able to download the existing issues or pull requests or use the CI of SecureDrop itself or its dependencies. Not only did it make my work significantly more difficult, the release that I produced was also less tested than it should have been and its quality was lower than the one produced using the online GitHub environment.

If F3 had existed at the time, I would have had a convenient way to implement this feature offline with the same quality level than the standard SecureDrop distribution. That would have allowed me to better protect this journalist by having a fully functional copy of the SecureDrop development environment as well as its dependencies to develop this specific feature with the same level of quality that is expected when facing a threat from a state actor.

In addition we urge you to revisit your budget and factor in the true costs of development beyond the hourly cost of your labor.

As mentioned during our call, the proposed budget includes in the state taxes which are about 50% of the total amount. This leaves me with a net income that is a decent salary by French standards.

Received today from OTF:

image


Your application is now in “External Review” status (progressed from “Ready For Discussion”).