Discussion :

[Michael Guilloux]

NativePHP veut permettre aux développeurs de créer des applications desktop natives multiplateformes avec PHP et les techs du Web
une réincarnation du framework Electron pour les développeurs PHP ?

NativePHP est un nouveau framework, qui selon ses auteurs, permet de créer rapidement des applications de bureau natives riches en utilisant PHP. Il offre des classes faciles à utiliser pour interagir avec les fonctionnalités du système d'exploitation, des outils pour construire et empaqueter des applications natives, ainsi qu'un runtime PHP statique pour une exécution sans effort sur les systèmes des utilisateurs. Contrairement à d'autres frameworks, NativePHP n'impose pas de méthodes strictes pour la construction des applications et prend en charge différents outils d'interface utilisateur tels que React, Vue, Livewire, etc. Il comprend également des fonctionnalités de gestion de fenêtres, de menus, de fichiers, de base de données, et bien plus encore. Selon ses auteurs, les possibilités de développement avec NativePHP sont vastes et limitées uniquement par l'imagination des développeurs.

Actuellement en phase alpha, NativePHP est un nouveau framework qui fait étrangement penser à Electron, le framework de GitHub permettant de développer des applications de bureau multiplateformes (macOS, Windows, Linux) avec des technologies web (JavaScript, HTML et CSS). La différence majeure semble être l'utilisation de PHP.

NativePHP est un nouveau framework pour construire rapidement des applications de bureau riches et natives en utilisant PHP. Si vous êtes déjà développeur PHP, vous vous sentirez tout de suite chez vous. Si vous êtes nouveau dans le monde de PHP, nous pensons que vous trouverez NativePHP facile à apprendre et à utiliser. Quel que soit votre parcours, nous pensons que vous serez rapidement productif.

NativePHP connaît un succès fulgurant à travers le monde en permettant aux développeurs PHP de créer de véritables applications natives multiplateformes en utilisant les outils et les technologies qu'ils connaissent déjà : HTML, CSS, JavaScript et bien sûr, PHP.

Sur le site du projet, NativePHP est présenté comme une combinaison des éléments suivants :

• Une collection de classes faciles à utiliser - des abstractions - qui vous permettent d'interagir avec diverses fonctionnalités du système d'exploitation hôte.
• Un ensemble d'outils pour permettre la création et l'empaquetage de votre application native en utilisant l'environnement Web d'Electron ou Tauri.
• Un runtime PHP statique qui permet à votre application de s'exécuter sur n'importe quel système d'utilisateur sans aucun effort de leur part.

NativePHP vient également avec un ensemble de fonctionnalités utiles, notamment la gestion des fenêtres, la gestion des menus, la gestion des fichiers, une prise en charge de base de données (SQLite) et des notifications natives.

Pour les auteurs du projet, vous pouvez construire presque tout avec NativePHP dans les limites de votre imagination.

Que puis-je construire avec NativePHP ?

Honnêtement, tout ce que vous voulez. Nous pensons que NativePHP va permettre à des milliers de développeurs de construire toutes sortes d'applications. La seule limite est votre imagination.

Vous pourriez construire une application de barre de menus qui vous permet de gérer vos cron jobs, ou une nouvelle application de lancement, ou un enregistreur d'écran qui met des chapeaux de cowboy sur chaque emoji de smiley qu'il voit.

Pour l'instant, le projet ne prend en charge qu'un pilote Laravel, mais l'équipe dit déjà travailler sur sa compatibilité avec n'importe quel framework que vous utilisez. Et même si vous n'utilisez pas de framework du tout, NativePHP devrait prendre en charge vos cas d'utilisations.

Avant que vous ne vous posiez la question, les auteurs du projet précisent également que NativePHP n'est ni une nouvelle version personnalisée de PHP, ni un framework GUI.

NativePHP n'est pas un framework GUI. Nous ne voulons pas vous dire comment construire votre application. Vous pouvez choisir l'ensemble d'outils d'interface utilisateur qui vous rend le plus productif, ainsi que votre équipe.

