Un festival informatique aura lieu cette semaine à Saint-Pétersbourg . L'un des intervenants sera Richard Stallman. participe également au festival, et bien sûr nous ne pouvions pas ignorer le thème du logiciel libre. C'est pourquoi l'un de nos rapports s'appelle . Il sera consacré à l'histoire du développement d'Embox en tant que projet open source. Dans cet article, je souhaite parler des principales idées qui, à mon avis, influencent le développement de projets open source. L'article, tout comme le rapport, est basé sur une expérience personnelle.
Commençons par quelque chose de simple, avec la définition du terme opensource. Évidemment, un projet open source est un projet qui possède l'une des licences permettant d'accéder au code source du projet. De plus, un projet ouvert signifie que les développeurs tiers peuvent apporter des modifications. Autrement dit, si une entreprise ou un développeur publie le code de son produit, partiellement ou totalement, cela ne fait pas encore de ce produit un projet open source. Et enfin, toute activité de projet doit conduire à une sorte de résultat, et l'ouverture du projet implique que ce résultat ne soit pas utilisé uniquement par les développeurs eux-mêmes.
Nous n'aborderons pas les problèmes des licences ouvertes. Il s’agit d’un sujet trop vaste et complexe qui nécessite une enquête approfondie. De nombreux bons articles et documents ont été écrits sur ce sujet. Mais comme je ne suis pas moi-même un expert dans le domaine du droit d'auteur, je dirai seulement que la licence doit répondre aux objectifs du projet. Par exemple, pour Embox le choix d’une licence BSD plutôt que GPL n’était pas accidentel.
Le fait qu'un projet open source doive offrir la possibilité d'apporter des modifications et d'influencer le développement du projet open source implique que le projet soit distribué. Le gérer, maintenir l’intégrité et la performance est beaucoup plus difficile par rapport à un projet avec une gestion centralisée. Une question raisonnable se pose : pourquoi ouvrir des projets ? La réponse réside dans le domaine de la faisabilité commerciale : pour une certaine classe de projets, les avantages de cette approche dépassent les coûts. Autrement dit, elle ne convient pas à tous les projets et une approche ouverte est généralement acceptable. Par exemple, il est difficile d’imaginer développer un système de contrôle pour une centrale électrique ou un avion basé sur un principe ouvert. Non, bien entendu, de tels systèmes devraient inclure des modules basés sur des projets ouverts, car cela offrirait un certain nombre d'avantages. Mais quelqu’un doit être responsable du produit final. Même si le système est entièrement basé sur le code de projets ouverts, le développeur, après avoir tout regroupé dans un seul système et effectué des builds et des paramètres spécifiques, le ferme essentiellement. Le code peut être accessible au public.
Il y a également de nombreux avantages pour ces systèmes à créer ou à contribuer à des projets open source. Comme je l'ai déjà dit, le code système final peut rester accessible au public. Pourquoi, car il est évident qu’il est peu probable que quiconque dispose du même avion pour tester le système. C'est vrai, mais il se peut que quelqu'un veuille vérifier certaines sections du code ou, par exemple, que quelqu'un découvre que la bibliothèque utilisée n'est pas configurée tout à fait correctement.
Un avantage encore plus important apparaît si l'entreprise répartit une partie de base du système dans un projet distinct. Par exemple, une bibliothèque pour prendre en charge une sorte de protocole d'échange de données. Dans ce cas, même si le protocole est spécifique à un domaine donné, vous pouvez partager les coûts de maintenance de cette partie du système avec d'autres entreprises de ce domaine. De plus, les spécialistes capables d’étudier cet élément du système dans le domaine public ont besoin de beaucoup moins de temps pour l’utiliser efficacement. Et enfin, séparer une pièce en une entité indépendante que les développeurs tiers utilisent nous permet d'améliorer cette pièce, car il faut proposer des API efficaces, créer de la documentation, et je ne parle même pas d'améliorer la couverture des tests.
Une entreprise peut bénéficier d'avantages commerciaux sans créer de projets open source, il suffit que ses spécialistes participent aux projets tiers utilisés dans l'entreprise. Après tout, tous les avantages demeurent : les employés connaissent mieux le projet, donc ils l'utilisent plus efficacement, l'entreprise peut influencer l'orientation du développement du projet et l'utilisation de code prêt à l'emploi et débogué réduit évidemment 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 important des affaires que le marketing. Il s’agit pour lui d’un très bon bac à sable qui lui permet d’évaluer efficacement les exigences du marché.
Et bien sûr, il ne faut pas oublier qu'un projet opensource est un moyen efficace de se déclarer porteur de toute spécialisation. Dans certains cas, c’est la seule façon d’accéder au marché. Par exemple, Embox a commencé comme un projet visant à créer un RTOS. Il n’est probablement pas nécessaire d’expliquer qu’il existe de nombreux concurrents. Sans créer une communauté, nous n'aurions tout simplement pas eu suffisamment de ressources pour amener le projet à l'utilisateur final, c'est-à-dire pour que des développeurs tiers commencent à utiliser le projet.
La communauté est clé dans un projet open source. Il permet de réduire considérablement les coûts de gestion de projet, de développer et d'accompagner le projet. On peut dire que sans communauté, il n’y a pas de projet open source.
De nombreux documents ont été écrits sur la façon de créer et de gérer une communauté de projets open source. Afin de ne pas raconter des faits déjà connus, j'essaierai de me concentrer sur l'expérience d'Embox. Par exemple, le processus de création d’une communauté est une question très intéressante. Autrement dit, beaucoup expliquent comment gérer une communauté existante, mais les moments de sa création sont parfois négligés, considérant cela comme acquis.
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. Je veux dire qu’il n’y a 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. Il est peu probable que vous puissiez utiliser les mêmes règles lors de la création d'une communauté pour une bibliothèque de journalisation js et un pilote hautement spécialisé. De plus, aux différentes étapes de développement du projet (et donc de la communauté), les règles changent.
Embox a démarré en tant que projet étudiant car il avait accès aux étudiants du département de programmation système. En fait, nous entrions dans une autre communauté. Nous pourrions intéresser les participants de cette communauté, étudiants, aux bonnes pratiques industrielles dans leur spécialité, aux travaux scientifiques dans le domaine de la programmation système, aux cours et diplômes. Autrement dit, nous avons suivi l’une des règles de base de l’organisation d’une communauté : les membres de la communauté doivent recevoir quelque chose, et ce prix doit correspondre à la contribution du participant.
L'étape suivante pour Embox était la recherche d'utilisateurs tiers. Il est très important de comprendre que les utilisateurs participent à part entière à la communauté open source. Il y a généralement plus d'utilisateurs que de développeurs. Et pour vouloir devenir contributeur à un projet, il faut d’abord commencer à l’utiliser d’une manière ou d’une autre.
Les premiers utilisateurs d'Embox furent le Département de Cybernétique Théorique. Ils ont suggéré de créer un firmware alternatif pour Lego Mindstorm. Et même s’il s’agissait toujours d’utilisateurs locaux (nous pouvions les rencontrer en personne et discuter de ce qu’ils voulaient). Mais ce fut quand même une très bonne expérience. Par exemple, nous avons développé des démos qui pourraient être montrées à d’autres, car les robots sont amusants et attirent l’attention. En conséquence, nous avons eu de véritables utilisateurs tiers qui ont commencé à se demander ce qu'est Embox et comment l'utiliser.
A ce stade, il a fallu réfléchir à la documentation, aux moyens de communication avec les utilisateurs. Non, bien sûr, nous avions déjà pensé à ces choses importantes, mais c'était prématuré et n'a pas eu d'effet positif. L'effet a été plutôt négatif. Laissez-moi vous donner quelques exemples. Nous avons utilisé Googlecode, dont le wiki prenait en charge le multilinguisme. Nous avons créé des pages en plusieurs langues, non seulement en anglais et en russe, dans lesquels nous parvenions à peine à communiquer, mais aussi en allemand et en espagnol. En conséquence, cela semble très ridicule lorsqu'on le pose dans ces langues, mais nous ne pouvons pas répondre du tout. Ou bien ils ont introduit des règles sur la rédaction de la documentation et les commentaires, mais comme l'API changeait assez souvent et de manière significative, il s'est avéré que notre documentation était obsolète et était plus trompeuse qu'elle n'aidait.
En conséquence, tous nos efforts, même les mauvais, ont conduit à l’apparition d’utilisateurs externes. Et même un client commercial est apparu qui souhaitait que son propre RTOS soit développé pour lui. Et nous l’avons développé parce que nous avons de l’expérience et du travail de base. Ici, vous devez parler à la fois des bons et des mauvais moments. Je vais commencer par les mauvais. Étant donné que de nombreux développeurs étaient impliqués dans ce projet sur une base commerciale, la communauté était déjà assez instable et divisée, ce qui ne pouvait bien sûr qu'affecter le développement du projet. Un facteur supplémentaire était que l'orientation du projet était définie par un client commercial et que son objectif n'était pas le développement ultérieur du projet. En tout cas, ce n’était pas l’objectif principal.
En revanche, il y a eu un certain nombre d'aspects positifs. Nous avons de véritables utilisateurs tiers. Il ne s'agissait pas seulement du client, mais aussi de ceux à qui ce système était destiné. La motivation à participer au projet a augmenté. Après tout, si vous pouvez aussi gagner de l’argent grâce à une entreprise intéressante, c’est toujours bien. Et surtout, nous avons entendu un désir des clients, qui à l'époque nous paraissait fou, mais qui est désormais l'idée principale d'Embox, à savoir utiliser du code déjà développé dans le système. Désormais, l'idée principale d'Embox est d'utiliser le logiciel Linux sans Linux. Autrement dit, le principal aspect positif contribuant au développement ultérieur du projet a été la prise de conscience que le projet est utilisé par des utilisateurs tiers et qu'il devrait résoudre certains de leurs problèmes.
A cette époque, Embox dépassait déjà le cadre d’un projet étudiant. Le principal facteur limitant dans le développement du projet selon le modèle étudiant est la motivation des participants. Les étudiants participent pendant qu’ils étudient, et lorsqu’ils obtiennent leur diplôme, ils devraient avoir une motivation différente. Si la motivation n'apparaît pas, l'étudiant cesse tout simplement de participer au projet. Si l'on tient compte du fait que les étudiants doivent d'abord être formés, il s'avère qu'ils deviennent de bons spécialistes au moment où ils obtiennent leur diplôme, mais leur contribution au projet, en raison de leur inexpérience, n'est pas très importante.
En général, nous passons en douceur au point principal qui nous permet de parler de création d'un projet open source : créer un produit qui résoudrait les problèmes de ses utilisateurs. Comme je l'ai expliqué plus haut, la principale propriété d'un projet opensource est sa communauté. De plus, les membres de la communauté sont avant tout des utilisateurs. Mais d’où viennent-ils quand il n’y a rien à utiliser ? Il s'avère donc que, tout comme pour un projet non opensource, vous devez vous concentrer sur la création d'un MVP (produit minimum viable), et si cela intéresse les utilisateurs, alors une communauté apparaîtra autour du projet. Si vous êtes engagé dans la création d'une communauté uniquement via les relations publiques communautaires, en écrivant un wiki dans toutes les langues du monde ou en corrigeant le flux de travail git sur github, il est peu probable que cela ait une importance dans les premiers stades du projet. Bien entendu, aux étapes appropriées, ce sont des choses non seulement importantes, mais également nécessaires.
En conclusion, je voudrais souligner , à mon avis, reflétant les attentes des utilisateurs d'un projet open source :
Je pense sérieusement à passer à ce système d'exploitation (essayez au moins. Ils le poursuivent activement et font des choses sympas).
PS activé Nous aurons jusqu'à trois rapports. Un sur l'open source et deux sur l'embarqué (et un est pratique). Sur le stand, nous organiserons une master class sur la programmation des microcontrôleurs à l'aide . Comme d'habitude, nous apporterons le matériel et vous laisserons le programmer. Il y aura également une quête et d'autres activités. Venez au festival et à notre stand, ce sera amusant.
Source: habr.com