Cette semaine à Saint-Pétersbourg se tiendra un festival IT. . Richard Stallman sera l'un des conférenciers. participe également au festival, et bien sûr, nous ne pouvions pas passer sous silence le sujet des logiciels libres. Ainsi, l'un de nos présentations s'intitule . Elle sera consacrée à l'histoire du développement d'Embox en tant que projet à code ouvert. Dans cet article, je souhaite partager les idées principales qui, selon moi, impactent le développement des projets open source. L'article, tout comme la présentation, est basé sur mon expérience personnelle.
Commençons par quelque chose de simple : la définition du terme open source. Il est évident qu'un projet à code ouvert est un projet ayant l'une des licences qui permettent l'accès au code source du projet. De plus, un projet ouvert implique la possibilité de modifications par des développeurs externes. En d'autres termes, si une entreprise ou un développeur publie le code de son produit, en partie ou complètement, cela ne fait pas nécessairement de ce produit un projet open source. Enfin, toute activité de projet doit aboutir à un certain résultat, et l'ouverture du projet implique que ce résultat est utilisé non seulement par les développeurs eux-mêmes.
Nous n'aborderons pas les problèmes des licences ouvertes. C'est un sujet trop vaste et complexe qui nécessite une analyse approfondie. Il existe déjà de nombreux bons articles et matériaux à ce sujet. Mais comme je ne suis pas un spécialiste en droit d'auteur, je dirai simplement que la licence doit répondre aux objectifs du projet. Par exemple, pour Embox, le choix de la licence BSD plutôt que de la GPL n'était pas fortuit.
Le fait qu'un projet open source doit permettre d'apporter des modifications et d'influencer le développement de ce projet open source implique que le projet est réparti. Le gérer, maintenir son intégrité et son fonctionnement est beaucoup plus complexe qu'un projet ayant une gestion centralisée. La question légitime se pose alors : pourquoi faire des projets ouverts ? La réponse repose sur la viabilité commerciale ; pour certaines catégories de projets, les avantages d'une telle approche l'emportent sur les coûts. Cela signifie que l'approche ouverte n'est pas adaptée à tous les projets et peut même être inacceptable. Par exemple, il est difficile d'imaginer le développement d'un système de gestion d'une centrale électrique ou d'un avion basé sur un principe ouvert. Certes, certaines parties de ces systèmes devraient inclure des modules basés sur des projets open source, car cela présente plusieurs avantages. Cependant, quelqu'un doit être responsable du produit final. Même si le système est entièrement basé sur le code de projets open source, le développeur, en regroupant le tout dans un seul système et en effectuant des compilations et des configurations spécifiques, le ferme en réalité. Le code peut cependant être accessible au public.
Pour ces systèmes, il existe également de nombreux avantages à créer des projets open source ou à y participer. Comme je l'ai déjà mentionné, le code du système final peut rester accessible au public. Pourquoi cela ? Car il est évident qu'il est peu probable que quelqu'un dispose d'un avion identique pour tester le système. C'est vrai, mais il pourrait tout de même y avoir des personnes souhaitant vérifier certaines sections du code, ou par exemple, quelqu'un pourrait découvrir que la bibliothèque utilisée n'est pas configurée correctement.
Un avantage encore plus grand se manifeste lorsque l'entreprise consacre une certaine part de son système à un projet distinct. Par exemple, une bibliothèque pour le support d'un protocole d'échange de données. Dans ce cas, même si le protocole est spécifique à un domaine donné, il est possible de partager les coûts de maintenance de cette partie du système avec d'autres entreprises du secteur. De plus, les spécialistes capables d'étudier cette portion du système en accès libre nécessitent beaucoup moins de temps pour en faire une utilisation efficace. Enfin, le fait de dissocier une partie en une entité autonome utilisée par des développeurs externes permet d'améliorer la qualité de cette partie, car il faut proposer des API efficaces et rédiger de la documentation, sans même parler de l'amélioration de la couverture des tests.
L'entreprise peut également tirer un bénéfice commercial sans créer de projets open source, il suffit que ses spécialistes participent à des projets externes utilisés au sein de l'entreprise. En effet, tous les avantages restent : les employés connaissent mieux le projet, ce qui leur permet de l'utiliser plus efficacement, l'entreprise peut influencer l'orientation du développement du projet, et l'utilisation de code déjà testé réduit clairement les coûts de l'entreprise.
Les avantages de la création de projets open source ne s'arrêtent pas là. Prenons un élément aussi essentiel que le marketing. Pour cela, c'est une très bonne plateforme qui permet d'évaluer efficacement les besoins du marché.
Et bien sûr, n'oublions pas qu'un projet open source est un moyen efficace de se faire connaître comme un acteur dans un domaine de spécialisation. Dans certains cas, c'est même le seul moyen d'entrer sur le marché. Par exemple, Embox a commencé comme un projet de création d'OSRV. Il n'est probablement pas nécessaire d'expliquer qu'il existe une multitude de concurrents. Sans la création d'une communauté, nous n'aurions tout simplement pas eu les ressources nécessaires pour amener le projet jusqu'à l'utilisateur final, c'est-à-dire pour que des développeurs externes utilisent le projet.
La communauté est la clé d'un projet open source. Elle permet de réduire considérablement les coûts de gestion du projet et d'en favoriser le développement et le soutien. On peut dire que sans communauté, il n'existe tout simplement pas de projet open source.
Il existe de nombreux documents sur la création et la gestion d'une communauté de projet open source. Pour ne pas répéter des faits déjà connus, je vais m'attacher à l'expérience d'Embox. Par exemple, une question très intéressante est celle du processus de création d'une communauté. En effet, beaucoup parlent de la gestion d'une communauté existante, mais les aspects de sa création sont parfois négligés, considérés comme une évidence.
La règle principale lors de la création d'une communauté de projet open source est qu'il n'y a pas de règles. Ce que je veux dire, c'est qu'il n'existe pas de règles universelles, tout comme il n'y a pas de solution miracle, ne serait-ce que parce que les projets sont très différents. On ne peut guère appliquer les mêmes règles pour créer une communauté pour une bibliothèque de journalisation en js et pour un pilote très spécialisé. De plus, à différentes étapes du développement du projet (et donc de la communauté), les règles changent.
Embox a commencé comme un projet étudiant, car nous avions accès à des étudiants du département de programmation système. En réalité, nous pénétrions dans une autre communauté. Nous pouvions intéresser les membres de cette communauté, les étudiants, avec une bonne pratique industrielle liée à leur spécialité, des travaux de recherche dans le domaine de la programmation système, ainsi que des projets de fin d'études. En d'autres termes, nous respections l'une des règles fondamentales de l'organisation d'une communauté : les membres doivent recevoir quelque chose, et ce qu'ils reçoivent doit correspondre à la contribution du participant.
La prochaine étape pour Embox a été la recherche d'utilisateurs externes. Il est très important de comprendre que les utilisateurs sont des membres à part entière de la communauté open source. Il y a généralement plus d'utilisateurs que de développeurs. Et pour avoir envie de devenir contributeur du projet, il faut d'abord, d'une manière ou d'une autre, commencer par l'utiliser.
Les premiers utilisateurs d'Embox étaient le département de la Cybernétique Théorique. Ils ont proposé de créer un firmware alternatif pour Lego Mindstorm. Bien que ce soient encore des utilisateurs locaux (nous pouvions les rencontrer en personne et discuter de leurs attentes), cela représentait tout de même une très bonne expérience. Par exemple, nous avons développé des démonstrations que nous pouvions montrer aux autres, car les robots sont amusants et attirent l'attention. Au final, nous avons eu de véritables utilisateurs externes qui ont commencé à demander ce qu'était Embox et comment l'utiliser.
À ce stade, nous avons dû réfléchir à la documentation et aux moyens de communication avec les utilisateurs. Bien sûr, nous avions songé à ces choses importantes auparavant, mais c'était prématuré et n'apportait pas d'effet positif. L'effet était plutôt négatif. Voici quelques exemples. Nous utilisions googlecode, dont le wiki supportait le multilinguisme. Nous avons créé des pages dans plusieurs langues, pas seulement en anglais et en russe, avec lesquelles nous pouvions communiquer tant bien que mal, mais aussi en allemand et en espagnol. Au final, cela faisait très bizarre de recevoir des questions dans ces langues sans pouvoir répondre. Nous avons également établi des règles sur la rédaction de la documentation et des commentaires, mais comme l'API changeait assez souvent et de manière significative, notre documentation devenait rapidement obsolète et prêtait souvent à confusion plutôt que d'aider.
En fin de compte, tous nos efforts, même s'ils n'étaient pas toujours corrects, ont conduit à l'apparition d'utilisateurs externes. Et même un client commercial est apparu, qui souhaitait que nous développions un système d'exploitation pour lui. Et nous l'avons fait, car nous avons de l'expérience et quelques acquis. Il est important de parler des bons et des mauvais aspects. Je vais commencer par les mauvais. Comme de nombreux développeurs ont été impliqués dans ce projet sur une base commerciale, la communauté, déjà assez instable, s'est divisée, ce qui a bien sûr eu un impact sur le développement du projet. Un autre facteur était que l'orientation du projet était dictée par un unique client commercial, dont l'objectif n'était pas de développer davantage le projet. Du moins, cet objectif n'était pas la priorité.
D'une part, il y avait plusieurs aspects positifs. Nous avons vraiment obtenu des utilisateurs externes. Ce n'était pas seulement le client, mais aussi ceux pour qui ce système était destiné. La motivation à participer au projet a augmenté. Après tout, s'il est possible de gagner de l'argent en s'occupant d'un sujet intéressant, c'est toujours agréable. Et surtout, nous avons entendu un souhait des clients, qui à l'époque nous paraissait insensé, mais qui est maintenant l'idée principale d'Embox, à savoir utiliser du code déjà développé dans le système. Actuellement, l'idée principale d'Embox est d'utiliser des logiciels Linux sans Linux. Ainsi, l'un des aspects positifs qui ont soutenu le développement futur du projet a été la prise de conscience que le projet est utilisé par des utilisateurs externes, et qu'il doit résoudre certains de leurs problèmes.
À ce moment-là, Embox avait déjà dépassé les limites d'un projet étudiant. Le principal facteur limitant le développement du projet selon le modèle étudiant est la motivation des participants. Les étudiants participent tant qu'ils étudient, mais une fois diplômés, une autre motivation doit apparaître. Si cette motivation n'apparaît pas, l'étudiant cesse simplement de participer au projet. Si l'on considère qu'il faut d'abord former les étudiants, cela signifie qu'ils deviennent de bons spécialistes au moment de leur diplôme, mais leur contribution au projet, en raison de leur inexpérience, n'est pas très importante.
En gros, nous passons en douceur au point principal qui permet de parler de la création d'un projet open source : créer un produit qui résout les problèmes de ses utilisateurs. Comme je l'ai expliqué ci-dessus, la principale caractéristique d'un projet open source est sa communauté. En effet, les membres de la communauté sont avant tout des utilisateurs. Mais d'où viennent-ils s'ils n'ont rien à utiliser ? Ainsi, tout comme avec un projet non open source, il faut se concentrer sur la création d'un MVP (produit minimum viable), et s'il intéresse les utilisateurs, une communauté apparaîtra autour du projet. En revanche, si l'on se concentre uniquement sur la création de la communauté par le biais de la promotion, de la rédaction de wikis dans toutes les langues du monde, ou d'un bon flux de travail Git sur GitHub, cela n'aura guère d'importance aux premières étapes du projet. Bien sûr, à des stades appropriés, ce sont non seulement des choses importantes, mais aussi nécessaires.
En conclusion, je voudrais mentionner , selon moi, reflétant les attentes des utilisateurs d'un projet open source :
Je envisage sérieusement de passer à ce système d'exploitation (du moins, d'essayer. Il est vraiment activement développé et des choses incroyables y sont réalisées).
P. S. Sur nous aurons pas moins de trois présentations. Une sur l'open source et deux sur l'embedded (dont une pratique). Sur notre stand, nous organiserons un atelier sur la programmation de microcontrôleurs avec . Traditionnellement, nous apporterons du matériel et ferons programmer les visiteurs. Il y aura également une chasse au trésor et d'autres activités. Venez au festival et sur notre stand, ce sera amusant.
Source : habr.com