Vous construisez une interface front-end React ? Pas de problème. Vue ? Bien sûr. Livewire ou Inertia ? Peu importe ! Du simple HTML et CSS ? C'est bon aussi. Tailwind ? Bootstrap ? Material UI ? Comme vous voulez.

NativePHP n'est pas une nouvelle version personnalisée de PHP. C'est le bon vieux PHP que vous connaissez et aimez.

PHP et les technologies Web sont-ils adaptés pour développer de bonnes applications de bureau ?

Comme avec Electron, NativePHP veut permettre aux développeurs de créer des applications desktop natives multiplateformes avec les technologies Web. Mais cette approche est-elle adaptée pour le développement d'applications de bureau performantes et vraiment natives ?

Rappelons ici les critiques relatives au développement d'applications de bureau avec Electron.

« Si vous ne connaissez pas Electron, il s'agit essentiellement d'un navigateur Web (Chromium) qui héberge seulement votre application Web... comme s'il s'agissait d'une application de bureau », disait Renato Athaydes, un développeur logiciel travaillant dans une entreprise technologique privée. « Si les gens préfèrent livrer un navigateur Web complet avec leurs applications afin qu'ils puissent utiliser d'excellents outils tels que JavaScript pour les développer, il y a vraiment quelque chose qui ne va pas. »

Ainsi, indépendamment de la question de savoir si la pile de technologies Web est bonne pour les applications de bureau, l'un des points qui dérangent le plus à propos d'Electron est qu'il va empaqueter un runtime Web complet dans chaque application, même si un runtime convenable existe déjà sur le système d'exploitation. Chromium comprend plus de 20 millions de lignes de code et il semble que chaque application Electron va empaqueter une copie de cette énorme base de code sous forme de binaire. Ce qui aura pour conséquence de grossir la taille de votre application et créer un gaspillage de mémoire.

Le framework NativePHP utilisant l'environnement Electron pour la création et l'empaquetage d'applications, il pourrait hériter aussi de ces inconvénients. Mais si cela n'a pas empêché Electron d'être populaire aujourd'hui, le framework NativePHP peut-il aussi avoir du succès avec les fonctionnalités annoncées ?

Source : NativePHP

Et vous ?

Avec les fonctionnalités annoncées, pensez-vous NativePHP est un framework prometteur ?
PHP et les technologies Web sont-ils adaptés pour développer de bonnes applications de bureau vraiment natives ?

Voir aussi

Un rapport révèle que la plupart des déploiements de PHP utilisent des versions qui ne sont plus prises en charge, 61,9 % des répondants utilisent encore des versions de PHP en fin de vie

PHP 8.2 est disponible et s'accompagne des propriétés "en lecture seule" aux classes ainsi que la possibilité de déprécier les propriétés dynamiques

Faut-il utiliser Electron pour le développement d'applications de bureau ? Quels sont ses avantages et inconvénients ?

[clavier12AZQSWX]

je me demande ce que cet outils aura de "mieux" qu'un basic xamp/wamp/lamp installé où l'on est pas limité à un framework...

[grunk]

je me demande ce que cet outils aura de "mieux" qu'un basic xamp/wamp/lamp installé où l'on est pas limité à un framework...

Une solution xamp ou wamp quand tu l'installe sur un poste d'utilisateur , tu as toujours la possibilité d'un service qui démarre pas, d'un petit rigolo qui te modifie un fichier, etc ...
Avec ce genre d'application tu n'as plus ces problématique et tu fais croire que c'est une vraie application puisque tu n'as pas de navigateur à lancer.
C'est limité à Laravel pour le moment mais clairement ils veulent s'ouvrir.

Il existe des tas de solution similaires (php gtk , php-qt, wxphp) et elles ont globalement toute en commun de n'intéresser pas grand monde car forcément à un moment on se heurte a des limitation techniques.

On va dire que c'est pratique quand tu as une appli web que tu veux transformer en desktop à moindre coût pour une raison X, mais la tendance est quand même plutôt à l'inverse.

