angle-uparrow-clockwisearrow-counterclockwisearrow-down-uparrow-leftatcalendarcard-listchatcheckenvelopefolderhouseinfo-circlepencilpeoplepersonperson-fillperson-plusphoneplusquestion-circlesearchtagtrashx

N'hésitez pas à réinventer la roue si vous voulez que votre logiciel avec les composants open source vive plus longtemps

La durée de vie de nombreuses composantes de open source peut être courte. Écrivez le vôtre si vous voulez vous assurer que votre logiciel continue à fonctionner.

10 mars 2020
Dans Flask
post main image
https://unsplash.com/@neilsoniphotography

Le problème : un client veut une application dotée d'une certaine fonctionnalité et la veut hier. Ce que vous faites, c'est chercher une solution "plug-and-play", des bibliothèques et/ou des extensions. Vous dites à votre client que vous pouvez le faire, que le client est content, que vous le faites. Par exemple, vous prenez Wordpress, vous sélectionnez et vous configurez quelques plugins. Le problème est résolu, ou l'est-il ?

Oui, le problème est résolu, mais pour combien de temps ? Après quelques mois, Wordpress est mis à jour en raison d'une vulnérabilité. Puis soudainement, certains plugins ou thèmes ne fonctionnent plus. Puis PHP est déplacé vers PHP 7.4 et à nouveau certains plugins ou thèmes ne fonctionnent plus. Au final, cela vous oblige, vous ou votre client, à utiliser des versions de logiciels plus anciennes, souvent vulnérables. Mais cela peut aussi être votre modèle commercial, les mises à jour.

Les grandes entreprises technologiques forcent le changement pour éliminer la concurrence

Il est très difficile de développer un logiciel qui dure quelques années. Les normes changent souvent à l'initiative des grandes entreprises technologiques. Bien sûr, elles veulent changer les normes. Elles appellent cela une amélioration, un progrès, mais il est tout simplement essentiel pour leur entreprise d'ajouter de nouvelles fonctionnalités et de supprimer les anciennes. C'est un moyen parfait et légitime d'éliminer la concurrence.

Par exemple, regardez ce que fait Google avec Android. Chaque année, ils publient une nouvelle version. Et tous les fabricants de téléphones doivent suivre. La nouvelle version est-elle meilleure ? La plupart du temps, non ! Ils font de grosses réécritures de certaines parties du code, donc si vous aviez essayé de comprendre et de vous habituer aux internes de la version X, vos connaissances ne valent rien quand la prochaine version est publiée. Oui, ils introduisent également de nouvelles vulnérabilités, mais ce ne sont que des erreurs. Une entreprise de logiciels multimilliardaire ne dispose bien sûr pas des ressources nécessaires pour analyser et tester ses logiciels de manière approfondie. Google a également forcé les sites web à utiliser HTTPS. Je sais que pour de nombreuses personnes non spécialisées en technologie, c'est une bonne idée. Mais maintenant, de nombreux sites web utilisent les certificats de Letsencrypt, une autre dépendance. Et les concurrents de Letsencrypt ne sont pas autorisés, merci à tous !

Open source les développeurs créent le changement

Je tiens à dire que je suis très heureux de la disponibilité du logiciel open source . Je respecte beaucoup les développeurs et les communautés de open source . Sans eux, le logiciel que nous utilisons aujourd'hui serait totalement différent. Le logiciel Open source oblige les grandes technologies à penser aux changements, à continuer à développer de nouvelles versions, à garder une longueur d'avance. À bien des égards, les développeurs de open source créent souvent des changements sans qu'ils le sachent.

La durée de vie du logiciel open source est souvent plus courte que celle des logiciels commerciaux

Si vous utilisez le logiciel open source pour construire vos applications, vous avez de nombreuses raisons d'être très prudent. Comme de nombreuses personnes l'ont déclaré, il est très difficile de gagner de l'argent avec le logiciel et les projets open source . Le logiciel Open source est souvent développé par une ou quelques personnes parce qu'elles en avaient besoin pour quelque chose et qu'elles le partagent ensuite avec le monde entier, en fait en le donnant. De nombreux développeurs espèrent que d'autres personnes s'impliqueront dans leur projet, mais ce n'est souvent pas le cas. Au bout d'un certain temps, le développeur commence à travailler sur d'autres projets ou obtient un travail qui lui prend beaucoup de temps et n'a pas le temps de maintenir son logiciel. On peut appeler cela le côté obscur du logiciel open source .

Examinons les logiciels que j'utilise pour ce site

Ce site web est construit avec les extensions Python 3, framework Flask, quelques Flask , SQLAlchemy, Bootstrap 4, jQuery, MariaDb. Python 3 survivra-t-il aux cinq prochaines années ? Je l'espère. Python 2 était une erreur car il manquait des fonctionnalités essentielles. Les responsables de Python ont décidé de rendre Python 3 non rétrocompatible avec Python 2. Pour cette raison, Python 2 devrait continuer à vivre comme une langue indépendante de Python 3, mais la communauté a décidé de ne plus la soutenir. Ce n'est pas bon, mais je peux comprendre cela. La raison principale est que la communauté ne gagne pas d'argent en soutenant Python , alors elle choisit Python 3. Python 2 est un très bon exemple de ce qui peut aller mal avec le logiciel open source .

Le logiciel Flask survivra-t-il aux cinq prochaines années ? Je l'espère, mais j'ai peur. Le créateur et principal développeur de Flask voudra peut-être consacrer son temps à d'autres projets au cours des prochaines années. D'autres personnes peuvent-elles prendre la relève ? Je ne suis pas convaincu. Les extensions de Flask sont une autre chose. Elles sont généralement développées par des individus. Flask a été introduit en 2010 et déjà un grand nombre d'extensions n'ont pas été mises à jour depuis des années, quel sera le sort des extensions que vous incluez aujourd'hui dans votre produit ?

Il en va de même pour SQLAlchemy, un beau logiciel, ORM tel qu'il devrait être. Mais que se passera-t-il lorsque le créateur décidera d'arrêter et de faire autre chose ? Bootstrap est open source et il semble qu'ils aient pour politique d'aller de l'avant en cassant les versions précédentes. Je suis maintenant à Bootstrap 4 mais supposons que vous soyez à Bootstrap 3 et que vous deviez migrer vers Bootstrap 4. Ce n'est pas une tâche facile. Bootstrap a déjà annoncé la version 5, qui fonctionnera sans jQuery. Je me réjouis de cette migration ... PAS.

jQuery est très utilisé, mais nous allons essayer de suivre les changements imposés par les grandes technologies. Je ne peux qu'espérer qu'ils en auront la capacité. Des projets comme jQuery-UI et jQuery-Mobile sont plus ou moins morts. Et puis il y a MariaDb. Je crois qu'ils sont là pour rester au moins cinq ans car ils fournissent un très bon produit. Je pense aussi que Oracle veut qu'ils existent car ils stimulent les développements Oracle MySQL . MariaDb vend aussi du soutien, gagne de l'argent, très important.

Devriez-vous utiliser le logiciel open source pour développer votre prochaine application ?

Les logiciels des organisations commerciales sont-ils meilleurs ? Dans de nombreux cas, la réponse est non. Mais vous bénéficiez d'un soutien et il est essentiel qu'ils restent à jour. Néanmoins, je pense que c'est un bon choix d'utiliser les composants open source pour créer de nouveaux logiciels. Mais seulement si vous étudiez d'abord de manière approfondie le problème de la durée de vie des composants. Et bien sûr, vous devez vérifier la licence avant toute autre chose.

Minimiser les dépendances risquées en écrivant vos propres composants

