Conférence du Paris Open Source Summit 2015 Retour d'expérience sur la gouvernance d'un projet Open Source dans le domaine du transport public entre Kisio Digital et Tisséo. Par Stephan Simart et Xavier Raffin

1. Open Source: Retour d’expérience
Collaboration entre industriels dans le
domaine du transport

2. Kisio « Editeur »
@stifoon – Stephan Simart
Navitia Product Owner
Tisséo « Utilisateur et Contributeur »
@xavierraffin
Software Architect & Project Manager
Les acteurs

3. Contexte et historique

4. Historique
2001 201620122007 2010 2014 2015
Calculateur
itinéraire
interne
Mise en GPL
API exposée
en openData
Intégration
Navitia
Contribution
TimeTable
Généralisation
Navitia
Navitia 1
Transilien,
SNCF
vianavigo.com
mappy
API exposée en
openData
Navitia open
source
TimeTable
open source
TR
OpenSource
Indépendance
technique
Premier
échec de
gouvernance

5.  Pour l’indépendance
 Du sur mesure
 Maitrise Roadmap
 Maitrise des coûts
 Pérennité
 Simplification juridique
 Marchés & Achats
 Pas de vente de prestation intellectuelle
Tisseo : ce qui marchait bien
Pourquoi passer à l’open source

6.  Partage
 Réduction des couts
 Croissance de la base d’utilisateur
 Généricité
 Retour d’expérience
 Qualité logicielle
 Le code est éprouvé
 Le code est bien organisé
 Releases fréquentes
Tisseo : ce qui ne marchait pas
Pourquoi passer à l’open source

7.  La gouvernance
 Arbitrages fonctionnels
 Arbitrages techniques
 Communication externe
 La méthodologie
 La modularisation
Tisseo : ce qui manquait
Pourquoi passer à l’open source

8.  Suite logique d’une stratégie d’entreprise
 Open Data
 Permet d’améliorer les données en retour
 Open Service
 Permet d’améliorer l’interopérabilité
 Open Source
 Application plus diffusé= application plus stable
Kisio Digital
Pourquoi passer à l’open source

9.  Faire progresser l'humanité
 rien que ça !
 car nous sommes ambitieux…
 Et puis Navitia est elle-même composée de plusieurs lib
open-source
Kisio Digital
Pourquoi passer à l’open source

10.  Adapter rapidement l'application à plusieurs enjeux
distincts
 Révolution dans les mobilités
 covoiturage, auto-partage, VLS, solo-wheel...
 Temps réel dans une mobilité multi-modale
 Crowd-sourcing
Kisio Digital
Pourquoi passer à l’open source

11.  Motivation des équipes de réalisation
 Partage
 Visibilité des réalisations
 Transparence
Kisio Digital
Pourquoi passer à l’open source

12. La gouvernance dans Navitia

13.  Les contributeurs sont une tribu avec des fous rire
et des drames
 Mise en place d'un espace de dialogue en temps
réel
 Mise en place d'évènements fédérateurs
Entre développeurs
Première règle : le dialogue !

14.  Considérer sérieusement tous les besoins des
contributeurs externes
 Ne jamais refuser une demande mais la challenger
 Pourquoi ? Pourquoi ? Pourquoi ? Pourquoi ? Pourquoi ?
Pourquoi ? Pourquoi ?
 Savoir acceptez un refus
 Ne pas hésiter à répondre "fait-le si tu en as besoin,
c'est open-source"
Pour intégrer toute nouvelle fonction
Deuxième règle : le dialogue !

15.  Dialogue « ferme » sur le modèle de donnée
 Pas qui peut le plus peut le moins
 Scope clair et précis
 Le défendre
 Couvrir les besoin par l’extension et la généricité
Pour intégrer toute nouvelle fonction
Deuxième règle : le dialogue !

16.  Engagement et transparence sur les interfaces
 Les interfaces sont des contrats
 Ces contrats sont publics
 Suivre et définir les standards d’interface
 API et standards
 Démultiplie les opportunités
 Une ouverture au monde
Pour intégrer toute nouvelle fonction
Deuxième règle : le dialogue !

17.  Respect des « codes de conduite » OpenSource
 Pas de Bureaucratie
 Pas de vote mais une dictature bienveillante
 Confiance et méritocratie
 Honnêteté
 Les échanges sont publics
Suivre les standards communautaires
Troisième règle : le dialogue !

18.  Engagements réciproques
 Assumer le cout des merges
 L’effort de la qualité
 Adapter ces méthodes
 Négocier les contraintes Roadmap en interne
Un engagement au plus haut niveau
Gouvernance

19. Si c’était à refaire

20.  Contraintes et impacts en terme d’archi
 Process de PR et relecture systématique
 Imposer les tests
 Application de ces process y compris en interne
Développer une application OS

21.  Faire grandir la communauté
 Se montrer régulièrement
 Meet-up #OpenTransport
 #OSSPARIS15
 Communication régulière pour maintenir informer la
communauté
 Partage de la roadmap court et moyen terme
Evangélisation d’une application OS

22.  Construire des références et démonstrateurs
 Getting started in 5 minutes
 Association OpenService et Opensource
 Viser l’internationnal
Evangélisation d’une application OS

23. Chercher d’abord à intégrer un projet existant !
Le syndrome NIH
Pragmatisme Open Source