Le seul vrai intérêt c'est la rapidité/facilité de création des UI en html/css qu'aucune solution native n'a jamais réussi à égaler à mon gout.

[clavier12AZQSWX]

On va dire que c'est pratique quand tu as une appli web que tu veux transformer en desktop à moindre coût pour une raison X, mais la tendance est quand même plutôt à l'inverse.

le jour où j'ai voulu "founir" une appli lamp à un tiers, j'ai fait une VM minimaliste avec une gui qui lançait le browser au démarrage. ça restait "keep it simple" pour la maintenance (modification,deploiement,configuration, formation).

àprès 20ans de php, je me méfie bcp des "nouvelles " solutions de framework php : le framework n'a pas 15ans d'age, il ne vaut plus le coup de s'investir (je pense surtout au temps humain de formation et de passage-transisation de relai pour la re-formation par un collègue).

[Madmac]

je me demande ce que cet outils aura de "mieux" qu'un basic xamp/wamp/lamp installé où l'on est pas limité à un framework...

Ruby avec Sinatra. Ruby vient avec un serveur intégré. Ce qui fait que l'on n'a pas à installer un serveur. Vous lancer l'appli en Sinatra. Et le serveur se lancera automatiquement.

Et J'oubliais OpenSuse a un GUI utilisant Ruby pour des applications de ce genre.


Sauter directement à 2 minutes

Et pour ceux qui ne sont pas au courant. Il est possible de produire de véritable exécutable avec mRuby. https://mruby.org/docs/articles/exec...ith-mruby.html

ou fait des applis en webassembly: https://semaphoreci.com/blog/ruby-webassembly

[Invité]

Maintenir le code PHP legacy/spaghetti d'une app web n'est-il pas suffisamment dissuasif? Non, il faut en rajouter une couche avec des applications desktop "natives"... quelle horreur. Sérieusement, j'espère que ce château de sable n'ira pas plus loin qu'une version alpha.

[grunk]

Maintenir le code PHP legacy/spaghetti d'une app web

Ca fait 15 ans que t'as pas fait de web non ?

[Eric30]

Ca fait 15 ans que t'as pas fait de web non ?

Non. Ça fait surtout 15 ans qu'il n'a pas du faire de PHP.
Ou alors il est resté sur la version PHP5 d'il y a 15 ans.
Ou encore il ne bosse qu'avec des applications développées en PHP il y a 15 ans.

Je trolle, mais c'est un classique quand on parle de PHP.
Tu as toujours quelqu'un qui parce qu'il en a fait un peu il y a 15 ans ou qui bosse sur un projet vieux de 15 ans ou fait par un ado de 15 ans (je trolle encore) qui a du coup une mauvaise expérience et considère ce langage comme pourri.
Débat sans fin.

[Invité]

Non. Ça fait surtout 15 ans qu'il n'a pas du faire de PHP.
Ou alors il est resté sur la version PHP5 d'il y a 15 ans.
Ou encore il ne bosse qu'avec des applications développées en PHP il y a 15 ans.

Je trolle, mais c'est un classique quand on parle de PHP.
Tu as toujours quelqu'un qui parce qu'il en a fait un peu il y a 15 ans ou qui bosse sur un projet vieux de 15 ans ou fait par un ado de 15 ans (je trolle encore) qui a du coup une mauvaise expérience et considère ce langage comme pourri.
Débat sans fin.

Je pense que tu devrais te confronter à la réalité du terrain, à des applications complexes, à la haute disponibilité, en tant que développeur et chef de projet... Coder des sites web et CMS en PHP dans son coin, même un gamin de 12 ans peut le faire.

Par ailleurs, je ne considère pas le langage comme étant pourri, c'est plutôt la manière dont il est utilisé et sa granularité qui posent problème.

Et plutôt que de faire des commentaires creux, tu devrais fournir quelques arguments en faveur de PHP puisque tu aimes ce langage. Je sens que ça va être très drôle...

C'est sûr qu'en cassant du sucre sur le truc, il va prendre de l'ampleur.

