gelnior a écrit 142 commentaires

Merci :) Oui, sait on jamais !

C'est un sujet complexe. Pour tenter de simplifier, soit tu développes une bibliothèque sur un sujet commun à pas mal de monde et là tu peux compter sur les moteurs d'indexation pour faire connaître ton projet et initier une communauté. Soit tu fais un logiciel un peu en rupture avec ce qui se fait déjà. Dans ce cas, il faudra prévoir de le présenter dans un maximum de conférences pour trouver tes premiers utilisateurs.

Je me suis rarement arrêté avant de publier quelque chose. Après si tu entends par là lesquelles n'ont pas suscité d'intérêt. Je dirais une bonne dizaine. Quand c'est un sujet qui ne me motive pas beaucoup et que ça ne prend pas, je m'arrête vite.

A sympa ces liens ! Je viens d'ouvrir un forum pour des discussions ouvertes sur le sujet : https://forum.personal-server.org

PS : c'est noté pour le bépo / azerty

Bien vu pour le noyau Linux. C'est un autre modèle qui marche bien.

Mon projet ne s'oppose pas à Yunohost. L'idée est de réunir une communauté de gens ayant un serveur perso avec Yunohost dessus ou non. Je développe d'autres tools liées à ces thématiques mais qui ne font pas de déploiement faciles (contrairement à Yunohost). Je te laisse regarder.

Oui la réponse est super intéressante.

Donc en gros Pour un projet qui veut toucher beaucoup de monde il y a plusieurs paliers :

• Communautaire seulement : bien adapté aux petites libs, moins aux logiciels complet.
• Communautaire + donation : ex : Krita, Peertube. A un moment ça demande du travail à temps plein
• Entreprise : ex Gitlab, Nextcloud, Feu Ansible. La boite doit son succès au logiciel et donc le porte activement.
• Fondation + backer privés : ex : Mozilla, Kernel Linux ou Blender. Une fondation coordonne les efforts communautaires ainsi que des employés à temps plein. Les grosses corps mettent des sous ou fournissent des employés car elles y voient leur intérêt.

Pour les questions de vie privée. Je suis moyen fan du terme hygiène car traiter de sales tout ceux qui ne se conforment pas me parait pas top. A contrario j'aime bien la métaphore du dentifrice pour Firefox, tor pour le savon. En tout cas j'aime bien ton idée de dire qu'il faut tout mettre en place pour pouvoir se prémunir le jour où la prise de conscience émerge et qu'on est prêt à passer à l'action. Mais bon pas de miracle, ça demande de la discipline !

Oui on est pas obligé de rentrer dans un rapport de force. Des fois il suffit juste de demander.

Dans le même style, mon frère me racontait une anecdote :

• Un collègue : Hey pourquoi tu as une meilleur machine que moi ?
• Lui : Tu as répondu quoi quand on t'a demandé ce que tu voulais ?
• Le collègue : un i5 et un 24 pouces
• Lui : Ba moi j'ai répondu un i7 et un 30 pouces (les configurations sont fictives)

A merci pour vos retours d'expérience, ça me rassure !

Oui je parle de prendre des patchs qui ne respecte pas l'architecture. Pour moi il faut les prendre pour assurer une plus grande diversité de contributeurs (Hintjens m'a convaincu). On est donc effectivement pas d'accord :)

