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
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:
From: OTF
Subject: Your application to Open Technology Fund: Friendly Forge Format (F3) - an Open Standard for autonomous Free SoftwareDear 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 | LoginThe 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 SoftwareDear 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/#communicationsSee 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
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?
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.
Friendly Forge Format (F3) - an Open Standard for autonomous Free Software
Loïc Dachary
60000
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.
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.
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:
And it unlocks the following use cases:
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.
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.
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
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.
Here is an hypothetical use case relevant to human right defenders in need of long term support:
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.
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:
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
With F3 it will only be necessary to maintain a migration process from:
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.
A reference implementation of F3 in Go provides:
Milestone: The Go package is published https://pkg.go.dev/
A reference implementation of F3 in Python provides:
Milestone: The Python package is published https://pypi.org/
The F3 Specification includes:
Milestones:
The first F3 release is a bundle that includes:
They are verified to be consistent and tagged with the same version number.
Milestone: simultaneous publication of F3 version 1.0.0 at:
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
12 months
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.
… 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.
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?
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?
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.
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.
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.
By what metrics will you define the successful completion of the project?
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?
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:
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.
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”
… 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.
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:
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:
Further iterations will then expand the scope of the F3 specifications and provide additional practical advantages to drive the change.
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
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.
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 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.
Here is first draft of the proposal.
Friendly Forge Format (F3) - an Open Standard for autonomous Free Software
Loïc Dachary
60000
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.
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.
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:
And it unlocks the following use cases:
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.
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.
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
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.
Here is an hypothetical use case relevant to human right defenders in need of long term support:
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.
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:
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
With F3 it will only be necessary to maintain a migration process from:
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.
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).
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.
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.
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.
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 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.
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.
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:
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.
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.
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.
Deliverable: A User Research report
Effort: 10 days
The F3 Specification includes:
Deliverables:
Effort: 30 days
A reference implementation of F3 in Go provides:
Deliverable: The Go package is published https://pkg.go.dev/
Effort: 70 days
A reference implementation of F3 in Python provides:
Deliverable: The Python package is published https://pypi.org/
Effort: 5 days
The first F3 release is a bundle that includes:
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
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
Reach out to OASIS and propose F3 as a new standard
Deliverable: A submitted application acknowledged as received by OASIS
Effort: 5 days
12 months
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.
… 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.
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?
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
User Research will be conducted to identify the need of three personae using F3:
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:
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:
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.
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?
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.
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.
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.
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.
By what metrics will you define the successful completion of the project?
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?
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:
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.
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”
… 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.
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:
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:
Further iterations will then expand the scope of the F3 specifications and provide additional practical advantages to drive the change.
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.
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 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.
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.
Friendly Forge Format (F3) - an Open Standard for autonomous Free Software
Loïc Dachary
60000
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.
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.
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:
And it unlocks the following use cases:
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.
Many vendor lock-in aspects are directly detrimental to the conditions needed to assure Internet Freedom:
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.
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.
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.
Here is an hypothetical use case relevant to human right defenders in need of long term support:
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.
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:
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
With F3 it will only be necessary to maintain a migration process from:
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.
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).
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.
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.
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.
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 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.
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.
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:
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.
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.
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.
Deliverable: A User Research report including recommendations for developing F3
Effort: 10 days
The F3 Specification includes:
Deliverables:
Effort: 30 days
A reference implementation of F3 in Go provides:
Deliverable: The Go package is published at https://pkg.go.dev/
Effort: 70 days
A reference implementation of F3 in Python provides:
Deliverable: The Python package is published https://pypi.org/
Effort: 5 days
The first F3 release is a bundle that includes:
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
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
Reach out to OASIS and propose F3 as a new standard.
Deliverable: A submitted application acknowledged as received by OASIS
Effort: 5 days
12 months
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.
… 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.
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?
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.
User Research will be conducted to identify the need of three personae using F3:
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:
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:
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.
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?
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.
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.
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.
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.
By what metrics will you define the successful completion of the project?
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?
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:
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.
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”
… 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.
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:
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:
Further iterations will then expand the scope of the F3 specifications and provide additional practical advantages via the reference implementation to drive the change.
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.
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 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.
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.
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/#communicationsSee 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
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
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:
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:
Your application is now in “External Review” status (progressed from “Ready For Discussion”).
Sent today to OTF:
Hi,
Do you have clarity on when a decision will be made by the external reviewer(s)? I’m kind of excited that this is the last step and curious about when to expect the final concusion.
Cheers
Sent today to OTF:
Gentle ping?