PHP n'est pas forcément le langage le plus adapté pour faire des applis Desktop, il n'a pas été conçu pour ça à la base mais il peut le faire. Exemple php-gtk qui lui n'est pas en Alpha.

Après ça reste de l'interprété (sans tenir compte de la compilation à la volée en bytecode).

D'un autre coté, si un projet est codé avec les pieds, ce n'est pas le langage qui est en cause. Utiliser un langage inadapté ne va pas aider non plus. Pour moi php n'est pas forcément le langage le plus adapté pour faire une appli Desktop, mais ça ne veut pas dire que c'est inadapté.

Je ne casse pas du sucre, j'ai simplement mis côte-à-côte les envolées lyriques et la réalité des faits. Il s'agit d'une produit en version alpha, il devrait être présenté comme tel. En plus, ils parlent d'un framework mais pour l'instant c'est surtout un wrapper dépendant de Lavarel... les grandes ambitions aiment l'humilité.

En outre, je serais curieux de connaître le nombre de projets ayant utilisé avec succès PHP-GTK au cours des 15 dernières années...

En conclusion, PHP n'a jamais été conçu pour faire du desktop. Ce n'était pas l'ambition de son créateur, et ce n'est pas l'ambition de ses mainteneurs. Il existes de nombreux autres langages éprouvés et adaptés au desktop. Pour moi, NativePHP est surtout l'initiative de 2 développeurs qui par ego démesuré ou non souhaitent enjoliver leur CV avec un projet "ambitieux". Ce projet n'a visiblement aucune chance d'aboutir, si ce n'est au-près d'une petite niche de développeurs.

[pokap]

Je n'ai pas trouvé l'information sur le site sur la machine virtuelle php. J'imagine qu'elle est embarqué avec l'app ? comme c'est le cas pour le navigateur web.
Mais du coup y a un serveur http interne ou il y a process CGI spécifique ?

En tout cas c'est un projet intéressant et assez dense aussi, il y avait déjà eu il y a très longtemps une tentative de php dekstop mais c'était pas foufou.

Vivement que ça supporte autre chose que Laravel parce que personnellement je n'aime pas ce framework.

[NukaCola]

Maintenir le code PHP legacy/spaghetti d'une app web n'est-il pas suffisamment dissuasif? Non, il faut en rajouter une couche avec des applications desktop "natives"... quelle horreur. Sérieusement, j'espère que ce château de sable n'ira pas plus loin qu'une version alpha.

J'en ai surtout marre de devoir maintenir des "applications" PHP obsolètes de 5, 10 ou 15 ans parce que des pseudo-autodidactes et autre ingénieurs ratés ont écrit et entassé du code pourri pendant des années, en mélangeant des paradigmes, des conventions, des versions et extensions PHP qui ne sont plus maintenues, des extensions PEAR douteuses, des bibliothèques récupérées sur composer et maintenue par 1 seul gars qui voulait faire parler lui.

Je pense que tu devrais te confronter à la réalité du terrain, à des applications complexes, à la haute disponibilité, en tant que développeur et chef de projet... Coder des sites web et CMS en PHP dans son coin, même un gamin de 12 ans peut le faire.

Pour moi, NativePHP est surtout l'initiative de 2 développeurs qui par ego démesuré ou non souhaitent enjoliver leur CV avec un projet "ambitieux". Ce projet n'a visiblement aucune chance d'aboutir, si ce n'est au-près d'une petite niche de développeurs.

Oui tu as raison, c'est bien mieux de ne jamais rien proposer, de ne jamais rien essayer, de ne jamais innover, et de venir chier sur le langage, les développeurs ratés qui l'utilisent, les gens qui te répondent, une alpha d'un projet, et les développeurs derrière à "l'égo démesuré".

[Invité]

Ca fait 15 ans que t'as pas fait de web non ?

