Developpez.com

Une très vaste base de connaissances en informatique avec
plus de 100 FAQ et 10 000 réponses à vos questions

Le hardware open-source enfin défini
Le marché totalise déjà 13 milliards de dollars de revenus et devrait se développer

Le , par Idelways, Expert éminent sénior
13 milliards de dollars, c'est le chiffre d'affaires des compagnies qui font du hardware open-source, mais aucun standard ne régissait jusqu'alors ce domaine émergeant.

C'est à présent chose faite.

L'absence de définitions formelle de cette industrie l'a pour l'instant laissé dans l'ombre. Mais ses acteurs et ses produits commencent à être nombreux (citons Chumby - un dispositif Wifi populaire, ou Adafruit, un kit d'assemblage pour réaliser divers périphériques comme un lecteur mp3).

Mardi dernier, un groupe de signataires a publié une définition formelle de ce qu'est le hardware open-source.

Les fondements de ce standard seront familiers aux habitués des licences du logiciel libre.

Ils concernent en vrac: la documentation, les logiciels nécessaires, les travaux dérivés, la libre redistribution et attribution, la non discrimination contre les personnes ou les groupes, les licences ne doivent pas être spécifiques à un produit donné, ni être restreinte à un type de logiciel ou matériel, la licence doit être technologiquement neutre.

Mais l'apparence altruiste de ce mouvement ne veut pas dire que les sociétés qui y adhèrent ne font pas des profits.

Comme précisé en début d'article, 13 sociétés réalisent chacune plus d'un milliard de dollars de revenus. Un chiffre appelé à croitre rapidement, surtout avec l'arrivée de ce nouveau standards.

Un standard qui donnera plus de crédibilité aux entreprises et plus d'assurance aux investisseurs en dépit du principequi autorise les autres à fabriquer et vendre ou à offrir gratuitement des produits à base de conceptions matérielle open-source.

Intel, AMD et les autres vont-ils devoir regarder de près ce mouvement pour ne pas le sous-sestimer ?

L'avenir le dira

Source : Les termes complets du nouveau standard (site officiel), les sites de Chymby et Adafruit

Lire aussi

« Dans 5 ans, logiciels et hardwares seront gratuits », prédit la Fondation Linux

Les rubriques (actu, forums, tutos) de Développez :

Hardware
Linux

Et vous ?

Que pensez-vous de l'avenir de cette industrie ?
Aura-elle le même succès que le logiciel libre ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Louis Griffont Louis Griffont - Inactif https://www.developpez.com
le 23/07/2010 à 16:41
Citation Envoyé par dams78  Voir le message
Sauf que à quel moment j'ai écris (moi ou un autre qui essaye de t'expliquer le monde de l'open source), que tout le monde avait les droits d'ECRITURE sur le serveur de sources (svn ou cvs)?

Dans ce post
Quel que soit le projet si tu partages le code c'est via un gestionnaire de sources (svn, cvs), donc tu as forcément des droits d'écriture sur ces dépôts. Mais avec l'open source, tu peux récupérer ce code, le corriger et le distribuer (toi même), ou bien soumettre ton patch / modification à l'éditeur pour qu'il l'intègre à la version "officielle".

Avatar de dams78 dams78 - Membre chevronné https://www.developpez.com
le 23/07/2010 à 16:48
Citation Envoyé par Louis Griffont  Voir le message
Dans ce post


C'est bien ce que je dis, ya pas marqué : commiter le code!

Alors récupérer du code : ça veut dire le copier sur ton pc...
Le corriger : ça veut dire le corriger toujours sur ton pc...
Le distribuer (toi même), très important le toi même : ça veut dire le distribuer toi même, là j'avoue que j'ai du mal à expliquer plus, je tente un exemple mais ça veut pas dire que cela se passe toujours comme ça : tu peux très bien mettre la version (ta version) sur ton PROPRE serveur...
Avatar de Louis Griffont Louis Griffont - Inactif https://www.developpez.com
le 23/07/2010 à 17:03
Citation Envoyé par dams78  Voir le message
C'est bien ce que je dis, ya pas marqué : commiter le code!

Alors récupérer du code : ça veut dire le copier sur ton pc...
Le corriger : ça veut dire le corriger toujours sur ton pc...
Le distribuer (toi même), très important le toi même : ça veut dire le distribuer toi même, là j'avoue que j'ai du mal à expliquer plus, je tente un exemple mais ça veut pas dire que cela se passe toujours comme ça : tu peux très bien mettre la version (ta version) sur ton PROPRE serveur...

Dans ce cas, effectivement, ça n'a rien à voir. C'est complètement différent.
Mais, ce n'était pas clair, et avec un post quasi similaire de l'expérimenter ruronialex ça devenait confus.
Avatar de koala01 koala01 - Expert éminent sénior https://www.developpez.com
le 23/07/2010 à 22:18
Je proposerai à tout le monde de respirer un bon coup et de se calmer, car, si je dois encore user de mon droit de modération (et tout semble parti pour), cela va m'énerver moi, et je risque de demander à l'équipe modération de sévir.

Sans blague, je m'absente une petite journée et les phrases assassines refont leur apparition alors que j'ai valablement prévenu les gens concerné lors de ma première tentative de calmer le jeu (les personnes concernées se reconnaitront).

Ceci dit, Louis, il faut comprendre comment cela fonctionne en pratique, même si dams semble avoir quelque mal à l'exprimer clairement.

Reprenons tout depuis le début.

1- un bug est transmis via le "bugtracker" du projet par la personne qui en a fait l'amère expérience.

2- Tout le monde (toi y compris) a un acces en lecture sur le système de gestion de version concurrentes (SVN, CVS, Mercurial ou autre) et peut donc récupérer le code source originel.

3- N'importe qui peut modifier le code qu'il a récupéré, pour résoudre le problème transmis en [1], pour résoudre un problème qu'il aurait lui-même remarqué ou, pourquoi pas, pour ajouter une fonctionnalité qui n'a pas (encore) été acceptée par le projet.

4- Toute personne ayant modifié le code peut proposer la version modifiée au téléchargement sous réserve de le faire sous la même licence, de fournir le code modifié, et d'indiquer le site du projet originel.

5- Toute personne ayant modifié le code peut proposer un patch à l'équipe du projet

6- un patch proposé par un membre extérieur à l'équipe de développement sera validé et contrôlé avant d'être appliqué à la version de production (et passera sans doute par un trunk, après une première analyse)

7- l'équipe de développement seule a accès en écriture sur le système de gestion de version concurrente.

8- Un membre de l'équipe de développement peut proposer ses modifications du code directement sur le système de gestion de versions concurrentes, MAIS cela se fait sur un "trunk" et non sur la version "de production", de manière à permettre une vérification en profondeur de la viabilité de la modification.

9- En tout état de cause, un retour en arrière est toujours possible grâce au système de version concurrente si, d'aventure, une modification venait à occasionner plus de problèmes qu'elle n'en résout.

Tu constates, Louis, que le processus de validation et la gestion des modifications se fait exactement de la même manière que dans n'importe quelle équipe travaillant sur un code fermé au niveau de l'équipe en charge du projet.

La seule différence tenant, encore une fois, au fait qu'un grand nombre de gens ne faisant pas partie de l'équipe de développement "officielle" peuvent proposer des solutions auxquelles l'équipe "officielle" n'aurait peut être pas pensé (ou auxquelles elle aurait pu penser après un délais plus ou moins long).

Il y a de fortes chances que le développeur qui prétend ne jamais faire d'erreur soit un menteur (ou qu'on ne lui ait jamais fait remarqué ses erreurs s'il en est réellement convaincu), car l'erreur est humaine.

Mais on dit aussi qu'il y a toujours plus dans deux têtes que dans une.

Et c'est là la grande force des projets open-source: plutôt que de se limiter à une dizaine ou une quinzaine de têtes, le projet est susceptible d'obtenir des idées de... n'importe quel tête appartenant à l'un des six milliards d'être humains vivant actuellement.

Même en retirant ceux qui n'entravent que dalle au développement et les petits zigotos qui ont à peine lu un tutorial mal fait mais qui se croient pourtant devenus un crack, cela fait encore beaucoup plus de monde que n'importe quelle société, aussi grande et puissante soit-elle, sera susceptible de regrouper autour de n'importe quel projet
Avatar de Louis Griffont Louis Griffont - Inactif https://www.developpez.com
le 26/07/2010 à 9:11
Bonjour koala01,

Je constate que le fonctionnement que tu décris est bien celui que j'estimais être, d'un projet Open-Source, ce qui me rassure.

Et me fait maintenir, qu'il n'y a donc aucune raison qu'une correction soit plus rapidement corrigé (et j'entends par corriger le principe suivant : mise en évidence, étude, correction logiciel, tests, et déploiement), que dans le monde fermé.

