Cette semaine déjà, à Saint-Pétersbourg, se tiendra le
TechTrain IT-festival. L'un des conférenciers sera Richard Stallman.
Embox participe également au festival, et bien sûr, nous ne pouvions pas ignorer le sujet des logiciels open source. Par conséquent, l'un de nos rapports s'intitule
«De l'artisanat étudiant au projet open source. Embox Experience .
” Il sera dédié à l'histoire d'Embox en tant que projet open source. Dans cet article, je veux parler des principales idées qui, à mon avis, affectent le développement de projets open source. L'article, comme le rapport, est basé sur une expérience personnelle.
Commençons par une définition simple du terme opensource. De toute évidence, un projet open source est un projet qui possède l'une des licences qui vous permet d'accéder au code source du projet. De plus, un projet ouvert implique la possibilité de modifications par des développeurs tiers. Autrement dit, si une entreprise ou un développeur publie le code de son produit, partiellement ou complètement, cela ne fait pas de ce produit un projet open source. Et enfin, toute activité de projet devrait conduire à l'apparition d'une sorte de résultat, et l'ouverture du projet implique que non seulement les développeurs eux-mêmes utilisent ce résultat.
Nous ne toucherons pas aux problèmes des licences ouvertes. C'est un sujet trop vaste et compliqué qui nécessite une enquête approfondie. Beaucoup de bons articles et matériaux ont été écrits sur ce sujet. Mais comme je ne suis pas moi-même un spécialiste du droit d'auteur, je peux seulement dire que la licence doit répondre aux objectifs du projet. Pour Embox, par exemple, choisir un BSD plutôt qu'une licence GPL n'était pas aléatoire.
Le fait qu'un projet ouvert doit permettre d'apporter des modifications et d'influencer le développement d'un projet ouvert implique que le projet soit distribué. Le gérer, maintenir l'intégrité et l'efficacité est beaucoup plus difficile par rapport à un projet avec une gestion centralisée. Une question raisonnable se pose: pourquoi des projets open-source? La réponse réside dans le domaine de la faisabilité commerciale; pour une certaine classe de projets, les avantages de cette approche l'emportent sur les coûts. Autrement dit, pas pour tous les projets, une approche ouverte est généralement acceptable. Par exemple, il est difficile d'imaginer le développement d'une centrale électrique ou d'un système de contrôle d'avion basé sur un principe ouvert. Non, bien sûr, cela vaut la peine d'inclure des modules basés sur des projets ouverts dans la composition de tels systèmes, car cela fournira un certain nombre d'avantages. Mais quelqu'un doit répondre pour le produit final. Même si le système est entièrement basé sur du code open source, le développeur, regroupant tout dans un seul système et réalisant des assemblages et des paramètres spécifiques, le ferme essentiellement. Le code peut être rendu public.
Pour ces systèmes, il existe également de nombreux avantages à créer des projets open source ou à y participer. Comme je l'ai dit, le code du système final peut rester dans le domaine public. Pourquoi, car il est évident qu'il est peu probable que quelqu'un ait le même avion pour tester le système. C'est vrai, mais il peut bien y avoir quelqu'un qui veut vérifier des sections individuelles du code, ou par exemple, quelqu'un peut trouver que la bibliothèque utilisée n'est pas tout à fait correctement configurée.
Un avantage encore plus important apparaît si l'entreprise alloue une partie de base du système à 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é, il est possible de partager les coûts de maintenance de cette partie du système avec d'autres entreprises de ce domaine. De plus, les spécialistes qui peuvent étudier cette partie du système dans le domaine public ont besoin de beaucoup moins de temps pour l'utiliser efficacement. Et enfin, mettre en évidence une pièce en tant qu'entité indépendante, qui est utilisée par des développeurs tiers, vous permet d'améliorer cette partie, car vous devez offrir des API efficaces, faire de la documentation, je ne parle même pas d'améliorer la couverture des tests.
Une entreprise peut obtenir des avantages commerciaux sans créer de projets ouverts, il suffit que ses spécialistes participent à des projets tiers utilisés par l'entreprise. Après tout, tous les avantages demeurent: les employés connaissent mieux le projet, ils l'utilisent donc plus efficacement, l'entreprise peut influencer la direction du développement du projet, eh bien, l'utilisation de code débogué prêt à l'emploi 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 de l'entreprise que le marketing. Pour lui, c'est un très bon bac à sable, qui vous permet d'évaluer efficacement les exigences du marché.
Et bien sûr, il ne faut pas oublier que le projet opensource est un moyen efficace de se déclarer porteur de toute spécialisation. Dans certains cas, c'est généralement le seul moyen d'entrer sur le marché. Par exemple, Embox a commencé comme un projet pour créer un RTOS. Probablement pas besoin d'expliquer qu'il y a un tas de concurrents. Sans créer une communauté, nous n'aurions tout simplement pas assez de ressources pour amener le projet à l'utilisateur final, c'est-à-dire que des développeurs tiers pourraient utiliser le projet.
La communauté est la clé du projet opensource. Il vous permet de réduire considérablement les coûts de gestion de projet, développe et soutient le projet. On peut dire que sans communauté, il n'y a aucun 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, je vais essayer de me concentrer sur l'expérience d'Embox. Par exemple, une question très intéressante est le processus de création d'une communauté. Autrement dit, beaucoup disent comment gérer la communauté existante, mais les moments de sa création sont parfois négligés, la considérant comme une donnée.
La règle principale lors de la création du projet communautaire open source - il n'y a pas de règles. Je veux dire, il n'y a pas de règles universelles, tout comme une solution miracle, ne serait-ce que parce que les projets sont très différents. Il n'est guère possible d'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, à 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 il y avait accès aux étudiants du Département de programmation système. En fait, nous sommes allés dans une autre communauté. Participants de cette communauté, étudiants, nous pourrions être intéressés par les bonnes pratiques industrielles dans leur spécialité, les travaux scientifiques dans le domaine de la programmation système, les mémoires et diplômes. Autrement dit, nous avons respecté l'une des règles de base de l'organisation de la communauté, les membres de la communauté doivent obtenir quelque chose, et ce prix doit correspondre à la contribution du participant.
La prochaine étape pour Embox a été la recherche d'utilisateurs tiers. Il est très important de comprendre que les utilisateurs sont des membres à part entière de la communauté opensource. Il y a généralement plus d'utilisateurs que de développeurs. Et afin de vouloir devenir un contributeur au projet, ils commencent d'abord à l'utiliser d'une manière ou d'une autre.
Le premier utilisateur d'Embox a été 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 encore d'utilisateurs locaux (nous pouvions nous rencontrer en personne et discuter de ce qu'ils voulaient). Mais c'était quand même une très bonne expérience. Par exemple, nous avons développé des démos qui pourraient être montrées aux autres, car les robots sont amusants et attirent l'attention. En conséquence, nous avons eu de véritables utilisateurs tiers qui ont commencé à demander ce qu'était Embox et comment l'utiliser.
A ce stade, il fallait penser à la documentation, aux moyens de communication avec les utilisateurs. Non, bien sûr, nous avons pensé à ces choses importantes auparavant, mais c'était prématuré et cela n'a pas eu d'effet positif. L'effet a été plutôt négatif. Permettez-moi de vous donner quelques exemples. Nous avons utilisé le googlecode, dont le wiki supportait le multilinguisme. Nous avons créé des pages en plusieurs langues, non seulement l'anglais et le russe, qui pouvaient mal communiquer, mais aussi l'allemand et l'espagnol. En conséquence, cela semblait très ridicule lorsqu'on lui a demandé dans ces langues, mais nous ne pouvons pas répondre du tout. Ou ils ont introduit des règles pour la rédaction de la documentation et les commentaires, mais comme l'API a changé assez souvent et de manière significative, il s'est avéré que notre documentation était dépassée et trompeuse plus qu'elle ne l'aidait.
En conséquence, tous nos efforts, même pas corrects, ont conduit à l'émergence d'utilisateurs externes. Et même un client commercial est apparu qui voulait qu'il développe son propre RTOS. Et nous l'avons développé parce que nous avons de l'expérience et quelques développements. Ici, vous devez parler des bons et des mauvais points. 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é, et donc plutôt instable, s'est divisée, ce qui bien sûr ne pouvait qu'affecter le développement du projet. Un autre facteur était que la direction du projet avait été établie par un client commercial et que son objectif n'était pas de poursuivre le développement du projet. Au moins, cet objectif n'était pas le principal.
En revanche, il y avait un certain nombre de points positifs. Nous avons vraiment des utilisateurs tiers. Ce n'était pas seulement le client, mais aussi ceux à qui ce système était destiné. La motivation pour participer au projet s'est accrue. Après tout, si vous pouvez également gagner de l'argent sur une question 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 aujourd'hui l'idée principale d'Embox, à savoir utiliser le code déjà développé dans le système. L'idée principale d'Embox est désormais d'utiliser un logiciel Linux sans Linux. C'est-à-dire que le principal facteur positif contribuant à la poursuite du développement du projet a été la prise de conscience que le projet était utilisé par des utilisateurs tiers et qu'il devrait résoudre certains de leurs problèmes.
À cette époque, Embox dépassait déjà le cadre du projet étudiant. La principale contrainte au développement du projet selon le modèle étudiant est la motivation des participants. Les étudiants participent pendant leurs études et lorsqu'ils obtiennent leur diplôme, une motivation différente devrait apparaître. 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 de l'obtention du diplôme, mais la contribution au projet, en raison de l'inexpérience, n'est pas très importante.
En général, nous nous déplaçons en douceur vers le point principal, ce qui nous permet de parler de la création d'un projet open source - la création d'un produit qui résoudrait les problèmes de ses utilisateurs. Comme je l'ai expliqué ci-dessus, la propriété principale du projet opensource est sa communauté. De plus, les membres de la communauté sont principalement des utilisateurs. Mais d'où viennent-ils jusqu'à quoi utiliser? Il s'avère donc que, tout comme avec un projet non open source, vous devez vous concentrer sur la création d'un MVP (produit minimum viable), et si cela intéresse les utilisateurs, une communauté apparaîtra autour du projet. Si vous êtes uniquement impliqué dans la création d'une communauté via les relations publiques de la communauté, l'écriture d'un wiki dans toutes les langues du monde, ou un flux de travail git approprié sur github, il est peu probable que cela ait de l'importance dans les premières étapes du projet. Bien sûr, aux étapes appropriées, ce ne sont pas seulement des choses importantes, mais aussi nécessaires.
En conclusion, je veux faire un
commentaire , à mon avis reflétant les attentes de l'utilisateur du projet open source:
Je pense sérieusement à passer à cet OS (essayez au moins. Ils sont très actifs pour le scier et faire des choses sympas).
PS Chez
TechTrain, nous aurons jusqu'à trois rapports. Un sur l'open source et deux sur l'embarqué (et un pratique). Sur le stand, nous organiserons une master class sur la programmation de microcontrôleurs utilisant
Embox . Traditionnellement, nous apportons les glandes et les laissons programmer. Il y aura également une quête et d'autres activités. Venez au festival et à notre stand, ce sera amusant.