J'en ai surtout marre de devoir maintenir des "applications" PHP obsolètes de 5, 10 ou 15 ans parce que des pseudo-autodidactes et autre ingénieurs ratés ont écrit et entassé du code pourri pendant des années, en mélangeant des paradigmes, des conventions, des versions et extensions PHP qui ne sont plus maintenues, des extensions PEAR douteuses, des bibliothèques récupérées sur composer et maintenue par 1 seul gars qui voulait faire parler lui, bonjour la gestion des dépendances... sans oublier le "hacking" des frameworks et ORM parce qu'ils ne comprennent pas les design pattern ou guidelines élémentaires qui les régissent...ou sont juste trop paisseaux pour les mettre en oeuvre.

Sérieusement, pour implémenter un online shop qui se connecte à une base de données et consomme une API pour les paiements, PHP c'est très bien. Pour faire quelque chose d'un peu plus accueillant qu'un script bash en administration système, ça passe aussi. Mais pour tout le reste, c'est choisir d'investir à fonds perdus et l'assurance d'une dette technique dans les 18 mois suivant le passage en production...

[Christophe]

Il est indiqué sur le site officiel que ce truc est en version alpha et ne doit pas être utilisé en production.

De là au "succès fulgurant à travers le monde permettant aux développeur PHP de créer de véritable applications natives multiplateformes", il n'y a qu'un pas

C'est sûr qu'en cassant du sucre sur le truc, il va prendre de l'ampleur.

PHP n'est pas forcément le langage le plus adapté pour faire des applis Desktop, il n'a pas été conçu pour ça à la base mais il peut le faire. Exemple php-gtk qui lui n'est pas en Alpha.

Après ça reste de l'interprété (sans tenir compte de la compilation à la volée en bytecode).

D'un autre coté, si un projet est codé avec les pieds, ce n'est pas le langage qui est en cause. Utiliser un langage inadapté ne va pas aider non plus. Pour moi php n'est pas forcément le langage le plus adapté pour faire une appli Desktop, mais ça ne veut pas dire que c'est inadapté.

[Eric30]

J'en ai surtout marre de devoir maintenir des "applications" PHP obsolètes de 5, 10 ou 15 ans parce que des pseudo-autodidactes et autre ingénieurs ratés ont écrit et entassé du code pourri pendant des années, en mélangeant des paradigmes, des conventions, des versions et extensions PHP qui ne sont plus maintenues, des extensions PEAR douteuses, des bibliothèques récupérées sur composer et maintenue par 1 seul gars qui voulait faire parler lui, bonjour la gestion des dépendances... sans oublier le "hacking" des frameworks et ORM parce qu'ils ne comprennent pas les design pattern ou guidelines élémentaires qui les régissent...ou sont juste trop paisseaux pour les mettre en oeuvre.

Sérieusement, pour implémenter un online shop qui se connecte à une base de données et consomme une API pour les paiements, PHP c'est très bien. Pour faire quelque chose d'un peu plus accueillant qu'un script bash en administration système, ça passe aussi. Mais pour tout le reste, c'est choisir d'investir à fonds perdus et l'assurance d'une dette technique dans les 18 mois suivant le passage en production...

Merci. Ta réponse est exactement du même acabit que celles que l'on lit d'habitude : tout ce que tu évoques n'est pas lié à PHP mais aux personnes et aux projets. Étonnant que tu ne sois pas capable de t'en rendre compte.

Pareil. La dette technique et les mauvais choix, ce n'est pas PHP.

Les projets mal gérés, la dette technique, les "autodidactes", les paresseux, le turnover... tu trouves ça en Python, en Java, en ce que tu veux...

Je connais des sites et apps écrits en PHP qui tournent sur des versions régulièrement mises à jour et bien suivies depuis 10 ans.
À l'inverse, lors d'une de mes expériences en ESN, j'ai eu à intervenir des projets écrits en Java dont je savais qu'ils étaient déjà pourris avant même leur MEP car les compétences n'étaient pas là.
Autre exemple : en ce moment je bosse parfois avec une équipe qui bosse sur un projet écrit en C++.
Le projet a 4 ans : code spaghetti et dette technique sont déjà bien présents.

[Invité]

Merci. Ta réponse est exactement du même acabit que celles que l'on lit d'habitude : tout ce que tu évoques n'est pas lié à PHP mais aux personnes et aux projets. Étonnant que tu ne sois pas capable de t'en rendre compte.