Le fait qu'un plus grand nombre de développeurs (ou tout du moins un nombre indéterminé et supposé considérable - je pense qu'il est difficile d'estimer réellement le chiffre) ayant accès au code source puisse permettre une mise en évidence des problèmes plus rapide, la suite peut par contre être plus lente, ou tout du moins pas plus rapide. Je m'explique, car je sens déjà venir la controverse. Mettons un bug dans un logiciel libre. Admettons que 100 développeurs se penchent dessus et trouvent une correction. Les 100 développeurs remontent leur correction à l'équipe du projet. Cette équipe à donc 100 corrections à vérifier, à étudier, et un patch à créer et tester.

Vous avez le droit de penser que c'est plus rapide, mais je n'en suis pas sûr. Ce qui peut être plus rapide, c'est la mise à disposition des mises à jour (la distribution d'une version corrigée) une fois toutes les étapes de corrections réalisées, car les éditeurs ont des politiques bien établies pour ces mises à jour.
Avatar de dams78 dams78 - Membre chevronné https://www.developpez.com
le 26/07/2010 à 11:15
Citation Envoyé par Louis Griffont  Voir le message
Bonjour koala01,

Je constate que le fonctionnement que tu décris est bien celui que j'estimais être, d'un projet Open-Source, ce qui me rassure.