Je faisais surtout référence à cette phrase dans mon commentaire (j'aurais du la citer) :

Cela correspondrait donc à mon intuition comme quoi le laxisme du réviseur de code est probablement une bonne méthode pour les projets naissants, mais pas forcément autant pour les gros projets.

Sinon pour le fork en général, je ne pense pas qu'il faut le prendre comme une chose négative. Je dis simplement que l'historique d'un projet, et surtout son nombre d'utilisateurs, crée de l'inertie. Donc au bout d'un moment, voir le projet forké pour lui permettre de retrouver du dynamisme et de confronter des points de vue différents me parait une étape logique dans la vie d'un projet à succès.

Pour ton cas de GIMP, c'est bien que quelqu'un tente quelque chose dans son coin (bon codeur ou non). Ca ne l'empêche pas de réintégrer ses ajouts plus tard ou tout simplement donner une seconde vie au projet si tout le monde le suit.

Ce n'est pas un contresens complet que de comprendre qu'Hintjens est extrême et que globalement il accepte beaucoup de patchs. Là où mon journal est effectivement ambiguë c'est que ce n'est pas clair de savoir s'il prend les patchs qui n'ont pas de sens ou ne sont pas pertinents. Je te remercie pour avoir complété avec les critères d'acceptation du C4 qui permettent de clarifier ça. 

Pour la phrase que tu cites elle est mal tournée en effet car on peut supposer qu'elle est en contradiction avec la notion de contrat. Par contre, elle a aussi son contexte : un paragraphe qui parle d'architecture (et un paragraphe précédent qui commence par "En très résumé" et qui invite donc à creuser si intéressé). Sur le plan de l'architecture, je vois rien dans le C4 en contradiction avec le fait qu'il prend presque tout.

Je pense qu'il y a ambiguité parce que tu te réfères au contrat qu'il a écrit et moi à ses talks et bouquins. Effectivement, il propose et recommande le C4, mais dans ses publications, il parle de contrat avant tout. Ensuite dans les 8 lignes que tu cites, il fait peu référence à l'architecture du logiciel. C'est surtout en ce point qu'il propose de laisser passer beaucoup de choses (et mon paragraphe commence en parlant de l'architecture).

Je suis d'accord que le terme laxiste est un peu fort et que j'aurais du mettre plus l'accent sur le contrat. J'aurais du aussi insister sur le fait que le patch doit résoudre un problème bien identifié.
Mais de mon point de vue, le message principal reste qu'il faut faciliter la contribution au maximum. Pour cela on peut se permettre de faire des bons compromis sur l'architecture et la qualité du code.

C'est forcément plus fin, car j'ai résumé en quelques paragraphes plusieurs talks et écrits.

Je comprends pas pourquoi tu dis que je ne lui rends pas justice. Il insiste beaucoup sur le fait d'intégrer rapidement les contribs des autres. Dans un de ses talks, il invite même ses mainteneurs principaux à faire la course pour merger le plus vite possible un patch. Il indique également qu'il n'a pas peur de casser ses tests.
Je mentionne bien par la suite que certaines règles doivent être respectées. Mais que celles-ci sont établies à l'avance. Pieter Hintjens parle de contrats. C'est le rôle des mainteneurs principaux de les établir car ils ont une bonne connaissance du projet.

D'ou ma question, est-ce que tu peux me dire en quoi je ne lui rends pas justice ?

Est-ce que ça ne veut pas dire que tout gros projet est destiné à être forké ?
Si à partir d'une certain taille critique, cela devient trop risqué de le bouger, ne devrait-on pas appeler au fork pour permettre à une version expérimentale qui évolue rapidement d'émerger ?

Je programme en bépo et je trouve cette disposition mieux que l'azerty pour coder. Certaines touches comme les accolades, ou les crochet pourraient être plus accessibles mais dans ça l'ensemble ça reste acceptable.

Là où ça a été plus difficile, c'est pour l'utilisation de vim. J'ai du remapper pas mal de touches. J'ai failli craquer et repasser en azerty à ce moment là mais au final je m'y suis bien fait. Par conséquent, ma config de vim devient très personnalisée. Ce qui fait que je ne suis efficace avec vim que dans le cadre de mes paramètres.

A l'époque où Steve Jobs a fait l'erreur, comme tu dis, on trouvait peu d'info sur les startups et la création d'entreprise. La situation est très différente en 2016. Tu trouves pléthore d'informations en ligne, de nombreux incubateurs pour t'accompagner, et ce genre de problématique - faire entrer des investisseurs et se faire éjecter c'est le premier truc qu'on t'apprend quand on te parle de préparer des levées de fonds. Pour le savoir il faut se former/se renseigner. Mais c'est la première étape de la préparation d'une levée de fonds.

Pour autant ça arrive toujours souvent. Un blog post peut t'apporter des informations mais il ne pourra pas t'apprendre à faire face à ce genre de situation. Et la littérature entrepreunariale là dessus est pauvre comparée aux autres sujets. Les incubateurs sont plus focalisés sur la mise en oeuvre du business model et t'aident peu sur ces sujets.

NB : Steve Jobs savait très bien ce qu'il encourait en défendant son point de vue.

Donc ce que dit Zenitram est vrai : c'est le B.A.BA. Le problème des créateurs d'entreprise qui ont un rôle technique c'est que bien souvent il se cantonnent à leur travail "technique" et que donc tous les aspect "business" ils les laissent gérer par les autres. Dans le quotidien de la boîte c'est normal, mais en tant qu'actionnaire, c'est une faille.

En fait il faut bien prendre en compte que monter une startup est difficile et que être sur tous les fronts en mème temps, l'est encore plus. C'est pourquoi souvent on s'associe pour se répartir les domaines de responsabilité. Malgré ça le CTO s'intéresse aussi au business et peut l'influncer beaucoup (ex : Docker ou Hubspot). Là où tu as raison, c'est que, entre autres, j'aurais du m'investir plus dans la relation investisseur. Je l'ai appris «the hard way». Je pense pas que le terme BA BA soit adapté, ça demande pas mal de pratique pour être bien fait.

Je ne partage pas cet avis.

J'ai dit ça pour exprimer le fait que c'est la boîte que j'ai fondé et que j'avais un lien affectif fort avec elle. Après techniquement tu as raison, je ne possède qu'un bout de la boîte.

J'ai un droit de réponse sur ce communiqué et sur ce que dit Bruno. Je le posterai sur mon blog et en journal sur ce site dès que possible.

Pour information, la politique chez Cozy est de réaliser les nouveaux projets en ES6. Le fait de proposer un langage plus populaire permet de faciliter les contributions.

Merci pour les retours d'expérience détaillées. Je n'ai plus envie de me battre pour que ma PR passe sur Express (projet qui a un prob de gouvernance en plus). L'idée de cette partie de mon post était surtout de faire un constat sur ce qui pouvait arriver. Je ne cherche pas à blâmer l'auteur (qui je crois est en burnout) mais à indiquer qu'un dév conséquent même bien fait n'aboutit pas toujours à une intégration dans le projet cible.

Bref, je pense qu'on a encore de la marge pour améliorer le flux des contributions et savoir à quoi s'attendre !

Bon ça me rassure sur mon expérience avec Express, je ne suis pas le seul à vivre une déception. Je pense que la prochaine fois je serai clair sur mes attentes au moment de proposer des modifications. Après il faut être indulgent avec les auteurs, ça peut demander beaucoup de boulot d'intégrer un développement externe.

A oui j'avais oublié ça ! Pour l'esperanto je te pingerai le jour où je m'y attaque mais ce sera pas pour tout de suite. Idem pour Lua. Je connais un fanatique du langage qui m'a déjà aiguillé sur des bonnes ressources.
Pour Go, pour commencer, je suis en train de lire tout le site : http://gobyexample.com/ .

Merci pour ces informations qui complètent bien mon post. Tu as raison, dans mon article je n'ai pas intégré le contexte. Selon la gouvernance, d'acteurs impliqués et de type de projet (lib, appli bureau, appli web, outil sytème, etc.), il ne faut pas s'attendre aux mêmes types de réaction. Ca me fait remarquer que le sujet de la contribution est vaste et mériterait plus d'un article pour être bien couvert.

T'étais à PSES, j'aurais du lire le programme… En tout cas bel initiative pour Libervia. J'espère que ça va marcher !