Discussion :

[Sodium]

• Les serveurs tournent sur Debian ? Il faut donc des administrateurs qui savent gérés du Débian, et ça se payent. Et comme dans tout l'informatique, ils n'arrivent généralement pas avec un savoir absolu sur la question, ils doivent donc chercher sur des éléments pointus qu'ils ne maîtrise pas encore, et ça aussi ça coûte. Si on veut opposer ça à une solution propriétaire auquel tu sous traite la réalisation, on pourrait dire que cela semble plus difficile de prévoir combien ça va te coûter (sauf si ce que tu fais n’atteins pas la limite de ce que c'est déjà faire son personnel).
• Tu utilises un produit 100% libre et gratuit sans support commercial -> tu es encore plus dépendant de ta capacités à maintenir le savoir acquis sur la technos car sinon tu risques de te retrouver le bec dans l'eau si un problème arrive plus tard.

Je ne comprends pas l'argument, je dirais même plutôt que ça n'en est pas un. Quelle que soit la technologie, même avec du développement from scratch il faut des gens compétents pour l'utiliser. Ben oui, pour développer un programme, il faut, surprise des développeurs. Et si une boîte développe sa propre solution, elle doit former ses employés à l'utiliser, prendre bien garde à ne pas perdre les personnes qui la maîtrisent le mieux car il y a peu de chance qu'il y ait une documentation à jour et complète contrairement à un framework open source. Et bien entendu, les clients de la boîte deviennent dépendants de celle-ci car trouver un concurrent prêt à se former dessus (et à quel prix) est à peu près mission impossible.

Si on part dans ce sens-là, ben oui effectivement rien n'est gratuit sur terre à part éventuellement l'oxygène (et encore). Le pétrole à la base c'est gratuit, on paye les gens et le matériel pour l'extraire.

Les certifs et autres je serais curieuse de savoir quel pourcentage de développeurs ça représente, personnellement je travaille sous Symfony et je me contente très bien de la doc et éventuellement de Stack Overflow. Mais c'est sûr, les certifs c'est bien pour le CV de l'employé comme pour l'entreprise afin de valoriser ses tarifs.

[esperanto]

Les serveurs tournent sur Debian ? Il faut donc des administrateurs qui savent gérés du Débian, et ça se payent.

Parce que pour un serveur Windows ce n'est pas le cas peut-être? On sait tous que toute forme de support est payante, que le logiciel de base soit libre ou pas.
Tu pars peut-être du principe qu'un admin Debian est plus dur à trouver donc plus cher. S'ils sont plus rares c'est peut-être que (tout le monde part du principe que) la demande est moins grande, donc pour le prix c'est discutable.
En revanche ce qui est certain, c'est qu'avec un logiciel propriétaire, seul l'éditeur lui-même peut te proposer un support de niveau maximal (c'est à dire celui allant jusqu'à la personnalisation la plus poussée) parce que personne d'autre ne peut lire les sources pour gérer les cas les plus extrêmes. Alors qu'un logiciel open source, je prends ici volontairement le terme plus général, il est possible d'apprendre, c'est loin d'être évident on est d'accord, mais ça reste possible.

Tu utilises un produit 100% libre et gratuit sans support commercial -> tu es encore plus dépendant de ta capacités à maintenir le savoir acquis sur la technos car sinon tu risques de te retrouver le bec dans l'eau si un problème arrive plus tard.

Tu crois vraiment que tout le monde achète le support commercial avec la licence Windows? Non et c'est là le vrai intérêt du libre: oui le support a un coût mais on ne le paie que si on en a besoin (ou simplement parce que ça vous rassure, mais c'est une raison comme une autre d'avoir un besoin)

[Sodium]

Les admins serveur Windows seraient plus courants et moins cher que les admins serveur Linux ? J'ai de sérieux doute.

[JPLAROCHE]

Bonjour,
quand on veut étudier par exemple Postgres c'est du solide et accessible, bien sur la partie payante fait beaucoup plus , mais avec de l'huile de coude on parvient à ses fins.
Pareille pour les langages .... Les licences propriétaires ne permette pas de faire de réel essai ils ont tellement limités que c'est bien souvent inutile d'essayé...
Gratis est pour moi important j'aide des personnes et s'il me fallait payer ???? Ou faire payer ??? (je suis maintenant à la retraite), maintenant open-source me permet de rentrer dans le code et parfois c'est vraiment important pour comprendre et prendre des décisions.
Je n'oublie pas de participer et je fais des Dons avec mes moyens, d'une part pour soutenir et d'autre part parce que je trouve le boulot bien fait.
Je me rappelle qu'au travail j'avais utilisé un logiciel ouvert et libre, j'ai participé au debug... Et fournit du code pour améliorer... et passer du temps ...