Il y a de nombreuses années, j'ai repris un projet qui avait été écrit en Perl. Lorsque PHP est arrivé, j'ai construit mon propre petit framework et l'ai converti en PHP. Comme je n'utilisais aucune bibliothèque, tout était sous mon contrôle. Heureusement, PHP semblait raisonnablement rétrocompatible, ce qui signifie que la migration vers les nouvelles versions n'a pas demandé beaucoup d'efforts. De nombreux PHP sont venus et repartis, mais mon logiciel PHP fonctionne toujours. Mais bien sûr, il n'a pu survivre que parce que j'étais là. Je vois souvent sur des sites web comme Stackoverflow des commentaires selon lesquels il ne faut pas réinventer la roue. Mais développer vos propres composants n'est souvent PAS réinventer la roue !

  • vous pouvez utiliser les connaissances acquises dans le cadre de projets similaires déjà existants
  • vous pouvez laisser de côté le gonflement
  • vous pouvez ajouter des fonctionnalités manquantes au lieu de combattre le code de quelqu'un d'autre
  • vous pouvez sauter du code difficile à comprendre des autres
  • vous pouvez mettre à jour vos composants vous-même au lieu d'attendre les autres
  • on apprend beaucoup en regardant le code des autres

J'ai lu sur Internet que certaines personnes pensent que c'est une sorte d'arrogance lorsque quelqu'un décide d'écrire son propre composant. Je ne suis pas du tout d'accord, il n'y a pas de noir et blanc et c'est à vous ou à votre équipe de décider quand construire votre propre composant. Il y a de nombreuses raisons de ne pas le faire, mais aussi de nombreuses raisons de le faire. Pesez-les soigneusement.

Deux composants que j'ai récemment construits : le sélecteur de date et la macro Jinja Bootstrap

Dans un projet précédent, j'ai utilisé le sélecteur de date jQuery . C'est bien mais ... après un certain temps, j'ai eu besoin d'une fonctionnalité comme le passage à un autre mois sans sélectionner de date. C'était le début de nombreux maux de tête pour contourner cette limitation et d'autres encore. Pour ce site web, j'ai également besoin d'un sélecteur de date, il doit être intégré à Flask et WTForms et il doit adhérer à Content Security Policy. Ce dernier problème peut être résolu en exportant les paramètres du sélecteur de date de Python sous la forme application/json.
La macro Jinja Bootstrap doit permettre de générer très facilement toutes sortes de formulaires, elle doit être flexible et prendre en charge un large éventail de champs, y compris mon propre sélecteur de date. Je déteste construire des formulaires "à la main", c'est-à-dire mettre tous les champs du formulaire séparément dans un modèle, alors qu'avec un peu d'effort supplémentaire dans la macro, cela peut être fait simplement en écrivant :

{{ bootstrap_form(demo_form, id='demo_form') }}

Parce que je considère que ces deux composants sont vitaux pour mes futurs efforts, j'ai décidé de les écrire moi-même.

Résumé

Lorsque vous construisez votre logiciel avec des composants open source , vous prenez souvent plus de risques que d'utiliser des composants commerciaux. N'écoutez pas les autres, prenez vos propres décisions et n'ayez pas peur d'écrire vos propres composants. Lorsque vous écrivez vos propres composants, la règle principale est de les garder lisibles afin que les autres puissent les comprendre. Un problème avec de nombreux composants open source est qu'ils sont optimisés. C'est bien beau, mais l'optimisation ne se traduit pas toujours par la lisibilité. Les ordinateurs et les téléphones d'aujourd'hui sont beaucoup plus puissants et les optimisations ne devraient être envisagées que si elles sont absolument nécessaires.

Liens / crédits

How to make money from open source software
https://www.cio.com/article/3178621/how-to-make-money-from-open-source-software.html

Open Source, SaaS and Monetization
https://lucumr.pocoo.org/2019/11/4/open-source-and-saas/

REINVENT THE WHEEL | meaning in the Cambridge English Dictionary
https://dictionary.cambridge.org/dictionary/english/reinvent-the-wheel

En savoir plus...

Flask

Laissez un commentaire

Commentez anonymement ou connectez-vous pour commenter.

Commentaires

Laissez une réponse

Répondez de manière anonyme ou connectez-vous pour répondre.