Tu n'as pas expliqué le lien de cause à effet.
Si l' "artisan" (l'un l'est, pas l'autre? Quelle différence?) n'a pas su convaincre celui qui possède les 81M$ que sa base était meilleure pour commencer à investir que de partir de 0, peut-être que c'est juste que c'était pas bien fait (en imaginant que l'artisan n'a pas caché volontairement dans son coin sa travail pour se plaindre ensuite de ne pas avoir été vu)?
En effet j'ai pas creusé. Ici le cas est un peu symptomatique, car ils ont pu avoir 81M$ car ils avaient déjà eu une réussite avant, ce n'était pas inné et magique avec leur plan mongodb (même s'il était forcément bon et équilibré, car tu ne donnes pas 81M$ dans le vide).
Ce que je voulais mettre en avant c'était le fait que de toute manière les dés vont être pipés dès le début, et qu'en terme de moyens il y a juste un problème d'échelle. Il faudrait avoir le produit parfait sur une niche ultra visible/hype à une équipe reteinte -aka mes artisans mais on va revenir sur le terme qui t’irrite on dirait :) -
L'un n’empêche pas l'autre, du moment où des gens sont intéressés. Si l'un meurt, c'est juste qu'il n'y avait pas de gens intéressés et qu'il y avait mieux ailleurs. En quoi est-ce mal?
Est-ce mal? Non. Je dirai dommage pour l'équipe resteinte, mais c'est la règle du jeu, et de toute manière la masse aura un produit fini avec le gros éditeur. Donc non, ce n'est pas un mal. (je laisse de côté la partie "politique" sur le fait que dans ce cas le capital va gagner à tous les coup, c'est pas le point ici, je veux juste me placer d'un point de vue end user qui a ce qu'il souhaite).
Ce qui est 100% normal, tout le monde n'étant pas masochiste.
A te lire, je sens que tu y vois un mal, est-ce faux? Si non, pourquoi?
Je me suis mal fait comprendre alors: non ce n'est pas un mal. Comme tu dis on est pas des masochistes, et si je peux avoir facilement et d manière agréable ce que je souhaites, je vois pas pourquoi je prendrais une autre solution rude et pas claire. (là encore je laisse de côté la politique et donc le fait que c'est libre blablabla, là on parle de end user, les licences ils s'en fichent jusqu'au jour où leurs données sont affichées dans la nature).
N'importe quoi : un artisan, il sait aussi faire du joli et ergonomique. C'est une choix personnel de la personne.
Le terme n'était pas bon, meaculpa je le reprends. En plus tu donnes une bonne définition juste en dessous:
c'est plutôt la différence entre les gens voulant faire que ce qui leur plait (mais qu'on les paye pour ça) et ceux sachant trouver un équilibre entre la technique et la demande des utilisateurs.
Exact.
Là où je ne suis pas totalement d'accord c'est qu'en fait la technique ne dois pas entrer en ligne de compte et que seul les demandes utilisateurs doivent compter au final. La technique ne doit être prise en compte que pour répondre sur la faisabilité et le temps que ça va demander (donc au final le prix).
Et c'est peut être bien là le point névralgique du truc: la plupart des projets qui réussissent ne sont pas technique (ou alors uniquement à la marge) et que ça va impliquer une barrière d'entrée très forte.
Docker? une superbe intégration de principes qui existaient depuis des années (containers + repository externes), aidée par la hype autour de go.
Mongodb? de simples objets json requétables, avec du distribués qui utilise du sharding sur clé. Rien de bien révolutionnaire dans les BDD, mais ultra facile à utiliser, superbement documenté et avec dès le début une myriades de lib pour les langages importants.
Qui tente de mettre un mysql en cluster? juste les fous. Par contre le faire avec un mongodb ça va, car ça parait plus facile (alors que bon au final les soucis de l'uns l'autres les aura).
Ils sont très bons. Et ce qu'ils vendent ce n'est pas de la technique, mais une très bonne connaissance de leur (potentiels) clients et leur attentes/points qui font mal.
Le modèle fonctionne, les utilisateurs finaux ont quelque chose qui leur parle et qui est simple à utiliser. Par contre ça demande un investissement marketing/édition (doc & ergonomie & outils divers, donc beaucoup de $ au final car il faut bien payer ses employés).
De base mon avis est que "recruter gratuitement" des contributeurs c'est faisable si tu es sur un domaine de recherche et/ou hautement technique. Par contre une fois la phase de recherche/exploration finie, là c'est mission impossible (il n'y a qu'à voir combien de designer il y a dans le monde open source par rapport aux dev).
Je suis d'accord avec toi, certaines petites équipes peuvent faire ultra ergonomique (il n'y a qu'à voir les jeux indépendants), mais reconnait que ce n'est pas la norme quand on parle d'outil Open Source fait par des petites équipes par hobby (car là c'est le défi technique qui prime).
Ma conclusion personnelle est donc de base le modèle collaboratif sera plus naturel sur les nouveaux domaines.
Par contre une fois le domaine dépoussiéré, là le modèle collaboratif s’effondre (ou a minima diminue de plusieurs ordres de grandeurs) faute de personnes pour le faire vivre. Ici les éditeurs prennent le lead car ils peuvent offrir une contrepartie aux contributeurs autre que la gloire: un salaire :D
A titre personnel je passe encore mes soirées à diminuer le nombre de malloc de mon code et d'aligner au mieux mes structures, car c'est un défi qui m'amuse. Mais je dois bien le reconnaître: aucun client ne me paiera pour ça, donc cette activité restera un hobby.
Tout le monde pourrait vivre tranquillement avec cette équation, mais le fait que les éditeurs investissent de plus en plus tôt la sphère de recherche/dev (merci l'argent des investisseurs) fait que les équipes réduites sont repoussées encore et encore vers des niches toujours plus petites.
Ce n'est pas très "juste" pour elles (les équipes réduites), mais j'ai dit qu'on laissait le côté "politique" de côté, et d'un point de vue end-user les éditeurs leur apportant ce qu'elles veulent (et gratuitement pour les premières versions en prime, le temps de comprendre le marché et faire connaitre leur marque), les équipes réduites n'ont plus d'intérêt. (Aller rapidement pour le côté politique car certains vont se sentir floué: leur place n'est-elle pas dans la recherche publique alors?).
[^] # Re: Provisioning
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Une nouvelle version de Cloonix est disponible, la v-37-00.. Évalué à 4.
En effet j'ai pas creusé. Ici le cas est un peu symptomatique, car ils ont pu avoir 81M$ car ils avaient déjà eu une réussite avant, ce n'était pas inné et magique avec leur plan mongodb (même s'il était forcément bon et équilibré, car tu ne donnes pas 81M$ dans le vide).
Ce que je voulais mettre en avant c'était le fait que de toute manière les dés vont être pipés dès le début, et qu'en terme de moyens il y a juste un problème d'échelle. Il faudrait avoir le produit parfait sur une niche ultra visible/hype à une équipe reteinte -aka mes artisans mais on va revenir sur le terme qui t’irrite on dirait :) -
Est-ce mal? Non. Je dirai dommage pour l'équipe resteinte, mais c'est la règle du jeu, et de toute manière la masse aura un produit fini avec le gros éditeur. Donc non, ce n'est pas un mal. (je laisse de côté la partie "politique" sur le fait que dans ce cas le capital va gagner à tous les coup, c'est pas le point ici, je veux juste me placer d'un point de vue end user qui a ce qu'il souhaite).
Je me suis mal fait comprendre alors: non ce n'est pas un mal. Comme tu dis on est pas des masochistes, et si je peux avoir facilement et d manière agréable ce que je souhaites, je vois pas pourquoi je prendrais une autre solution rude et pas claire. (là encore je laisse de côté la politique et donc le fait que c'est libre blablabla, là on parle de end user, les licences ils s'en fichent jusqu'au jour où leurs données sont affichées dans la nature).
Le terme n'était pas bon, meaculpa je le reprends. En plus tu donnes une bonne définition juste en dessous:
Exact.
Là où je ne suis pas totalement d'accord c'est qu'en fait la technique ne dois pas entrer en ligne de compte et que seul les demandes utilisateurs doivent compter au final. La technique ne doit être prise en compte que pour répondre sur la faisabilité et le temps que ça va demander (donc au final le prix).
Et c'est peut être bien là le point névralgique du truc: la plupart des projets qui réussissent ne sont pas technique (ou alors uniquement à la marge) et que ça va impliquer une barrière d'entrée très forte.
Docker? une superbe intégration de principes qui existaient depuis des années (containers + repository externes), aidée par la hype autour de go.
Mongodb? de simples objets json requétables, avec du distribués qui utilise du sharding sur clé. Rien de bien révolutionnaire dans les BDD, mais ultra facile à utiliser, superbement documenté et avec dès le début une myriades de lib pour les langages importants.
Qui tente de mettre un mysql en cluster? juste les fous. Par contre le faire avec un mongodb ça va, car ça parait plus facile (alors que bon au final les soucis de l'uns l'autres les aura).
Ils sont très bons. Et ce qu'ils vendent ce n'est pas de la technique, mais une très bonne connaissance de leur (potentiels) clients et leur attentes/points qui font mal.
Le modèle fonctionne, les utilisateurs finaux ont quelque chose qui leur parle et qui est simple à utiliser. Par contre ça demande un investissement marketing/édition (doc & ergonomie & outils divers, donc beaucoup de $ au final car il faut bien payer ses employés).
De base mon avis est que "recruter gratuitement" des contributeurs c'est faisable si tu es sur un domaine de recherche et/ou hautement technique. Par contre une fois la phase de recherche/exploration finie, là c'est mission impossible (il n'y a qu'à voir combien de designer il y a dans le monde open source par rapport aux dev).
Je suis d'accord avec toi, certaines petites équipes peuvent faire ultra ergonomique (il n'y a qu'à voir les jeux indépendants), mais reconnait que ce n'est pas la norme quand on parle d'outil Open Source fait par des petites équipes par hobby (car là c'est le défi technique qui prime).
Ma conclusion personnelle est donc de base le modèle collaboratif sera plus naturel sur les nouveaux domaines.
Par contre une fois le domaine dépoussiéré, là le modèle collaboratif s’effondre (ou a minima diminue de plusieurs ordres de grandeurs) faute de personnes pour le faire vivre. Ici les éditeurs prennent le lead car ils peuvent offrir une contrepartie aux contributeurs autre que la gloire: un salaire :D
A titre personnel je passe encore mes soirées à diminuer le nombre de malloc de mon code et d'aligner au mieux mes structures, car c'est un défi qui m'amuse. Mais je dois bien le reconnaître: aucun client ne me paiera pour ça, donc cette activité restera un hobby.
Tout le monde pourrait vivre tranquillement avec cette équation, mais le fait que les éditeurs investissent de plus en plus tôt la sphère de recherche/dev (merci l'argent des investisseurs) fait que les équipes réduites sont repoussées encore et encore vers des niches toujours plus petites.
Ce n'est pas très "juste" pour elles (les équipes réduites), mais j'ai dit qu'on laissait le côté "politique" de côté, et d'un point de vue end-user les éditeurs leur apportant ce qu'elles veulent (et gratuitement pour les premières versions en prime, le temps de comprendre le marché et faire connaitre leur marque), les équipes réduites n'ont plus d'intérêt. (Aller rapidement pour le côté politique car certains vont se sentir floué: leur place n'est-elle pas dans la recherche publique alors?).