Collaboration entre industriels dans le domaine du transport

699 vues

Publié le

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

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
699
Sur SlideShare
0
Issues des intégrations
0
Intégrations
27
Actions
Partages
0
Téléchargements
13
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • On va présenter le point de vue d’un « Editeur » et d’un « Réutilisateur / Contributeur »

    On parle ici de faire du logiciel libre sur son cœur de métier.
  • Images:
    Creative Commons CC0 1.0 Universal Public Domain Dedication
  • Echec de gouvernance : parce que quoi de mieux que des gens ayant échoué pour vous parler de la gouvernance ;-)
  • Maitrise Roadmap : on maitrise « son » planning
  • Réduction des couts
    Contributions sur périmètre utilisé
    Peu de partage sur les outils externes -> manque API
    L’ajout au modèle de donnée et en fct a un cout pour la maintenance
    Quand on utilise pas une fct, il est fort possible qu’on ne se rende pas compte d’une régression
    Généricité : votre besoin spécifique sera couvert sans patch, car le logiciel est pensé pour
    Releases  refactorings violents

  • Arbitrage fonctionnels : c’est le plus important : définir le « scope » et surtout le « hors scope » (Cf modularisation)
    Arbitrages techniques : développement et méthodes
    La modularisation
    Se mettre d’accord sur un petit périmètre fonctionnel est difficile, et impossible sur un gros


  • Travail sur l'openData avec les AO > intégration de l'OpenData dans le service ouvert navitia.io > mise en OS de l'application

    Eat your own dog food
    Data
    Service
    Source

  • Afin de ne pas ré-inventer plusieurs fois les mêmes algorithme, partageons-les!
    Et puis nous avons nous-même utilisé des librairies OS, il est normal de participer au fond commun
  • Afin de suivre l'ensemble des nouveaux besoins sans y mettre les moyens d'un GAFA
    Petite équipe, ne peut pas suivre
  • Envie partagée par les collaborateurs de devenir des contributeurs, de travailler en mode coopératif, en toute transparence
    Envie de faire les choses "biens", de se donner les moyens
    Et puis on découvre des équipes externe interne !
  • Image:
    Creative Commons CC0 1.0 Universal Public Domain Dedication
  • workshop
    meet-up
    petits dèj
  • Considérer sérieusement tous les besoins des contributeurs externes
    Même s'ils ne sont pas dans la roadmap interne
    Ne jamais refuser une demande
    Accompagner les contributeurs et assurer la coordination globale
    Rendre générique les besoins
    Architecture micro-service et interfaces pour permettre l’intégration de fonctions exotiques
    Toute nouvelle fonction, il faudra l’assumer et donc la tester.
    Valider tout impact d’une nouvelle fonctionnalité
    coûts de maintenance, tests, architecture…
    Lorsque l'équipe n'est pas d'accord, il faut recadrer le contributeur, sans le braquer pour ne pas le démotiver.

  • Scope et modèle de donnée : éléments critiques

    On peut ajouter facilement une fonction « exotique » mais pas maintenir un objet exotique

    l’extension et la généricité : ca peut être des modules, des objets abstraits (clef valeur) des API d’interface …

    => Parce qu’évidement un problème clef, est qu’un utilisateur qui ne couvre pas son besoin va partir (il ne renoncera pas à son besoin, il patchera, il forkera ou il abandonnera)

    Savoir acceptez un refus=> et faire en dehors ou autrement (c’est le parallèle du savoir refuser une demande de Stephan)
  • Le triptique IRC + GitHub + Mailing List est suffisamment « standard » pour qu’un nouveau venu sache comment s’impliquer
    PR=Imposer des contraintes de test

    Au sein d’une équipe de développement, on ne vote pas, on discute, mais l’architecte assume les choix techniques, le manager assume les arbitrages
    Le fork est une forme de vote : le dictateur est là pour éviter ça
    Confiance : on a confiance dans les contributions de chacun : on pousse en prod les releases
    Méritocratie : après plusieurs belles PR, votre code est intégré plus vite : c’est de la productivité
    Honnêteté : Une fois la confiance établie, on n’en abuse pas. Le dictateur doit être honnête (exemple TAD)
  • La direction générale doit suivre, et la chaine managériale doit assumer toutes les conséquence de cet engagement

    Adapter ces méthodes de dev (rythme release, méthodologie test, workflow, …)
  • Image:
    Creative Commons CC0 1.0 Universal Public Domain Dedication
  • Contraintes et impacts en terme d’archi
    Conception en micro-service
    Code source très découpé
    Process de PR et relecture systématique
    et ça a un coût
    Imposer les tests
    TU
    Tests d’intégration
    Application de ces process y compris en interne
    Et là, on y gagne!
  • Faire grandir la communauté
    pour avoir des discussions de qualité dans les salons IRC 
    Communication régulière pour maintenir informer la communauté
    Twitter, forum, newsletter
    Partage de la roadmap court et moyen terme
  • Construire des références
    Des exemples grand public live : on a la chance dans le transport public de pouvoir faire ça

    Association OpenService et Opensource
    Résout le dilemme : petit utilisateur / gros utilisateur

    Viser l’international dès le départ
    Surtout sur le core
    Damn. On aurait du faire cette présentation en anglais
  • Chercher d’abord à intégrer un projet existant
    -> C’est ce que Tisséo a fait plutôt que de repartir de zéro
  • Collaboration entre industriels dans le domaine du transport

    1. 1. Open Source: Retour d’expérience Collaboration entre industriels dans le domaine du transport
    2. 2. Kisio « Editeur » @stifoon – Stephan Simart Navitia Product Owner Tisséo « Utilisateur et Contributeur » @xavierraffin Software Architect & Project Manager Les acteurs
    3. 3. Contexte et historique
    4. 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. 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. 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. 7.  La gouvernance  Arbitrages fonctionnels  Arbitrages techniques  Communication externe  La méthodologie  La modularisation Tisseo : ce qui manquait Pourquoi passer à l’open source
    8. 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. 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. 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. 11.  Motivation des équipes de réalisation  Partage  Visibilité des réalisations  Transparence Kisio Digital Pourquoi passer à l’open source
    12. 12. La gouvernance dans Navitia
    13. 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. 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. 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. 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. 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. 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. 19. Si c’était à refaire
    20. 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. 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. 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. 23. Chercher d’abord à intégrer un projet existant ! Le syndrome NIH Pragmatisme Open Source

    ×