Dans le cas de l'OSS...

Envoyé par
totozor
- je t'imposes un audit pour me couvrir du risque que ton code représente
Tu ne peux rien imposer à l'auteur d'un code. Tu peux négocier, embaucher, acheter... mais sans un contrat qui donne des contreparties, l'utilisateur n'a pas d'influence forte sur l'auteur.
je te demande le certificat au moment où j'utilise ton code
Si un projet OSS a déjà été certifié (et que le commanditaire de la cetification le permet), alors ça ne pose pas de problème pour le projet de le partager. Au contraire, cette certification devient un label de qualité, l'avoir est un avantage concurrenciel. Donc les projets cetifiés seront finalement assez contents de l'exhiber pour gagner en crédibilité.
- je prends la responsabilité de l'analyse et de la garantie de la certification de ton code (ça coute et je ne vais probablement jamais accepter d'assumer ça)-
Certains n'auront pas le choix. Des projets sont tellement ancrés qu'ils sont quasi irremplaçables et qu'il faudra bien qu'un ou plusieurs consommateurs s'organisent pour le certifier quand le CRA sera la.
- je n'utilise plus ton code et je vais payer un autre pour le service et le certificat
Ce n'est pas forcément toujours plus rentable que de payer un audit.
Mais concrètement, ça consolide aussi des business-model OSS: le projet est OSS communautaire, non certifié et un éditeur contributeur peut décider de prendre une version et de la certifier et de la vendre avec la certif. C'est déjà le business-model de Red Hat (mon employeur) par exemple, qui vend par exemple Red Hat Enterprise Linux (RHEL) qui est un rebuild d'une ancienne version testée, stabilisée, documentée... de Fedora (qui est communautaire) et les gens paye Red Hat pour ce bonus de qualité. De la même manière, Red Hat payera surement la certification pour RHEL ou des parties de Fedora pour avoir la possibilité de continuer à vendre RHEL; et les gens qui doivent utiliser un OS certifié viendront donc préférer encore plus RHEL -et payer Red Hat- que de prendre d'autres distros qui ne sont pas certifiées.
Mais aussi, tu oublies des possibilités:
- Le consommateur paye l'audit/la certif de la brique OSS dont il a besoin et la contribue au projet => Le projet développe un avantage compétiftif et gagne alors en pérennité ce qui peut rendre le coût de l'audit rentable à moyen terme
- Plusieurs consommateurs s'accordent à partager les frais de la certif pour en bénéficier tous, de la même manière qu'on partage déjà le développement, les coûts d'infra... Les fondations ou consortiums open-source peuvent être les bons acteurs pour centraliser ça. => Le coût de la certif est partagé car le code est partagé, l'OSS a alors un avantage car elle permet ça plus facilement que du code fermé ou du dev interme.
D'un point de vue capitaliste je ne gagne rien à payer pour la certification d'un produit récupérer.
Si tu n'as pas le choix et qu'il ne te faut que du certifié, tu te poseras la question de comment être le plus rentable possible. Payer un audit sur un code externe que tu ne maintiens pas sera probablement moins cher que de payer un même audit sur un code sur un code que tu maintiens en interne; et restera potentiellement moins cher que de payer des licences... Ca dépendra des cas, mais je pense qu'en général l'approche OSS sera en fait encore plus rentable car les coûts d'audit peuvent aussi être partagés.
Si je veux rendre ça "rentable" je t'achètes pour gagner le bénéfice de mon investissement.
Tu ne peux pas acheter du code OSS, il est déjà existant et peut continuer tout seul. Aussi, revenons à l'objectif: ton objectif n'est pas de collectionner les certifications pour les revendre, d'ailleurs en l'état ce n'est pas clair si la certif est attachée à une brique logicielle, à un ensemble, si elle est la propriété de son acheteur (ce qui serait dommage) ou un bien commun que n'importe qui peut réutiliser si il utilise ce même logiciel... Selon ces détails, ça peut changer beaucoup de choses sur le modèle de "rentabilité"; mais quoi qu'il en soit, par rapport à l'état actuel, ce sera jamais rentable: on parle de forcer des coûts supplémentaires au développement, pas de générer plus de business. C'est fondamentalement à perte financièrement. Mais augmenter les coûts de production peut avoir des effets intéressant même sur la rentabilité: ça incite à produire moins, à produire mieux, plus durable.
Donc à la fin, on pousse (passivement) l'Open Source à disparaitre par impuissance face au système certificatif.
Je ne suis toujours pas convaincu que l'OSS soit plus impuissant que le propriétaire par rapport au système certificatif. Pour rappel, le dev OSS représente des millions de développeurs (~12% de l'ensemble de l'activite IT en France), est en croissance plus rapide que la moyenne du secteur; c'est pas 3 geeks dans un garage qui sont démunis, c'est 12% de tous les investissement logiciels du moment, avec un perspective à 15% d'ici 5 ans (
https://cnll.fr/media/2019_CNLL-Synt...urce-Study.pdf ), c'est un pan entier des l'industrie, qui pourra payer des certifs aussi bien voire mieux que pas mal de "petites" boites de logiciels propriétaires.
0 |
0 |