Source code version tracking system

Using a distributed version tracking system such as git is recommended. Svn or cvs systems are deprecated.

Help in choosing a web platform

In addition to the source code version tracking system, a web platform offers a range of associated collaborative tools and aims to mobilize a community of developers. These platforms may be hosted by a third party or by the administration.

Examples of web platforms hosted by a third party:

The source code of github.com is not free just like some modules of gitlab.com; some platforms publish anonymous data in open data; their geographic scope may vary, as well as the number of developers who use it. The list is incomplete.

The choice to create an organizational account within an existing Web platform is the responsibility of the administration, which can also host its own public forge.

Choosing a forge for a project must be done according to the level of collaboration expected and the interfaces with the private repositories and the rest of the development platform.

To know on which forge you should publish your source code, contact the maintaineur of this policy from your ministry. If you don’t know who you should get in touch with, send an email to opensource@data.gouv.fr.

Management of personal and organizations accounts

All projects initiated by an administration must be published in repositories under an organization accounts. Personal account repositories should only be used for temporary technical forks or personal developments.

Here are the recommendations for managing organization accounts or groups:

To handle repositories, it is recommended to have at least two organization owners and to publish the email address of at least one owner.

Inventory of organization accounts

A list of known forges and organization accounts from the public sector is readable in the comptes-organismes-publics file : if you happen to know a forge or an organization account that should appear in this list, please submit a pull request.

This list is used for code.etalab.gouv.fr which allows anyone to look for repositories within all forges and organization accounts.

You can also reference an organization account as a government account in GitHub:

  1. Register if you have not done so already in the community https://github.com/government/welcome

  2. Reference your organization account by adding it on the page: https://github.com/github/government.github.com/blob/gh-pages/_data/governments.yml as per https://government.github.com/community/

Distinction of personal / professional contributions

The distinction between personal and professional contributions is based on the associated email address. The contributor must change its email accordingly.

In the case of using git, this can be done easily:

git config user.email "firstname.lastname@ministere.gouv.fr"

git config user.email "email@perso.fr"

To find the email address currently used:

git config --get user.email

In cases where the contributor does not wish to see his personal identity attached to his contribution, an email address (or alias) need to be made available by the department to allow the use of a pseudonym. Beware some open source projects may refuse contributions under pseudonym.

Help in choosing the license

The choice of a license is also the choice of a community of developers and an ecosystem of associated tools. Once the license family is chosen, it is primarily the targeted developer’s community that determines the choice.

The recommended licenses by default are:

Multilicensing: It is possible to provide software under several licenses simultaneously, although this can lead to confusion.

Version Management

Having a versioning policy is recommended. The semantic versioning guide (https://semver.org/lang/en/) is a good example to follow.

Files in the repository

Make sure you have at least the README, CONTRIBUTING, and LICENSE files.

These files must be in plain text or with minimum marking (ie Markdown). It is not recommended to use binary formats (ie PDF).

Heads source files

According to the detailed recommendations in https://reuse.software each source code file must have its author, SPDX license ID, and a copy of the license in the local repository.

 / *
  * Copyright (c) 2017 Alice Commit <alice@example.com>
  * SPDX-License-Identifier: BSD-2-Clause
  * License-Filename: LICENSES / BSD-2-Clause_Alice.txt
  * /

or in the case of a project that automatically tracks its contributors:

 / *
  * This file is part of the project X. It's copyrighted by the contributors
  * recorded in the version of the history of the file, available from
  * its original location http://git.example.com/X/filename.c
  * SPDX-License-Identifier: BSD-2-Clause
  * License-Filename: LICENSES / BSD-2-Clause_Charlie.txt
  * /

To ensure software compliance, these identifiers enable to generate automatically inventories of licenses in the form of “Bill of Material”.

The complete list of SPDX identifiers is available at this address: https://spdx.org/licenses/

Traceability of development (DCO)

It is recommended to propose to contributors to sign a Developer’s Certificate of Origin. It allows her to attest that her contribution is genuine, respectful of previous works and that she accepts futur use for it under the project’s license. A French translation is made available DCO-Fr.txt and the english version is readble here.

In order to accept the DCO, the contributor only needs to sign off her commits with the command:

git commit --signoff (or git commit -s)

A DCO procedure should preferrably be set at the beginning of the project and it should be clearly stated in the CONTRIBUTING file of the repository.

Development practices

Best development practices also apply in the context of open development, and in particular those related to the normative documents enforced within the administration:

Opening the code also amplifies the importance of some of these best practices:

Documentation good practices

The recommendations below are not mandatory rules but define a goal. The quality of an open source project is closely related to the quality of its documentation, paying attention to this list is heavily recommended.


Identified interlocutor

It is recommended to identify a person in charge of the security of the project that will ensure compliance with best practices implemented during development, and to treat potential security incidents. It is also better to use a dedicated e-mail address to deal with security incidents or intellectual property issues which would be discovered by a third party.

Secure development

Do not rely on security by obscurity

Obscurity is generally recognized as an insufficient practice, but in the case of a project with open code, this strategy is deprecated. It must therefore be replaced by other more robust strategies such as defense in depth.

Secret / sensitive data, cryptography

Development tools and dependencies


The contribution policy is not intended to offer specific tools. However specifically for managing open code, you can find the referenced tools on https://www.linuxfoundation.org/tools-managing-open-source-programs/ useful.