Et me fait maintenir, qu'il n'y a donc aucune raison qu'une correction soit plus rapidement corriger (et j'entends par corriger le principe suivant : mise en évidence, étude, correction logiciel, tests, et déploiement), que dans le monde fermé.

Le fait qu'un plus grand nombre de développeurs (ou tout du moins un nombre indéterminé et supposé considérable - je pense qu'il est difficile d'estimer réellement le chiffre) ayant accès au code source puisse permettre une mise en évidence des problèmes plus rapide, la suite peut par contre être plus lente, ou tout du moins pas plus rapide. Je m'explique, car je sens déjà venir la controverse. Mettons un bug dans un logiciel libre. Admettons que 100 développeurs se penchent dessus et trouvent une correction. Les 100 développeurs remontent leur correction à l'équipe du projet. Cette équipe à donc 100 corrections à vérifier, à étudier, et un patch à créer et tester.

Vous avez le droit de penser que c'est plus rapide, mais je n'en suis pas sûr. Ce qui peut être plus rapide, c'est la mise à disposition des mises à jour (la distribution d'une version corrigée) une fois toutes les étapes de corrections réalisées, car les éditeurs ont des politiques bien établies pour ces mises à jour.

Et pourquoi dans ton exemple tu ne prendrai pas qu'une version corrigée au lieu de te taper les 100, si une seule fonctionne? D'ailleurs au fil du temps, l'équipe de développement sait très bien quel développeur fait du bon boulot, elle peut donc regarder sa solution en premier, et si elle fonctionne l'adopter.
Avatar de Louis Griffont Louis Griffont - Inactif https://www.developpez.com
le 26/07/2010 à 11:19
Citation Envoyé par dams78  Voir le message
Et pourquoi dans ton exemple tu ne prendrai pas qu'une version corrigée au lieu de te taper les 100, si une seule fonctionne? D'ailleurs au fil du temps, l'équipe de développement sait très bien quel développeur fait du bon boulot, elle peut donc regarder sa solution en premier, et si elle fonctionne l'adopter.

