Quelle est la vie des créateurs de bibliothèques open source populaires? Bien sûr, c'est bien quand le résultat de votre travail aide de nombreuses personnes à travers le monde. Mais vous trouvez-vous submergé par des tâches qui ne sont même pas votre travail principal? Comment y faire face? Avec audace, peut-on déléguer des pouvoirs?
Michelle Weststrate est bien consciente de tout cela: sa bibliothèque
MobX compte plus de 17 000 étoiles sur le github, le nombre de ses contributeurs a depuis longtemps dépassé la centaine. Et bientôt Michelle viendra en Russie pour parler à HolyJS, alors les gars du comité de programme de la conférence (Dmitry
DmitryMakhnev Makhnev et Evgeny
bunopus Kot) lui ont posé des questions en détail: sur l'open source en général, et en particulier sur MobX, et sur les conférences.
Eugene: Pouvez-vous d'abord parler un peu de vous pour ceux qui ne vous connaissent pas?"Oui, bien sûr." Je m'appelle Michelle Weststrate (ce qui est trop difficile à prononcer pour la plupart des gens), je viens des Pays-Bas. Le plus souvent, ils me connaissent grâce à mon travail sur MobX ou sur
immer . Je travaille pour Mendix. Nous créons des logiciels qui créent des logiciels: une plate-forme de développement d'applications que de nombreuses sociétés de conseil utilisent. Nous automatisons un grand nombre de compagnies d'assurance bancaire et de systèmes similaires. Je fais le côté technique - c'est-à-dire ce que j'aime. Et il y a environ deux ans, je me suis impliqué dans le monde open source, à partir de ce moment, j'ai été actif à la fois dans la communauté React et dans la communauté JS en général.
Eugene: Que faites-vous exactement à Mendix, y a-t-il des conseillers techniques?- Oui. J'ai plusieurs rôles différents là-bas, et le principal est Tehlid. Essentiellement, cela signifie que je suis responsable de la sélection des solutions techniques pour l'une de nos
«tribus» . Ainsi, je travaille sur un produit qui est un environnement pour les applications mobiles. Nous y travaillons avec quatre équipes, et principalement je prends les bonnes décisions architecturales et technologiques. De plus, je programme toujours. C'est une partie de mon travail.
Et l'autre est la participation à la communauté open source. Il s'agit d'une activité «bidirectionnelle». D'une part, nous faisons des choses techniques sympas que je veux partager lors de conférences, et je parle par moi-même ou j'encourage mes collègues à parler. Et d'un autre côté, le contraire est bon dans les visites fréquentes aux conférences: vous trouvez quelque chose qui peut nous être utile, puis nous l'étudions et l'incluons dans notre pile.
Eugene: OSS Evangelism est mentionné dans votre description Twitter. Qu'est-ce que c'est et pourquoi est-ce important pour vous?- La première raison pour laquelle cela est important: j'ai trouvé que si vous traduisez votre développement en open source, cela ne vous fait pas gagner du temps, mais cela aide beaucoup dans les tests et améliore la qualité. Parce qu'une bibliothèque comme MobX est utilisée dans des conditions très différentes. Et je pense que dans ce sens, l'open source donne un tel avantage qu'il est très difficile de l'obtenir d'une autre manière.
Et le second: je crois que nos développements «bas niveau» ne définissent pas l'entreprise, alors pourquoi ne pas les partager. Je veux dire, une entreprise est rendue plus ou moins compétitive par un produit qui est fabriqué sur la base de ses technologies - et non pas ces technologies par elles-mêmes. Et tout le monde profite de la collaboration, cela permet d'accélérer le développement dans son ensemble.
Eugene: Parfois, ils disent que l'open source "non-cash" est en fait un plaisir très cher. Des projets comme Linux nécessitent une tonne d'argent de géants comme Oracle et Microsoft. En est-il ainsi? Une communauté open source peut-elle exister sans gros fournisseurs et sans argent?- Je pense que cela dépend de la situation spécifique. Il y a de petites bibliothèques qui pourraient exister comme ça. Mais les projets comme le noyau Linux ou React Native mentionnés ci-dessus sont si complexes et tellement de gens en dépendent qu'ils ont besoin d'un modèle financier fiable. Dans ce cas, sans de gros sponsors, ce serait très difficile. Mais je ne pense pas que ce soit un problème. Je pense qu'il est plus important que les entreprises apprennent à assumer leurs responsabilités que nous apprenions à nous en passer.
Eugene: Par exemple, si Facebook vient à vous et vous dit «Achetons MobX ou sponsorisons-le pour que le développement passe sous notre marque»?- Eh bien, en fait, ils parrainent déjà! C'est drôle, mais Facebook est l'un des sponsors de MobX
à Open Collective . Donc, d'une certaine manière, cela s'est déjà produit. À mon avis, Open Collective est un excellent exemple de la façon dont nous pouvons améliorer la situation financière de l'open source. Il permet aux entreprises de parrainer le développement d'une manière qui leur convient, car il existe une approche financièrement sérieuse, avec des factures et autres.
Chez Mendix, je suis essentiellement payé beaucoup pour travailler sur MobX, donc je ne suis pas intéressé à passer complètement à Facebook. Je comprends que cela peut intéresser quelqu'un d'autre, mais je ne vois aucun problème à cela. À mon avis, si la licence reste open source, il n'y a rien de mal à ce que le produit passe sous la marque du sponsor principal. C'est comme regarder le football à la télévision: si tout le monde peut voir le match, il n'y a pas beaucoup de différence entre le logo sur les t-shirts.
Eugene: Si une grande entreprise sponsorise la bibliothèque, ne peut-elle pas dire "Puisque nous payons tant, alors s'il vous plaît, faites-nous cela"?"Je ne l'ai pas rencontré, au moins, de sorte que cela devient un problème." Si je ne me trompe pas, webpack utilise un tel modèle, il est possible d'y payer des fonctionnalités. Il y a donc un certain risque, mais je pense que c'est la responsabilité des mainteneurs de s'assurer que le projet reste fidèle à sa philosophie. Mais dans cette philosophie, il y aura probablement beaucoup de marge de manœuvre. Et d'ailleurs, en open source, si tout à coup quelque chose va complètement mal, au moins la possibilité de fork reste.
Eugene: Le développement d'un logiciel open source est comme une courbe: vous créez d'abord une bibliothèque dont personne d'autre n'a besoin, puis les gens commencent à l'utiliser, puis il gagne des milliers d'étoiles sur un github et ainsi de suite. Lorsqu'un projet open source devient populaire, il peut commencer à prendre beaucoup de temps. Combien dépensez-vous sur MobX?- Récemment, pas beaucoup. MobX est assez stable en ce moment. Bien sûr, j'ai beaucoup dépensé dans le passé. C'était très différent. Je pense que pendant les deux premières années, c'était quelques soirs par semaine, et il y avait beaucoup plus de petits moments où vous répondiez simplement à des problèmes mineurs ou à des questions sur Twitter. Ces petites choses ne sont pas ressenties comme un investissement important en temps, mais je pense qu'au total, elles s'ajoutent de manière significative. Cependant, il est très difficile à mesurer. Voici comment vérifier le courrier professionnel - vous vérifiez le problème et envoyez rapidement une réponse.
Eugene: Comment être productif dans une situation où vous êtes développeur, avez créé une bibliothèque, elle est devenue populaire et demande de plus en plus de temps? Vous avez de la chance, vous avez la possibilité de le faire pendant les heures de travail. Mais si vous avez déjà un travail et un hobby, et que le projet devient plus populaire?- Eh bien, quand j'ai commencé à travailler sur MobX, ce n'était que pendant mon temps libre, celui qui fonctionnait a été ajouté lorsque le projet a gagné en popularité. Mais j'ai quelques conseils. J'ai remarqué que plusieurs règles m'ont aidé.
Premièrement: gardez une trace de la pertinence de la documentation. Si vous avez reçu la même question trois ou quatre fois, assurez-vous d'enregistrer la réponse dans la documentation. Parce que cela vous fait finalement gagner du temps.
Deuxièmement: soyez très pointilleux sur le problème que vous acceptez. Au tout début, dès que vous êtes informé d'une erreur, vous essayez de reproduire le problème sur la base de la description disponible. Et dans certains cas, vous trouvez que c'est impossible, et le temps a déjà été dépensé. Par conséquent, maintenant je demande quelque chose que je peux exécuter directement à partir du problème, que ce soit un code dans le bac à sable ou une demande d'extraction avec des tests unitaires. Quelque chose qui me permet de déterminer où est le problème - dans la bibliothèque ou sur le côté utilisateur. C'est très important, car cela me permet de gagner du temps et de m'assurer que l'auteur du numéro est prêt à investir son temps. Certains disent: «Je n’ai pas le temps d’aider à reproduire le bogue» et j’ai le sentiment: «Eh bien, je n’ai pas le temps d’aider à résoudre votre problème.» Après tout, une personne est probablement payée pour le travail dans lequel elle utilise ma bibliothèque - pourquoi devrais-je alors investir mon temps libre dans son problème? En général, une telle sélectivité aide, même si elle vous fait vous sentir un peu moins responsable, car vous voulez aider tout le monde. Mais j'ai trouvé que «aider tout le monde» est tout simplement irréaliste.
Et pourtant, comme je travaille avec plusieurs bibliothèques, je ne réponds pas à tous les problèmes instantanément, mais «saute» d'une bibliothèque à l'autre: j'y travaille plusieurs jours à la fois, puis je passe au suivant. Et je peux vous répondre en quelques minutes si vous avez écrit sur celui que je fais maintenant, mais je ne peux pas répondre pendant des jours si votre tour n'est pas encore atteint. Cela m'aide à changer de contexte moins souvent.
Tous ces conseils sont utiles lorsque votre bibliothèque commence à gagner en popularité.
Eugene: Lorsque le créateur de la bibliothèque populaire répond "Je ne peux pas reproduire, écrire un test unitaire", cela ne fait-il pas ressentir aux gens "qu'il est arrogant et ne veut pas aider"?- J'ai rencontré un tel effet, mais très rarement. Je pense que généralement l'utilisateur comprend que les mainteneurs sont assez occupés et que le problème à forte probabilité est de son côté. Je pense que si vous utilisez le filtre Lodash et que vous avez un problème, il y aura un sentiment involontaire "probablement, quelque chose ne va pas chez moi, parce que tout le monde utilise Lodash". La plupart des gens comprennent donc qu'ils doivent être prudents en la matière.
Eugene: Lorsque la bibliothèque devient populaire et nécessite plus de temps, combien vaut-il la peine de partager votre rôle de contributeur, de donner des droits à d'autres membres de la communauté?- C'est une excellente idée, je donne généralement les droits d'un contributeur dès que je vois plusieurs bonnes demandes de tirage d'une même personne (ou même une seule demande de tirage, si elle est importante). À mon avis, cela fonctionne très bien. Par exemple, dans l'arbre d'état MobX, la plupart du travail est désormais effectué par d'autres personnes, pas par moi. Et il y a d'autres parties de la base de code que les gens comprennent mieux que moi, et c'est formidable que tout soit arrivé à cet état. Pour le MobX «de base», cela n'est pas nécessaire, car tout s'est déjà installé là-bas, les algorithmes n'ont pas changé au cours des deux dernières années, donc le travail de support est faible. Mais dans le cas de MobX-state-tree, j'ai délibérément choisi les personnes qui créent de nombreuses bibliothèques utilisateur et leur ai donné les droits du responsable. Après tout, si vous utilisez activement la bibliothèque dans votre travail quotidien, vous rencontrerez des modèles ou des problèmes courants que j'ai manqués. Et aussi, je pense, cela donne aux développeurs de la motivation et un sentiment de fiabilité - car ils peuvent aider la bibliothèque à travailler avec ce à quoi ils sont confrontés.
Eugene: En même temps, n'y a-t-il pas le sentiment que la bibliothèque, enfant, est battue? Peut-être n'êtes-vous pas d'accord sur la façon dont les autres personnes la développent?- Parfois ça arrive un peu. Mais je pense que c'est normal. Vous avez fait une grande analogie avec les enfants: au fil du temps, ils grandissent, ils ont 18 ans, et ensuite vous devez les laisser partir, car il est temps pour eux de trouver leur propre chemin. Je pense, dans une certaine mesure, également avec les bibliothèques open source. S'ils réussissent, alors vous commencez à faire face à des situations plus difficiles. Vous commencez à traiter des cas dont je ne voudrais généralement pas traiter. Le code ne sera plus le code beau, propre et minimaliste que je voulais à l'origine. C'est inévitable.
MobX en a un excellent exemple: j'ai écrit à l'origine pour TypeScript, où les décorateurs sont très simples, puis les gens ont commencé à l'utiliser avec Babel, où il existe une implémentation complètement différente. Et au final, certaines parties de la base de code sont très inesthétiques car elles essaient de déterminer si vous utilisez TypeScript ou Babel. Ça a l'air horrible et ça a l'air horrible. Mais cela fait partie du travail. Il n'est pas nécessaire de l'aimer, mais il faut s'assurer que tout fonctionne bien partout. Et dans ce sens, votre enfant peut aller dans une direction à laquelle vous n'avez pas pensé, mais c'est normal, car en fin de compte, il est important que les gens puissent utiliser le projet avec succès.
Eugene: Le développement change, beaucoup devient plus facile qu'il y a 10 à 20 ans. Que pensez-vous de la situation actuelle de l'open source en lien avec ces changements et qu'attendez-vous de l'avenir? Les grandes entreprises vont-elles devenir le moteur de tout le monde ou, au contraire, des passionnés?- C'est une question difficile. Pas sûr qu'il y aura de gros changements. Et il y a des changements dans les deux directions à la fois. Je suis particulièrement impressionné par Facebook et Microsoft - combien ils ouvrent maintenant et dans quelle mesure ils permettent aux développeurs tiers d'apporter une contribution. React Native est un exemple particulièrement frappant où une grande partie du travail ne vient pas de Facebook. D'un autre côté, pour un solitaire, il n'a probablement jamais été aussi facile de participer à un projet open source ou de créer le vôtre, comme c'est le cas actuellement. Les outils sont de plus en plus standardisés, nous avons d'excellents IDE en ligne comme
CodeSandbox et
Gitpod . J'ai travaillé avec Gitpod ces dernières semaines, et c'est génial: je peux vérifier les demandes de tirage sans même rien faire localement. Vous pouvez simplement exécuter Docker dans un navigateur et y développer. Je ne sais donc pas quels seront les changements.
Eugene: Il y a huit ans, lorsque j'étais développeur C ++, il n'existait pas de communauté open source comme maintenant. Et maintenant, dans le monde du web et de JavaScript, je vois que l'open source se développe de plus en plus vite. Cette croissance va-t-elle continuer?- Je pense que le mouvement va continuer. À mon avis, l'une des raisons est la suivante: les entreprises et les développeurs comprennent de plus en plus que l'open source n'est pas seulement utile à ceux qui le développent ou l'utilisent, mais aide également à trouver des employés. En regardant la participation d'une personne à l'open source, vous pouvez mieux comprendre à son sujet que si vous l'interviewez toute la journée. La façon dont il répond au problème ou les démarre en montre beaucoup. Je pense que les développeurs et les entreprises sont de plus en plus conscients de l'importance de cela.
Eugene: Vous pensez donc que le développement d'une bibliothèque open source peut vous aider avec une interview?- Exactement. Si vous êtes une entreprise et que vous avez de telles bibliothèques qui ne sont pas étroitement liées à votre API, c'est formidable, car les gens viendront y participer - et ils peuvent s'avérer être exactement ce dont vous avez besoin. Et si vous embauchez l'un de vos contributeurs, il sera plus facile pour eux de se joindre et vous comprendrez mieux à quoi vous attendre. Je pense que pour cette seule raison, beaucoup de choses intéressantes ont été ouvertes.
Dmitry: Nous avons parlé de l'open source en général, passons spécifiquement à MobX. Comment et pourquoi avez-vous commencé à le faire?- Bonne question. Chez Mendix, nous avons depuis longtemps une application Windows écrite en C #. Il y a quelques années, nous avons décidé de le porter sur le Web et avons commencé à déterminer quelle pile utiliser. React ne faisait que commencer, Angular existait depuis un moment, Ember était assez populaire. Et assez rapidement, nous sommes tombés amoureux de React en raison de son modèle de composant et de sa couche d'abstraction proposée.
Mais ensuite, nous avons constaté que nous avions un problème de performances, il s'est avéré que la mise à jour complète du DOM était assez chère, même dans le cas de React. En C #, nous avons constamment mis à jour le modèle et redessiné l'intégralité du canevas, et personne n'a optimisé quoi que ce soit, car tout fonctionnait très rapidement de toute façon, il n'était donc pas nécessaire «d'aborder le rendu de manière intelligente». Mais ici, nous avons constaté que dans le cas du DOM, vous ne pouvez pas tout redessiner 60 fois par seconde. Nous avons donc réfléchi à la manière de le faire efficacement. Nous avons pensé à l'approche immuable, mais dans notre cas, elle ne convenait pas pour plusieurs raisons. L'un d'eux est les données avec lesquelles nous avons travaillé et la façon dont elles ont été rendues. La même information a été rendue à divers endroits. Nos données sont très difficiles à normaliser. Et deuxièmement, il semblait que vous deviez encore faire face à trop de détails. Par exemple, vous devrez écrire des sélecteurs pour les données que vous rendez.
Mais que se passe-t-il si vous voulez écrire le même code simple que notre code C #, "rendre quelque chose" avant, et ne voulez pas vous soucier de la façon dont cela va changer à l'avenir? Si vous ne voulez pas dire aux composants "Alors, prenez cette partie des données d'ici, mais celle-ci à partir de là, et ensuite vous pouvez rendre quelque chose"? Nous avons commencé à étudier les technologies actuellement disponibles et nous sommes rapidement arrivés au paradigme utilisé dans Knockout, Meteor et (au moins sur le plan conceptuel), même dans Angular. Où vous ne voulez pas dire la relation entre les dépendances de données et les composants, ou ce qui doit être rendu quand.
J'ai commencé à comprendre pourquoi les gens détestent souvent de telles approches, en particulier lorsque l'application se développe. Et il s'est avéré que le plus souvent, les gens sont préoccupés par le manque de prévisibilité et de «débogage», que quelque chose peut être fait trop souvent, ou trop rarement, ou dans le mauvais ordre. Et j'ai décidé que nous pouvons faire mieux. Nous pouvons viser le même objectif, mais une approche plus intelligente de la mise en œuvre. Et c'est ainsi que MobX est apparu. Il ne capture pas seulement la relation entre les observables et les observables, mais crée un graphique de dépendance complet, de sorte que vous pouvez être sûr que tous les observateurs sont exécutés dans l'ordre le plus efficace. Dans la programmation réactive, il y a le concept de «pépin» - et donc, cela ne peut pas se produire ici. En général, une version existante a été prise ici, mais dans le but de la rendre plus prévisible.
Dmitry: Autrement dit, si j'aime une sorte d'approche, mais les bibliothèques existantes ne sont pas assez bonnes, vous pouvez simplement prendre et faire mieux, et cela peut devenir populaire?- Oui, exactement! Je l'ai donc écrit initialement pour nos besoins internes, puis je suis allé à ReactEurope. Cela semble être 2015, et il y a eu beaucoup de discussions sur les modèles de Flux. Puis la Flux Wars a fait rage. Et j'ai senti que les gens mettaient beaucoup d'énergie dans un problème que nous avons déjà résolu. « ». . , « Flux», - . .
: MobX , . , ?— ! « MobX Lite». , MobX, 200 . , . . , . MobX. , — API, . , , API . , MobX 5 MobX 4 ,
Proxy .
: Proxy. - , . ?— , , Proxy - , . . Chrome 8, , .
: . , jQuery -, , - . Redux MobX. ?— , . , jQuery- . , JQuery , . - . jQuery React , , , . . , state definitions .
, , React UI. . , - UI .
: ? , ?— , . , immutable values. , , immer — , immutable states JS. , state management. ,
, , . , , , GraphQL, , . …
: -, MobX?— , , , . . : , to-do list . , , todo. , - , todo- , . . , .
: . . , - . , ?— , . : , . — , , . , . Docker, . , , , . — « ». -, — , , . , , . — , , - . - -, , . , , . : -, , . .
: ( , ) , , Medium YouTube. ?— , , — . , . — . , , , … . . , . . , . , , . , , , , - . , . , (, , ) — . , , . .
: . — ?— . , MobX. , . MobX.
HolyJS 2018 Moscow , 24-25 . state management. .