Pareil. La dette technique et les mauvais choix, ce n'est pas PHP.

Les projets mal gérés, la dette technique, les "autodidactes", les paresseux, le turnover... tu trouves ça en Python, en Java, en ce que tu veux...

C'est bien les développeurs que j'ai fondamentalement mis en cause, dans tous les cas. En particulier ceux qui aggravent le problème avec des wrappers de drivers Lavarel sensés produire des applications desktop à base d'Electron et NPM. Répondent-ils à un besoin réel ? Permets-moi d'en douter.

Et merci de ne pas déformer mes propos, ou à défaut, commence par les mettre en citation pour fonder ton point de vue, c'est la moindre des choses.

Je connais des sites et apps écrits en PHP qui tournent sur des versions régulièrement mises à jour et bien suivies depuis 10 ans.

Oui pour coder des sites web c'est très bien, je l'ai mentionné. Mais pas pour des applications complexes et distribuées, avec des clients riches et d'autres exigences de haut niveau. Quant à la question de savoir si une app est "bien gérée et suivie depuis 10 ans", il faut un peu plus que l'impression générale d'un développeur. Cela se discute en premier lui au niveau du management.

Un exemple typique consiste à analyser le nombre d'heures dédiées à la maintenance corrective, les retards dans la planification, le turnover moyen des développeurs dans l'équipe ou organisation sur 6 à 18 mois, le taux d’absentéisme, le nombre de tickets de supports techniques résolus, le feedback des utilisateurs. Et de manière générale les surcoûts. Ensuite on peut objectivement affirmer qu'une application "est bien gérée" ou "a été bien gérée". La pensée magique, ça marche seulement avec les enfants (et les adultes idiots).

À l'inverse, lors d'une de mes expériences en ESN, j'ai eu à intervenir des projets écrits en Java dont je savais qu'ils étaient déjà pourris avant même leur MEP car les compétences n'étaient pas là.
Autre exemple : en ce moment je bosse parfois avec une équipe qui bosse sur un projet écrit en C++.
Le projet a 4 ans : code spaghetti et dette technique sont déjà bien présents.

Je n'ai pas dit que le code spaghetti était une exclusivité de PHP, mais il est indiscutable que PHP favorise les mauvaises pratiques à grande échelle.

[Invité]

NativePHP connaît un succès fulgurant à travers le monde en permettant aux développeurs PHP de créer de véritables applications natives multiplateformes en utilisant les outils et les technologies qu'ils connaissent déjà : HTML, CSS, JavaScript et bien sûr, PHP.

Il est indiqué sur le site officiel que ce truc est en version alpha et ne doit pas être utilisé en production.

De là au "succès fulgurant à travers le monde permettant aux développeur PHP de créer de véritable applications natives multiplateformes", il n'y a qu'un pas ...

[Karadoc]

Ça n'est que la résurrection d'une idée qui était déjà là quasi depuis le début de PHP avec les extensions PHP/Tk qui permettaient de faire des applications bureau

[Invité]

Ça n'est que la résurrection d'une idée qui était déjà là quasi depuis le début de PHP avec les extensions PHP/Tk qui permettaient de faire des applications bureau

Je suppose que tu parles de PHP-GTK. Et oui, c'est en quelque sorte une tentative de résurrection d'une idée générale - celle d'utiliser PHP pour implémenter des applications desktop - avec le succès qu'on lui connaît...

[Christophe]

LibreOffice est un succès, surtout parce que OpenOffice n'existe plus depuis 10 ans et qu'il n'existe aucun concurrent libre.

N'importe quoi, OpenOffice existe toujours, même si effectivement LibreOffice lui a couté des parts de marché (si on peut utiliser ce terme pour un produit libre). Par ailleurs, il existe des concurrents au moins en ligne libre sérieux (pour les concurrents hors ligne, je pense qu'il y en a des sérieux mais ne les connais pas spécifiquement), et des concurrents payant, libre/payant n'étant pas le sujet ici. Et "surtout parce ce que" n'empêche pas que le produit soit un succès.

