Pourquoi une entreprise de télécommunications publie son code
District AI fonctionne sur des logiciels à code source ouvert, et Distronode publie les siens : deux projets Apache 2.0 et des correctifs renvoyés en amont.
Lorsque vous confiez la ligne téléphonique de votre entreprise à un fournisseur, vous lui remettez quelque chose que vous ne pouvez pas voir. Vous ne pouvez pas suivre le trajet d'un appel, ni savoir qui le traite, ni ce qu'il advient ensuite de sa transcription. Vous devez croire le fournisseur sur parole.
Nous pensons qu'un client devrait avoir à nous croire sur parole le moins possible. Nous publions donc l'endroit où chaque type de données est conservé, nous nommons chaque entreprise externe qui nous aide à exploiter le service et, depuis cette semaine, notre travail à code source ouvert est réuni en un seul endroit : notre page Code source ouvert.
Ce billet explique ce qu'on y trouve, et pourquoi une entreprise de télécommunications s'en donne la peine.
Nous bâtissons sur le travail des autres, et nous le disons
District AI répond aux appels grâce à des logiciels que des milliers de personnes ont écrits et offerts à tous. Le système qui transporte l'audio d'un appel en direct est à code source ouvert. La base de données qui contient vos contacts et vos dossiers d'appels l'est aussi, tout comme le logiciel qui fait fonctionner nos serveurs dans chacune de nos quatre régions, et le petit programme qui détermine quand un appelant a fini de parler, pour que l'assistante sache que c'est son tour.
La nouvelle page nomme dix de ces projets, explique ce que chacun fait chez nous et indique la licence sous laquelle il est publié. Chacun accomplit un travail visible à chaque appel ou sur chaque page. Aucun n'est là pour allonger la liste.
Un nom bien connu en est absent, et c'est voulu. Nous utilisons Redis, mais sa licence actuelle n'est pas une licence de code source ouvert : il serait donc faux de le présenter comme tel. La page le dit.
Deux outils que nous avons construits, maintenant publics
En chemin, nous avons écrit deux logiciels qui méritent d'être partagés. Les deux sont libres d'utilisation sous licence Apache 2.0, et ce ne sont pas des vitrines : les dépôts publics sont ceux à partir desquels nous déployons, avec leurs tickets, leurs journaux des modifications et leurs politiques de sécurité à découvert.
bridgewatch est une petite application qui se loge dans votre barre de menus et qui indique à une équipe de développement si son dernier changement est réellement déployé. Nous l'avons écrite parce que chaque outil essayé répondait à une question légèrement différente. Notre propre système exécute une vérification automatique toutes les heures, et les outils essayés rendaient compte de cette vérification horaire plutôt que du changement que nous venions de faire. Pire encore, un seul changement chez nous lance plusieurs tâches distinctes, et aucun outil ne pouvait nous dire ce que le changement avait fait dans son ensemble. bridgewatch le peut. La version 1.0 est sortie le 19 septembre, pour macOS et Linux, et elle fonctionne avec GitLab comme avec GitHub.
District Scheduler est le moteur derrière chaque rendez-vous que fixe District AI, et derrière la page de réservation comprise dans chaque forfait. C'est notre version d'un projet de prise de rendez-vous à code source ouvert nommé Calnode. Nous y avons ajouté une chose que Calnode n'a pas : la capacité de cloisonner rigoureusement les calendriers de nombreuses entreprises à l'intérieur d'un même système, ce dont un service comme le nôtre a besoin. Cet ajout se trouve derrière un seul interrupteur. Désactivé, vous exécutez Calnode tel que publié.
Nous renvoyons les correctifs
C'est la partie qui nous tient le plus à cœur.
Quand on bâtit sur le logiciel de quelqu'un d'autre, on y trouve des bogues. On peut alors faire deux choses : corriger le bogue dans sa propre copie sans rien dire, ou renvoyer le correctif aux personnes qui maintiennent le projet d'origine, pour que tout le monde en profite.
Se taire est tentant, et c'est un piège. Un correctif privé doit être réappliqué à la main chaque fois que le projet d'origine publie une nouvelle version, et par la seule entreprise qui en connaît l'existence. Renvoyer le correctif signifie que la prochaine version le contient déjà, pour nous comme pour tout le monde.
Un correctif pour Calnode va donc à Calnode. Nos correctifs portant sur les types de rendez-vous dupliqués, la clarté des pages de réservation, la reconnexion des calendriers et la gestion des langues font aujourd'hui partie de Calnode, et chaque entreprise qui l'utilise en profite, pas seulement la nôtre.
Ce que cela change si vous êtes client
Vous n'avez pas à lire une seule ligne de code pour utiliser District AI, et rien ne change dans votre service. Ce qui change, c'est ce que vous pouvez vérifier.
Si vous voulez un jour savoir comment fonctionne réellement la prise de rendez-vous derrière votre page de réservation, ou si la question vient de la personne qui s'occupe de votre informatique ou d'un client pointu sur la protection des renseignements personnels, la réponse est publique. C'est pour la même raison que nous publions l'endroit où résident vos données et qui nous aide à les traiter. Une entreprise qui traite vos appels devrait être facile à vérifier.
Où trouver tout cela
Tout se trouve sur une seule page, avec des liens vers les deux projets sur GitHub et vers notre groupe sur GitLab. Les suggestions et les correctifs sont les bienvenus sur l'un ou l'autre projet. Si vous découvrez un problème de sécurité, veuillez le signaler à l'adresse indiquée dans la politique de sécurité du projet plutôt que publiquement, afin que nous puissions le corriger avant qu'il soit largement connu.
Questions fréquentes
District AI est-elle elle-même à code source ouvert?
Non. District AI est notre service commercial. Ce que nous publions, ce sont les logiciels à code source ouvert sur lesquels elle fonctionne, nommés un à un, et deux projets à nous sous licence Apache 2.0 : bridgewatch et District Scheduler.
Dois-je faire quelque chose en tant que client?
Non. Rien ne change dans votre service. Ce qui change, c'est ce que vous pouvez vérifier vous-même, tout comme la personne qui s'occupe de votre informatique ou l'un de vos clients.
Que signifie renvoyer un correctif au projet d'origine?
Quand nous corrigeons un bogue dans un projet à code source ouvert sur lequel nous bâtissons, nous remettons le correctif aux personnes qui maintiennent l'original, pour que la prochaine version le contienne pour tout le monde. L'autre option est un correctif privé qu'une seule entreprise doit réappliquer à la main indéfiniment.
Pourquoi Redis ne figure-t-il pas dans la liste?
Nous l'utilisons, mais sa licence actuelle n'est pas une licence de code source ouvert : le présenter comme tel serait faux.

