One of the classical issues with Open Source as a social movement is its opinion on promo work and marketing. We distrust marketing. We see it as someone trying to trick someone else into using something that isn't very good. In response, we often try to just describe what it is we have – assuming that its technical excellence will, in and of its own, make people use it. We employ a communicative form in marketing and promo material that is perhaps “precise” but not very “correct” - a distinction that can be illustrated by, for example, calling this column “a longer bit of text defined as a column with more or less subjective commentary on the state of Open Source in general and design work in KDE community in specific”. It doesn't roll off the tongue does it? In fact, I got bored writing it halfway through, meaning that most would be bored reading it after the second word. A more correct term for this column would be “Column about Design and Open Source” - it says what it needs to say but also without going into frivolous specifics. So in promotional work, Open Source projects strive for exactness and being precise – we try to explain exactly what something is in the hope that the reader won’t fall asleep about halfway through, and will notice the technical excellence that we have created. The bitter reality of which is that it doesn't work.
Un des problèmes classiques pour l'Open Source comme mouvement social, c'est son opinion sur le travail de promotion et le marketing. Nous craignons le marketing. Nous voyons cela comme quelqu'un tentant de tromper quelqu'un d'autre en lui faisant utiliser quelque chose qui n'est pas très bon.
En réponse, nous essayons juste de décrire ce que nous avons - en supposant que son excellence technique seule poussera les gens à l'utiliser.
Nous employons une forme de communication en marketing et en moyens promotionnels qui est peut-être « précise » mais qui n'est pas très « correcte », une distinction qui peut être illustrée, par exemple, en appelant cet article « un long morceau de texte défini comme faisant partie d'une rubrique avec des commentaires plus ou moins subjectifs sur l'état de l'Open Source en général et le travail de conception dans la communauté KDE en particulier ». Ça ne vient pas facilement aux lèvres, n'est-ce-pas ? En fait, l'écrire à moitié était ennuyeux au possible, ce qui signifie que la plupart des gens s'ennuieront après avoir lu le deuxième mot. Une expression plus correcte pour cet article serait « Article sur la Conception et l'Open Source ». Ce qui doit être dit est dit, sans se perdre dans des détails frivoles.
Ainsi dans le travail promotionnel, les projets Open Source aspirent à l'exactitude et à la précision ; nous essayons d'expliquer exactement ce qu'est quelque chose en espérant ne pas endormir le lecteur, qui devra même se rendre compte de l'excellence technique que nous avons créée. Mais l'amère réalité est que cela ne fonctionne pas.
In communicative theory, it would be explained as based on the false presumption that the readers/receivers are all a homogeneous mass and that they share the writer’s/sender’s disposition exactly. So what can we do to change this without, for that matter, scrapping our healthy skepticism of “marketing language” (as someone who's had long experience with marketing – skepticism is a must)? The first bit is throw everything we think we know about terminology out the window. A name, whether its an app, an OS, or the header for an article, has to be correct instead of precise. It has to deliver usable information based on assumptions of the reader. Saying “Filemanager” is better than calling it “Dolphin” even though “Dolphin” is the name of the application. Calling it “Files” is even better. Yes, the application is a filemanager, but who cares? Will a user, well versed in what Dolphin does, be confused by the application’s new name? Probably not. The icon is there to assist you, the name is there telling you essentially what it is – so he or she won't even notice after the first two second confusion. But for the new user this makes sense. Files is where the files are, that’s where they are handled - “managed” even. The assumption is there, so no need to spell it out and no need to be “precise” – just “correct”.
En théorie de la communication, l'explication serait que c'est basé sur une hypothèse fausse : que les lecteurs/récepteurs forment une masse homogène et qu'ils partagent exactement l'état d'esprit de l'auteur/émetteur. Alors que pouvons-nous pour changer ça sans, du reste, abandonner notre salubre scepticisme du « langage marketing » (ayant une longue expérience du marketing, je sais que le scepticisme est un « must ») ?
Le premier point c'est de passer par la fenêtre tout ce que nous savons sur la terminologie. Un nom, que ce soit pour une application, un système d'exploitation ou un article, doit être correct plutôt que précis. Il doit fournir une information basée sur les présomptions du lecteur. Dire « Gestionnaire de fichiers » est meilleur que l'appeler « Dolphin » même si « Dolphin » est le nom de l'application. L'appeler « Fichiers » est encore meilleur. Oui, l'application est un gestionnaire de fichiers, mais qui s'en préoccupe ? Un utilisateur, bien au fait de ce que Dolphin fait, sera-t-il induit en erreur par le nouveau nom de l'application ? Probablement pas. L’icône est là pour vous aider, le nom est là pour vous dire succinctement ce que c'est, de telle sorte qu'il ou elle ne sera perdu que pendant quelques petits instants. Mais, pour le nouvel utilisateur, cela paraît logique. Fichiers, c'est là où sont les fichiers, là où on les manipule, où on les gère, même. Voilà l'hypothèse, donc pas besoin de décrire clairement ni d'être « précis », juste « correct ».
Another example of this is if we look at the actual marketing and promo being done. How many articles haven't most linux users read that include more technical spec than information? Yes, technical specs ARE information, but it’s information that requires a lot more from the reader than would be advisable. This is a good moment to step back and look at what is meant to be communicated in the text – first you want to add the soft core values of the thing being explained. After that you explain how these values are represented as actual details of the object, and, finally, after all that is done, you put in technical details. Why do it that way, you might ask? Well, because, to most users, the most relevant bits are the core values of the desktop: “It’s lightweight”; after that they might want to know WHY it's lightweight: “Because we removed applications that started by default before,” and finally a technical summary of the changes done for those interested. A technically interested reader might skip ahead as long as he or she knows the technical bits are further down. But a technically disinterested person tends not to bother skimming through often more bulky technical bits to find the, to him or her, relevant parts. But why should we even care about marketing? Simply put, user spread. We are writing texts for no one, designing applications for experts, and then seem to be shocked that many users feel alienated. By making it accessible to more, by leaning towards the assumption that our techy users feel covered enough, we can actually try to explain the awesomeness of the techy bit for those users who aren't at home in these surroundings. By doing that, we aren't dumbing things down – we're smarting it up. We are letting more people get an “in” to the technical brilliance that is Linux.
Un autre exemple de ceci, c'est quand nous regardons une réelle action de marketing et de promotion. Combien d'articles ont-ils été lus par la plupart des utilisateurs de Linux, qui contiennent plus de spécifications techniques que d'informations ? Oui, les specs techniques sont de l'information, mais c'est de l'information qui demande beaucoup plus au lecteur que ce qui est recommandé. Le moment est venu de prendre du recul et de regarder ce qui devrait être communiqué dans le texte : d'abord vous voulez y mettre les valeurs fondamentales de la chose à décrire. Après cela, vous expliquez comment ces valeurs sont représentées dans les détails réels de l'objet et, enfin, vous mettez des détails techniques.
Pourquoi faire comme ça, me direz-vous ? Eh bien, par ce que, pour la plupart des utilisateurs, les points les plus significatifs sont les valeurs fondamentales de l'ordinateur de bureau : « il est léger » ; après ça, ils pourraient vouloir savoir POURQUOI il est léger : « parce que nous avons retiré des applications qui, avant, démarraient par défaut » et, enfin, un résumé technique des modifications pour ceux que ça intéresserait. Une personne intéressée par la technique pourrait en sauter une partie, du moment où elle sait que les informations techniques paraitront plus loin. Une personne sans goût pour la technique ne prendra pas la peine de naviguer dans les volumineux détails techniques pour trouver les parties qui l'intéressent.
Mais pourquoi devrions-nous toujours nous préoccuper de marketing ? Tout simplement, à cause de la diversité des utilisateurs. Nous n'écrivons des textes pour personne, concevons des applications pour les experts, et nous semblons choqués que beaucoup d'utilisateurs se sentent non concernés. En rendant accessible au plus grand nombre, en penchant pour l'idée que nos utilisateurs techniques se sentent assez concernés, nous pouvons vraiment essayer d'expliquer combien les parties techniques sont géniales aux utilisateurs qui ne se sentent pas chez eux dans ces domaines. En faisant cela, nous ne rabaissons pas les choses, nous les rendons plus intelligentes. Nous laissons plus de gens entrer dans la brillante technique qu'est Linux.