Pour moi la recherche passe par le libre/ouvert c'est l'un des moyens d'avancer.

Mais si pensez que libre est: faire votre boulot à votre place passer votre chemin...

@bientôt

[Aurelien.Regat-Barrel]

Accessoirement la version Enterprise de SqlServer est dans la même gamme de prix ($14,256) que ce qui a été annoncé pour les versions avancées de Postgres. Pour Oracle, moi j'ai plutôt entendu parler de contrats à 6 chiffres, on reste donc nettement mois cher, sans parler que ça tourne sur un Linux/Intel basique (là où par le passé il fallait aussi payer très cher du matos spécifique). Postgres/MySQL ont démocratisé l'accès aux bdd, sans ces projets l'ecosystème serait beaucoup moins riche aujourd'hui. Y'a juste pas de "one size fits all" : il en faut pour tout le monde.

J'ai l'impression d'assister au débat inverse de "les solutions propriétaires sont forcément moins bonnes que les open source". Je persiste à penser que dans l'ensemble les gens ne sont pas si con que ça : si une solution (gratuite ou payante) leur convient plutôt qu'une autre, c'est que ça leur va.

[4sStylZ]

Un petit retour d’XP sans trop de jugement de valeur :*

Dans ma boite on a travaillé avec un moteur orienté Colonne assez méconnu :*ColumnStore (Anciennement InfinyDB). On a choisi celui-ci après un benchmark de diverses solutions. La contrainte était de trouver un moteur gratuit à long terme, performant et dont on saurait maintenir les implémentations en autonomie par la suite.

Il s’avère que c’est MariaDB la boite derrière ça. Le moteur est open source, gratuit dans l’usage et MariaDB se fait de l’oseille dessus par diverses sources :*Si tu est un client qui paie une grosse license / du service, tu est privilégié et tes issues sont traitées plus rapidement. Si tu veut, tu peut aussi appeler des experts pour auditer ton usage de l’outil, t’aider à le maintenir et débugguer si besoin.

Le constat en usage gratuit et un support payant à petite échelle :

• Cette base est un produit de niche (peut-être est-ce la cause de tous les autres problèmes) et n’évolue pas.
• Certaines fonctions basiques implémentées ne sont pas fonctionnelles et offrent des résultats inconsistant (et là je parle de SUM() etc, pas de truc touchy).
• Les experts ne connaissent pas l’outil car ils ne développent pas directement dessus. -> Au setup on a payé des experts pour un audit de l’infra qu’on voulait déployer et la conf qu’ils ont validée était totallement voué à l’échec.
• Il y a des bugs majeurs et des instabilités importantes qui ne sont pas traitées. -> Chez nous ça tombe en rade tout seul sans raison et les experts qu’on a payé n’ont pas apporté de solutions.

Leur modèle économique entier semble privilégier le service (qui rapporte de l’argent) et pas le développement de l’outil (qui n’en rapporte pas… à court terme).

Edit : Lol juste à ma droite sur DVP.com j’ai une pub MariaDB

[redcurve]

Toutes ces boites vont fermer boutique plus personne ne veut payer pour le travail des autres, puisque tout doit être gratuit. Elles sont en plein effet streisand

[darklinux]

Toutes ces boites vont fermer boutique plus personne ne veut payer pour le travail des autres, puisque tout doit être gratuit. Elles sont en plein effet streisand

Non , tout n 'est pas gratuit , mais tu peux faire payer une prestation , encore une fois le free software est pour les techniciens , pas pour le marketing , Linux , EMACS , ne sont pas marqué"té et fonctionne très bien

[esperanto]

Un petit retour d’XP sans trop de jugement de valeur :*

Témoignage intéressant mais qui mérite quelques éclaircissements.
Après quelques recherches, je comprends qu'autrefois une société InfinityDB a créé un moteur de bases de données noSQL, et l'a mis en GPL avant de faire faillite. Ensuite Monty Program AB, la société qui édite MariaDB (puisqu'on parle ici de la société, alors que MariaDB c'est le produit), en a fait un fork repris à son compte.

