Bonjour,
Although the Freedom of the Press Foundation is a driving force behind SecureDrop, it would be good that the project governance is setup to include other stakeholders (users, the developer community, companies…).
There has been disagreements between FPF and the developer community in the past (about i18n for instance) and a sound governance would have helped reach a compromise.
For the sake of simplicity the governance could be roughly outlined and agreed upon informally as a first step. That would allow each person involved to voice their concern and the kind of guarantee they need to participate in SecureDrop.
For instance, I assume FPF needs to be able to effectively install & support every media with which there is a service contract. It means FPF employees are expected to fix whatever problem happens on a timely fashion and this highly depends on how familiar / comfortable they are with the codebase and the documentation. Should SecureDrop evolve outside of FPF control, this would create new kind of bugs, new features and new documentation for which FPF employee may not have enough expertise to provide the expected support.
Conversely, the community needs be able to improve SecureDrop even when FPF employees are busy with other things. When a contributor to SecureDrop can be trusted to follow the development workflow and preserve the quality/stability of the codebase/documentation, she/he expects features (such as i18n) will be merged when it is ready. If SecureDrop development stalls because of a bottleneck that is unrelated to the Free Software community (which is what happened with i18n), there is no sense of empowerment and participation is discouraged.
I believe we cannot resolve these tensions once and for all because they are in the nature of a community driven Free Software project. We should establish a balance of power which creates an incentive for each stakeholder to seek compromise. The ideal situation would be a community operating horizontally and voting on rules that have an impact on everyone (Debian GNU/Linux is the closes thing but I don’t know of any community setup in this way… yet).
This is all very vague 
But it is the state of mind that motivated me to work on i18n. I strongly believe FPF employees are willing to empower a Free Software community around SecureDrop. They have worked to establish a code base and process that are much better than they ever were, for this reason. They also agreed to set the i18n work in the roadmap, as a priority for 0.4.1. Not because they dedicated resources to it. But because they take the risk to trust a group of people outside of their control to do the right thing.
Another concrete step toward a more community driven SecureDrop is the management of resources created under the securedrop.club domain name (weblate and this forum). This domain is not exclusively controlled by FPF: it was setup by me and will be shared with whoever has time to participate in the maintenance of the associated resources.
Despite the best intentions, the devil is in the details and there are many ways for things to go wrong. We don’t have an example to follow, we need to invent something. It’s not terribly difficult either, as long as we don’t fool ourselves and stay creative.
What do you think ?