Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Collaboration entre industriels dans le domaine du transport

868 views

Published on

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

Published in: Software
  • Be the first to comment

  • Be the first to like this

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

×