Tu sembles attribuer tous tes problèmes au modèle libre+support, mais je ferais remarquer que:

• Si elle n'avait pas été libérée, cette base n'existerait plus du tout;
• Si je reprends tes points:
  

  -> Cette base est un produit de niche (peut-être est-ce la cause de tous les autres problèmes) et n’évolue pas.

  Si elle n'existait pas tu utiliserais quoi? Connais-tu un équivalent de ce moteur, répondant à tes critères, et étant développé suivant un modèle commercial classique? Il faut comparer ce qui est comparable: c'est quoi l'équivalent "grosse société type Oracle" de InfinityDB?
  Cherche pas, tu ne trouveras pas. Aujourd'hui les décideurs de grands comptes (grosses entreprises ou institutions) partent du principe qu'il faut toujours considérer que le plus gros produit est toujours le meilleur. Résultat pour eux: Oracle peut pratiquer des prix ou des conditions de licence absolument hallucinants sans qu'il soit possible de dire quoi que ce soit. Résultat pour nous autres développeurs: après avoir tué toute tentative de modèle alternatif (bases orientées objet, bases XML, et maintenant ce qu'on appelle NoSQL) on doit se coltiner au quotidien des ORM qui ne sont là que pour prouver que le modèle SQL, même s'il est très bon dans certaines situations, n'est juste pas adapté à d'autres.
  

  --> Les experts ne connaissent pas l’outil car ils ne développent pas directement dessus. -> Au setup on a payé des experts pour un audit de l’infra qu’on voulait déployer et la conf qu’ils ont validée était totallement voué à l’échec.

  Le coeur de métier de Monty Program AB ça reste quand même MariaDB. Ils ont pu reprendre InfinityDB mais visiblement ils n'ont pas non plus fait de miracles.

L'idéal aurait été que Monty Program AB reprenne aussi les employés d'InfinityDB, mais c'était peut-être déjà trop tard. Maintenant, la reprise par un éditeur plus classique n'aurait peut-être pas été mieux: je serais très intéressé d'avoir un retour similaire concernant SleepyCat, un moteur de bases de données XML libre, un tant maintenu par une société, et repris depuis par... Oracle. Je doute qu'Oracle fournisse beaucoup d'experts sur un produit qui a pu autrefois être vu comme un concurrent.

Edit : Lol juste à ma droite sur DVP.com j’ai une pub MariaDB

Ah oui en effet moi je l'avais au dessus

[tanaka59]

Bonjour,

Quel est votre avis sur le sujet ?

C'est simple on est dans un monde ou l'on veut du " tout gratuit " ... Forcement le tout gratuit à ces limites ... MySQL et MariaDB sont d'être les pointures. Alors c'est bien quand on veut débuter ou archiver mais certainement pas pour de la prod.

PostgreSQL c'est du marché de niche ... avec beaucoup de paramétrage ... Quand on est biberonné à MySQL on est vite déboussolé.

Ne parlons pas de "base" de openoffice/libreofffice qui est une catastrophe sans nom ...

Sur le marché du payant > les licences Microsoft sont hors de prix ... mais bon il y a une communauté bien développé sur ces produits. Pourquoi vouloir changer ce qui fonctionne.

Ne parlons pas de Oracle à plusieurs millier d'euros par mois.

L’open source empêche-t-il les entreprises d’avoir une croissance normale ?

Oui cela s'adresse avant tout à un publique ciblé , marché de niche. Qui plus est qui a déjà avoir des notions ... donc on réduit encore la voilure sur le panel.

Selon vous, quelles seraient les types de prestations qui ne doivent pas être rémunérées pour que la communauté open source puissent prospérer ?

Quand on veut une garantie support , SAV, licence, brique spécial ... la il y a plus le choix de passer à la caisse.

Comment peut-on rentabiliser les logiciels open source selon vous ?

C'est très compliqué , on le voit bien avec Mozilla :/

[Sodium]

C'est simple on est dans un monde ou l'on veut du " tout gratuit " ... Forcement le tout gratuit à ces limites ... MySQL et MariaDB sont d'être les pointures. Alors c'est bien quand on veut débuter ou archiver mais certainement pas pour de la prod.