NextCloud est un succès du au fait que des employés mutins ont conduit OwnCloud Inc à déposer le bilan et au délitement de la communauté.

Owncloud n'a pas déposé le bilan, est toujours présent. Les "employés mutins" ou contributeurs on tout à fait le droit de créer un fork d'un produit libre, c'est souvent la base d'un fork, des divergences d'opinion entre contributeurs.

Ubuntu n'est pas un fork de Debian. C'est une distribution qui à l'origine était basée sur son architecture, ce qui est techniquement différent.

à l'origine basé sur : c'est la définition même d'un fork, je veux bien que tu m'explique techniquement la différence.

Microsoft SQL Server est un succès relatif, compte tenu du fait que Microsoft tend à imposer ses solutions par monopole technologique, ils ne jouent pas très fair-play.

J'aimerais bien avoir un succès relatif comme SQL Server.
le SQL est un standard, tu n'es pas obligé d'utiliser SQL Server pour faire du SQL. Autant la politique de Microsoft est critiquable, mais sur l'aspect SQL Server c'est aller un peu loin. Mais je pense que j'aurais sortie n'importe quel fork ayant pignon sur rue, tu aurais eu quelque chose à redire.

[Invité]

N'importe quoi, OpenOffice existe toujours, même si effectivement LibreOffice lui a couté des parts de marché (si on peut utiliser ce terme pour un produit libre). Par ailleurs, il existe des concurrents au moins en ligne libre sérieux (pour les concurrents hors ligne, je pense qu'il y en a des sérieux mais ne les connais pas spécifiquement), et des concurrents payant, libre/payant n'étant pas le sujet ici. Et "surtout parce ce que" n'empêche pas que le produit soit un succès.

à l'origine basé sur : c'est la définition même d'un fork, je veux bien que tu m'explique techniquement la différence.

LibreOffice est un fork de OpenOffice.org, qui n'existe plus depuis 2011. Il existe Apache OpenOffice, mais ce n'est pas OpenOffice.org. Ce sont deux produits distincts. Mais je te le concède, je me suis mal exprimé.

Et oui on peut parler de "part de marché" dans le libre. Il s'agit d'un modèle économique, d'un modèle d'affaires, d'un modèle juridique et d'une méthodologie de travail. Ce n'est pas juste un terme désignant une communauté de brillants humanistes barbus travaillant gratuitement pour un monde meilleur.

à l'origine basé sur : c'est la définition même d'un fork, je veux bien que tu m'explique techniquement la différence.

Non la définition du terme est la suivante:

Un fork (terme anglais signifiant « fourche », « bifurcation », « embranchement »1) désigne dans le jargon informatique, un nouveau logiciel créé à partir du code source d'un logiciel existant (Wikipedia).

Ubuntu a exploité l'architecture (en gros le système d'exploitation GNU, le noyau Linux et le gestionnaire de paquets APT avec des dépôts distincts) de la distribution Debian, en aucun cas son "code source" ou tout autre élément constitutif du projet Debian. Fais tes devoirs, RTFM, consulte Wikipedia, interroge ChatGPT. Il n'est fait aucune mention de Ubuntu en tant que fork de Debian, et pour cause.

J'aimerais bien avoir un succès relatif comme SQL Server.
le SQL est un standard, tu n'es pas obligé d'utiliser SQL Server pour faire du SQL. Autant la politique de Microsoft est critiquable, mais sur l'aspect SQL Server c'est aller un peu loin. Mais je pense que j'aurais sortie n'importe quel fork ayant pignon sur rue, tu aurais eu quelque chose à redire.

Tu as raison sur un point: personne n'est obligé d'utiliser SQL Server pour faire du SQL. À présent, je t'invite à aller exposer ton point de vue dans les entreprises où l'écosystème logiciel et l'expertise sont essentiellement centrés sur des produits Microsoft.

C'est toujours plus facile d'imposer un produit en terre conquise. Même si ce produit ne présente aucun intérêt ou valeur ajoutée.