Inner source¶

Appliquer les principes de l'open source à l'intérieur de l'organisation pour casser les silos et accélérer le partage de code.

Qu'est-ce que l'inner source¶

L'inner source transpose les pratiques de l'open source dans un contexte d'entreprise : n'importe quel développeur de l'organisation peut contribuer à n'importe quel dépôt, selon des règles transparentes.

Contrairement à la collaboration classique ou les équipes sont des boites noires, l'inner source rend les dépôts visibles, accessibles et contributibles par défaut.

Différence avec la collaboration classique¶

Collaboration classique	Inner source
Un dépôt appartient a une équipe	Un dépôt est maintenu par une équipe, accessible à tous
Contribuer a un autre projet = demander	Contribuer = ouvrir une MR selon CONTRIBUTING.md
Les décisions sont dans des réunions	Les décisions sont dans des issues et des MR
La roadmap est interne à l'équipe	La roadmap est publique dans le projet

Les rôles¶

Maintainer (ou Trusted Committer)¶

Le maintainer est responsable de la sante du projet :

Il review et merge les contributions externes
Il maintient la documentation de contribution
Il communique la roadmap et les standards du projet
Il est le point de contact pour les contributeurs

Un maintainer n'est pas forcement le créateur du projet — c'est quelqu'un qui s'engage dans la durée.

Contributeur¶

Tout développeur de l'organisation qui ouvre une MR sur un projet qu'il ne maintient pas. Il suit les règles définies dans CONTRIBUTING.md et accepte le feedback du maintainer.

Guest contributor¶

Quelqu'un qui utilise le projet et signale des bugs ou propose des améliorations via des issues, sans forcement contribuer du code.

CONTRIBUTING.md : le contrat de contribution¶

Un fichier CONTRIBUTING.md est le document fondateur d'un projet inner source. Sans lui, les contributions arrivent n'importe comment et coutent plus qu'elles n'apportent.

Ce qu'il doit contenir¶

# Contribuer a [nom du projet]

## Avant de commencer

Lisez notre [Code of Conduct](CODE_OF_CONDUCT.md).

## Comment signaler un bug

Utilisez le template d'issue "Bug report". Incluez :
- La version du projet
- Les etapes pour reproduire
- Le comportement attendu vs observe

## Comment proposer une feature

Ouvrez une issue de type "Feature request" AVANT de coder.
Attendez un feedback du maintainer — vous eviterez de coder
quelque chose qui ne sera pas merge.

## Workflow de contribution

1. Forkez ou creez une branche depuis `main`
2. Nommez votre branche : `feature/<ticket>-description`
3. Suivez les conventions de commit (Conventional Commits)
4. Ouvrez une MR avec le template fourni
5. Repondez aux commentaires sous 5 jours ouvrables

## Standards techniques

- Linting : `make lint`
- Tests : `make test` (couverture minimum 80%)
- Documentation : toute API publique doit etre documentee

## SLA de review

Les maintainers s'engagent a repondre sous 3 jours ouvrables.

Workflow de contribution cross-équipe¶

sequenceDiagram
    participant C as Contributeur (Equipe B)
    participant I as Issue tracker
    participant M as Maintainer (Equipe A)
    participant CI as Pipeline CI

    C->>I: Ouvre une issue "Feature request"
    M->>I: Commente : "Oui, dans le scope du projet"
    C->>C: Code la feature sur une branche
    C->>M: Ouvre une MR
    CI->>M: Tests passes, lint OK
    M->>C: Review avec commentaires
    C->>M: Corrections appliquees
    M->>M: Merge dans main
    M->>I: Ferme l'issue, note dans le changelog

Inner source sans culture : le piegeage

L'inner source peut devenir un fardeau si les maintainers sont surchargés de MR externes qu'ils n'ont pas le temps de reviewer. Sans SLA définis et sans reconnaissance du temps passe en maintenance, les maintainers finissent par fermer les contributions par épuisement. Avant de lancer un projet inner source, assurez-vous que le temps de maintenance est reconnu dans la charge de l'équipe.

Gouvernance¶

Modèles de gouvernance¶

Modèle	Description	Adapté quand
Benevolent dictator	Un maintainer prend les décisions finales	Petit projet, vision forte d'un leader
Comite de maintainers	Décisions par consensus entre plusieurs maintainers	Projet strategique, plusieurs équipes
RFC obligatoire	Tout changement significatif passe par un RFC public	Projet a fort impact, nombreux contributeurs
Lazy consensus	Une décision est acceptee si personne ne s'y oppose sous 72h	Changements mineurs, équipe mature

Modèle de maturité inner source¶

graph TD
    M0["Niveau 0 : Opaque\nDepots prives par equipe\nPas de contribution possible"] --> M1
    M1["Niveau 1 : Lisible\nDepots visibles, pas de CONTRIBUTING\nContributions ad hoc"] --> M2
    M2["Niveau 2 : Contributable\nCONTRIBUTING.md present\nPremiers contributeurs externes"] --> M3
    M3["Niveau 3 : Actif\nSLA de review, templates\nContributions regulieres cross-equipe"] --> M4
    M4["Niveau 4 : Ecosysteme\nGouvernance formalisee\nContributeurs formes et reconnus"]

    style M0 fill:#c0392b,color:#fff
    style M1 fill:#e67e22,color:#fff
    style M2 fill:#f1c40f,color:#000
    style M3 fill:#27ae60,color:#fff
    style M4 fill:#2980b9,color:#fff

Par ou commencer¶

Choisissez un projet pilote : une bibliotheque interne utile à plusieurs équipes
Rendez le dépôt visible : lisibilite par défaut dans toute l'organisation
Ecrivez CONTRIBUTING.md : même minimal, il change tout
Definissez un SLA : les contributeurs ont besoin de savoir quand attendre une réponse
Communiquez : annoncez dans les canaux communs que le projet est ouvert aux contributions

Points clés¶

L'inner source rend les dépôts accessibles et contributibles, pas seulement lisibles
CONTRIBUTING.md est le contrat minimal pour recevoir des contributions saines
Le temps de maintenance doit être reconnu dans la charge des équipes
Commencez par un projet pilote, pas par un changement de politique global
La gouvernance formalisée n'est nécessaire que quand le projet grossit

Précédent : Conventions d'équipe | Suite : Bonnes pratiques