Je dirais : par déontologie, par honnêteté vis à vis des 99 autres qui ont bossé, et aussi qu'on ne peut savoir quelle est la meilleure, si l'on en a testé qu'une.
Maintenant, tu as également raison. La première qui arrive et qui fonctionne est retenue et les autres négligées.
Avatar de bioinfornatics bioinfornatics - Membre confirmé https://www.developpez.com
le 26/07/2010 à 12:08
bah en générale on évitait que 100 gard font le même boulout c'est pour ça qu'avec un bug tracker on peut assigner le bug a une personne. Cette personne discute également pour se renseigner sur le bug et les possibilités pour corriger le souci.
Avatar de koala01 koala01 - Expert éminent sénior https://www.developpez.com
le 26/07/2010 à 22:51
De plus, il ne faut pas oublier la puissance d'un outil qui est régulièrement sous employé dans les projets fermés: la COM-MU-NI-CA-TION.

Avant que tu ne me jettes des pierres, je précise que ce n'est pas le cas partout, mais il arrive régulièrement que les gens agissent littéralement comme des handicapés dans ce domaine, et que seules quelques personnes soient au courent de l'ensemble des tenants et des aboutissants.

Dans les projets open-source, les systèmes de gestion de versions concurrentes, les timeline, les "features requests", les todo lists et les bugtrackers représentent une part importante des outils utilisés.

Mais les outils les plus importants sont sans doute les chats, fora, canaux IRC et autre liste de diffusion.

S'il est vrai que certaines décisions sont prises en "petit comité" (comprend: au niveau de l'équipe de développement "officielle"), il y a systématiquement un système de discussion sur lequel les intervenants "ponctuels" peuvent exposer leurs problèmes, poser leurs questions ou se tenir au courant de l'évolution des travaux.

Même sans intervenir lui-même sur l'un de ces canaux de diffusion publique, n'importe qui peut se faire une idée précise de ce que les autres font ou de ce sur quoi ils planchent.

Il peut donc assez facilement déterminer si "cela vaut la peine" qu'il s'intéresse à un problème donné ou si, au contraire, "les autres" sont à son avis sur la bonne voie.

Le mieux, c'est qu'à la limite, s'il a l'impression qu'ils "partent dans une mauvaise direction", il peut parfaitement essayer de défendre son point de vue.

Ce genre de communication est souvent rare dans les projets fermés (bien que certains aient, effectivement, élevé la com au rang de religion ), mais est quasi systématique dans les projets open source.

Et c'est quelque part là que réside la force de ces derniers.

PS: quand je parle de communication, je ne parle pas de la comm à saveur de marketting, mais bel et bien de la comm qui permet de faire surgir les idées par la saine émulation qui peut apparaitre dans un groupe dans lequel chaque voix est entendue
Avatar de Louis Griffont Louis Griffont - Inactif https://www.developpez.com
le 27/07/2010 à 8:40
koala01, tu es en train de me dire que les projets Open-source sont biens ?

Mais, en doutais-je un seul instant ?

Je ne doute absolument pas que les projets Open-Source sont structurés, suivis et parfaitement maîtrisés par une équipe motivée et compétente. Et que le fonctionnement du développement, et du suivi soit très proche au final, de celui des éditeurs de logiciels propriétaires.

Et donc, j'en reviens toujours au même. En quoi, un tel fonctionnement permet des mise à dispositions de corrections plus rapide que dans le monde des éditeurs ? Le nombre de développeurs pouvant apporter leur contribution est plus important, mais au final, le temps est incompressible.
Avatar de bioinfornatics bioinfornatics - Membre confirmé https://www.developpez.com
le 27/07/2010 à 23:48
pour savoir ce qu'est l'open source une vidéo, disponible a partir de ce lien:
- http://dl.free.fr/getfile.pl?file=/oAJgSQPf
Offres d'emploi IT
Ingénieur développement fpga (traitement vidéo) H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Architecte électronique de puissance expérimenté H/F
Safran - Ile de France - Villaroche - Réau
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil