Une réponse

Cet article est une réponse à un autre article.

Mon sentiment général sur cet article est positif. Je suis heureux que ce sujet soit posé sur la table. Je suis en accord complet sur le fond. La licence d’un logiciel ne suffit pas à aider sa qualité ou son adoption ; ne suffit pas à être un élément différenciant pour la majorité de l’humanité concernée. La disponibilité sur Github non plus.

Mais cet article manque cruellement de pistes de solutions, de propositions de mieux. et à mon goût transmet une vision du travail collectif qui trouvera vite ses limites.

Point par point

Le manque de moyens et de compétences

Un développeur d’application libre commence souvent son application seul,

[citation needed] Ca ressemble plus à un mythe qu’une réalité. Mais admettons.

et en général il n’est ni designer ni directeur artistique, donc il fait avec les moyens du bord. Même si à mon sens c’est une erreur, et qu’un designer (au sens large) devrait être intégré dès le début, c’est souvent difficile, donc on fait sans.

Ca a lieu comme ça, mais ça serait mieux autrement, mais c’est difficile, donc ça n’a pas lieu. Ok. On fait quoi ? Les dévs arrêtent de commencer des projets ? On force les dévs à trouver un designer avant d’écrire la première ligne de code ?

… ou peut-être que les développeurs pourraient acquérir des compétences de design ?

C’est beau donc c’est sale

Vieux réflexe hérité de la guerre du 1er janvier 1970 entre la tribu des techos et celle des marketos

Toutaf. Je déteste cette guerre. Elle n’a aucun sens. Pour trouver une bonne solution, de nombreux problèmes nécessitent que des gens avec des compétences différentes s’allient et se parlent pour résoudre ensemble.

Comment arrêter cette guerre ?

J’ai récemment proposé mes services pour aider des projets libres à communiquer, et j’ai eu plusieurs réponses du style “je pense que tout va bien, il faudrait juste designer une skin pour le site web” ou encore “si tu veux aider pour la com’ regarde dans le trello, y’a des pictos à faire”.

Ca marche comment la proposition de service ? La frustration a l’air enracinée sur un problème de communication entre différentes cultures.

Pull request as design

Commençons par dire que je déteste le terme “Pull request”. “Change proposal” serait plus approprié à plusieurs niveaux.

L’outil conditionne aussi le design. En plus de n’être pas familier avec ces outils de devs (non, ils ne doivent pas plus les apprendre que le dev ne doit apprendre Illustrator…) ces outils formattent la pensée et la façon d’aborder une problématique (c’est pareil pour Invision d’ailleurs, qui est pourtant un outil de designers).

oui. oui. oui. Mais on fait quoi ? On utilise quels outils ? Spécifiquement, sur quels outils peut-on collaborer entre devs et designers ?

Par exemple, le fait qu’un projet libre avec l’importance et l’ambition de Cozy Cloud n’emploie qu’un designer sur 27 salariés me fascine.

Un peu de nuance ? Il semblerait que certains devs là-bas soient capables d’un peu plus qu’écrire du code.

“À Chacun son métier”

Le problème du libre n’est pas qu’il n’y a pas assez de designers. Il y a une racine plus profonde. Le problème est que certains libristes soient fermés à d’autres compétences, d’autres métiers.

La réponse à ce problème ne peut pas être de tracer une ligne et de se séparer en disant “ça, c’est mon travail, ça c’est le tien”.

Evidemment, ça commence par respecter les compétences et le métier les uns des autres, mais ça ne suffit pas. J’ai posé des petits cailloux dans mes réponses précédentes. Nous devons nous parler les uns les autres, échanger sur nos cultures, nous comprendre.

C’était fascinant d’aller au DemoDay du Wagon Bordeaux. Parmi les gens qui apprenent à coder, il y a des gens qui veulent lancer leur startup. Illes ne veulent pas devenir développeur à plein temps pour autant. Mais apprendre à coder leur met un premier pied dans le monde des dévs, partager leur culture et au final, savoir mieux parler avec des dévs le jour où il veulent recruter ou évaluer le travail d’un développeur.

Il y a des dévs qui sont capables de faire du design sans que ça soit le cœur de leur métier. Et des designers capables de dév sans que ça soit le cœur de leur métier. Mais ça aide à se comprendre, à trouver les bons outils/workflow pour collaborer efficacement dans nos métiers respectifs.

Une triste mais nécessaire exclusion ?

Je viens de comprendre : les libristes font exprès d’être désagréables avec les non-geeks, par snobisme ou pour protéger leur utopie 😕

- Clochix <3

Il y aura toujours des libristes qui n’ont pas envie de travailler avec des gens d’une autre culture, qui n’en comprendront pas l’intérêt. Dommage. La mauvaise nouvelle, c’est qu’il faut juste passer son chemin et ne pas perdre de temps avec des gens avec qui il n’y a aucune chance de créer ensemble. La bonne nouvelle, c’est que l’on n’est pas obligé de travailler avec qui que ce soit dans le monde du logiciel libre…

Quand on fork, on perd le canal de distribution principale du logiciel, mais l’auteur nous explique que “[les questions] [de la stratégie et du positionnement] ne sont jamais abordées” dans les projets de logiciel libre. Il ne devrait donc pas être si difficile de faire mieux pour devenir le canal de distribution principale ?

Mais la collaboration est possible si les personnes autour de la table partagent un même objectif et une certaine ouverture d’esprit.