Encore une fois, avant d'essayer de faire passer vos idées, essayez d'être raccord avec les FAITS. Après Sqlite, Mysql / Mariadb est le sgbd le plus utilisé sur les applications en prod. Si tu me sors "moi je pense pas que la terre est ronde", on s'en fout, la terre est ronde point, ton opinion sur des éléments factuels n'a absolument aucune espèce d'intérêt.

[champomy62]

Je pense que le rapport client-fournisseur se fait differement:

- le client embauche un DBA - il fait le support - developpement - conseil
- le client fait appel un fournisseur postgres. Les entreprises ne paient pas directement pour le logiciel en lui même mais pour:

• la formation
• le support 24h/7j
• les nouvelles fonctionalitees
• realisation de projet, conseils etc

C'est vrai que par default postgres manque de fonctionnalitees par rapport aux ténors mais pour 80% des entreprises, il suffit amplement (peut gérer plusieurs TB).

Je pense que le modele postgres a prouvé que c'est possible d'allier open-source et rentabilité. il suffit de voir les nombreuses compagnies qui gravitent autour de cet ecosysteme.

[Sodium]

Quand tu as juste besoin d'une appli web qui stocke des données (ce qui encore une fois représente probablement 70% des projets), la formation Postgres c'est un apt-get, pg_dump et pg_restore. Je suis passée de MariaDb à Postgres est à part implémenter une fonction qui permet de comparer des strings sans la prise en compte des majuscules et accents, je ne peux pas vraiment dire que ça se soit fait dans la douleur.

[esperanto]

à part implémenter une fonction qui permet de comparer des strings sans la prise en compte des majuscules et accents,

Tu as essayé le type citext? Ou simplement la comparaison lower(a) = lower(b) ?

[Sodium]

Je ne sais pas si ça fonctionne pour les accents, de toute façon s'il faut rajouter un champ juste pour ça humpf.
J'utilise unaccent (https://www.postgresql.org/docs/9.1/unaccent.html) avec une fonction doctrine permettant de la placer facilement dans un select. Il y a peut-être une conversion de la casse dans ma fonction je ne me souviens plus, ça fait un moment.

[SQLpro]

Tu as essayé le type citext? Ou simplement la comparaison lower(a) = lower(b) ?

Pour information, je suis en train d'écrire un long article sur le portage de MS SQL Server vers PostgreSQL avec de nombreux tests de performances…. Sur une table de 10 millions de lignes voici mes conclusions :

• Test mettant en évidence les contre-performances de PostGreSQL pour des recherches insensibles à la casse : SQL Server est 1 718 fois plus rapide que PostGreSQL sur cette recherche insensible à la casse...
• Test mettant en évidence les contre-performances de PostGreSQL pour des recherches insensibles aux accents et autres caractères diacritiques : SQL Server est 300 000 fois plus rapide que PostGreSQL sur cette recherche insensible aux accents…

Et il y a bien d'autres cas de ce genre….

[Sodium]

Ou alors tu ne sais tout simplement pas utiliser Postgres correctement et ces différences de performances viennent de tests non pertinents ainsi que d'un environnement non maîtrisé
Retourne donc plutôt jouer avec ton Framework PHP qui est assez édifiant quant à ton amateurisme en développement

[rawsrc]

Retourne donc plutôt jouer avec ton Framework PHP qui est assez édifiant quant à ton amateurisme en développement

à force de dire n'importe quoi, tu arrives même à confondre les personnes (CinePhil, SQLpro). Faudrait penser à aller consulter.

[Sodium]

Ah oui pardon, en effet, mon cerveau a fait le mix entre les deux personnes les plus imbues de leur personne sur ce forum

[champomy62]

Pour information, je suis en train d'écrire un long article sur le portage de MS SQL Server vers PostgreSQL avec de nombreux tests de performances…. Sur une table de 10 millions de lignes voici mes conclusions :

• Test mettant en évidence les contre-performances de PostGreSQL pour des recherches insensibles à la casse : SQL Server est 1 718 fois plus rapide que PostGreSQL sur cette recherche insensible à la casse...
• Test mettant en évidence les contre-performances de PostGreSQL pour des recherches insensibles aux accents et autres caractères diacritiques : SQL Server est 300 000 fois plus rapide que PostGreSQL sur cette recherche insensible aux accents…

Et il y a bien d'autres cas de ce genre….

Impatient de lire cet article!