Aujourd’hui, c’est la Saint Valentin, et l’occasion de déclarer son amour des logiciels libres !
Framasoft vous a déjà proposé son adaptation délirante de poèmes pour l’occasion, et voici une petite bande-dessinée qui synthétise l’événement :
Cette bande-dessinée est extraite du nouveau blog Grise Bouille hébergé par Framasoft.
Crédit : Simon Gee Giraudot (Creative Commons By-Sa)
Aujourd’hui, ce n’est pas un jour comme les autres. Journée de l’amour pour les uns, journée commerciale à bougonner pour les autres, elle ne laissera personne indifférent. Pourquoi ne lui donner une dimension toute différente, en en profitant pour déclarer notre amour aux logiciels libres, et aux développeurs du libre que nous torturons à longueur d’année, en bons utilisateurs exigeants et spécialistes du yakafokon que nous sommes.
C’est ce que nous propose la FSF avec sa campagne I love Free software, reconduite cette année. Il est important parfois de savoir lâcher prise pour clamer haut et fort que nous les aimons, ces logiciels libres.
Nous avons choisi pour notre part de vous proposer un fork de poèmes que vous devez tous connaître… Demain dès l’aube, de Victor Hugo et Le dormeur du Val d’Arthur Rimbaud.
Demain, dès l’aube, à l’heure des châteaux en Espagne,
Je râlerai. Vois-tu, je sais que tu m’entends.
De toi j’exigerai de coder des montagnes.
Je ne puis retenir mes commits plus longtemps.
Ce jour, je te le souhaite sans bug à obvier,
Nulle exigence en moi, nulle attente s’induit,
Seul, ton labeur, le dos courbé, mains au clavier,
Fier, voit le fruit de l’écran qui a blanchi tes nuits.
Je ne t’apporterai ni les bitcoins qui tombent,
Ni le vert des dollars qui ternit leur valeur,
Mais bientôt avec toi nous ferons la bombe
Une main sur la bière et l’autre sur le cœur.
(v. 4.2)
Dans un réduit obscur il chante une rengaine
Enchaînant follement les semaines aux semaines,
Content quand des lignes obscures s’empilent
Et il boit du maté quand son code compile.
Un codeur jeune, Git ouvert, tête nue
Et la face baignant dans de frais rayons bleus
Dort ; il est vautré dans le PHP chenu
Pâle dans son t-shirt geek au Tux globuleux
Les mains dans le cambouis, il dort. Souriant comme
Sourirait un géant, ce n’est pourtant qu’un homme :
Le livreur de pizzas seul nourrit cet ermite.
Les crashtests, il s’en est déjà bien trop nourri ;
Il dort sur son clavier, la main sur la souris,
Tranquille. Il a deux bugfix dans son commit.
Chez Framasoft, on ne code pas (ou très peu). On utilise le code développé par des personnes formidables, par des communautés de passionné-e-s, et on le propose au grand public sous forme de services libres et gratuits.
Nous tenons donc aujourd’hui à déclarer notre amour aux équipes développant Etherpad (Framapad), Ethercalc (Framacalc), studs & le fork framadate, Wisemapping et Mindmaps (FramindMap), SVG-Edit (Framavectoriel), TinyTinyRSS (Framanews), Wallabag (Framabag), Diaspora* (Framasphère)… et tant d’autres !
Et un spécial chaton d’amour aux équipes (et à la fondation Mozilla) derrière FireFox qui vous permettent d’utiliser ces applications web depuis un navigateur Libre.
Le développement du plugin a démarré mi-décembre, dont cette annonce aura été le témoin.
La feuille de route prévue était basée sur le fait que que le développeur consacrerait environ la moitié de son temps à MyPads et ce, jusqu’à la fin du mois de février.
Le calendrier est en réalité quelque peu décalé et compressé. Outre les fêtes de fin d’années, le prestataire a préféré en terminer avec ses autres engagements professionnels. Il n’a donc que très peu avancé sur MyPads.
Il a désormais assuré qu’il se dédierait exclusivement jusqu’à la fin du mois de février au plugin. Des progrès rapides devraient être visibles sur notre espace Gitlab (en maintenance pour le moment), à travers le code source, les tickets et le wiki.
Si les tests en conditions réelles ne se feront que dans quelques semaines, la date de sortie annoncée n’est pas pour autant remise en cause : le plugin reste prévu pour la fin du mois de février.
The development of MyPads has begun from the second half of December. Here is the annoucement.
The initial roadmap was based upon the fact the programmer would dedicate half of his time to MyPads development, from December to the end of February.
The schedule will actually be postponed and compressed. In addition to year’s end celebrations, the contractor has chosen to finish his other professional commitments. Consequently he hasn’t done much work for MyPads.
He has confirmed that he will be dedicated full time working on the plugin til the end of February. You’d be able to see significant progress in our Gitlab instance (at the moment down for maintenance), through the source, tickets and the wiki.
If real world tests can only be possible within a few weeks, the announced publishing date isn’t challenged: MyPads remains scheduled before March.
(english version below)
Notre éditeur de texte libre et collaboratif Framapad est une implémentation du logiciel libre Etherpad. Ce service est mis à la disposition de tous et cela démontre en même temps que ce service peut être proposé de manière décentralisée (même si nous sommes peu nombreux à proposer une instance publique d’Etherpad, des milliers d’instances privées existent).
Au mois de juin dernier, Framasoft a lancé une campagne de financement participatif visant à contribuer activement à l’amélioration d’Etherpad pour y ajouter la gestion des comptes utilisateurs, des groupes et des pads privés. Il n’aura fallu que trois semaines pour que l’objectif soit atteint. Nous vous en remercions une fois encore.
Le but de ce projet est de permettre aux utilisateurs d’Etherpad, et donc de Framapad, de créer un compte en leur nom, d’y associer des groupes et, pour chaque groupe, des pads. Ces pads pourront être publics, privés sur invitation ou encore d’accès restreints par l’usage d’un mot de passe. Le tout doit prendre la forme d’un plugin pour Etherpad, publié sous licence libre et s’installant de la même manière que tous les autres plugins du logiciel.
Il était prévu que la réalisation débute à la rentrée et que le plugin soit livré en fin d’année. La feuille de route a quelque peu glissé du fait de la surcharge temporaire du prestataire sélectionné. Le coup d’envoi est néanmoins lancé cette semaine et l’ensemble du développement se déroulera sur notre Gitlab via le projet ep_mypads https://git.framasoft.org/framasoft/ep_mypads .
Le plugin est attendu pour la fin du mois de février 2015. Il devrait comporter de petits bonus par rapport au cahier des charges initial.
Les premières semaines seront consacrées à l’écriture du code serveur, à sa documentation et à ses tests. Il faudra attendre début 2015 avec la création de l’interface graphique afin que MyPads puisse commencer à être testé.
Pour rappel, le cahier des charges originel est disponible sur ce pad : http://lite4.framapad.org/p/LEpEOUoQb3/timeslider#24.
Un point sur l’avancement du développement sera réalisé environ toutes les deux semaines.
——-
MyPads : development launched
Our free/open source and collaborative editor named Framapad, is an application of the free software Etherpad. This GoogleDoc-like service is opened for everybody and demonstrate simultaneously that it can be proposed in a decentralized way (even if only few organizations can propose such an open service, thousands private instances are running).
In last June, Framasoft has launched a crowdfunding campaign aiming to to contribute actively to Etherpad’s improvement, by adding the management of users, groups and private pads. Only three weeks have been necessary to reach the goal. We want to thank you again.
The purpose of this funding is to let Etherpad and so Framapad’s users create an account, link some groups and for each group some pads. These ones may be public, privates with invitation or protected by a password. All of this must be an Etherpad plugin, pubished under open source license. This have to be installed like any other Etherpad plugin.
The beginning of the plugin’s cofing was planned at the fall this year. The roadmap has moved forward because of the contractor’s overloading. However the project is launched this week and the development will be made on our Gitlab instance with the ep_mypads project https://git.framasoft.org/framasoft/ep_mypads
The plugin is expected on the end of February, 2015. It might include several little extra comparing to the original specifications.
First weeks will be dedicated to server side programming, its documentation and tests. You’ll have to wait for 2015 with the creation of the user interface if you want to test MyPads.
As a reminder, you will find the initial specifications on this pad http://lite4.framapad.org/p/LEpEOUoQb3/timeslider#24
A stage news will be made around every two weeks.
Nous avons reçu il y a quelque jours un appel téléphonique. Jusque là, rien d’anormal. Ce qui l’était plus, c’était qu’il émanait d’un groupe d’agricultrices. Leur demande ? Faire réaliser un logiciel qui leur permettrait de suivre un programme expérimental d’utilisation de produits en médecines alternatives (homéopathie/aromathérapie notamment). Pour le suivi de l’expérimentation, elles souhaiteraient utiliser un logiciel leur permettant de saisir des données sur leurs smartphones, ainsi qu’obtenir différents types de bilans ou statistiques.
Ce type de développement (quand bien même rémunéré, ce qui serait le cas ici) ne rentre pas vraiment dans le cadre des missions de Framasoft. Cependant, en répondant à leurs questions, il nous est apparu assez clairement que nous avions des valeurs communes (partage du savoir, non appropriation du bien commun, volonté d’agir “ensemble”, etc.).
Nous avions déjà, il y a quelques mois, mis en avant un logiciel libre dédié à l’agriculture : Agritux (on me souffle à l’oreille que si vous êtes intéressés par le sujet, vous devriez aussi jeter un œil à Ekylibre). Il est donc plutôt passionnant de voir des liens se tisser entre ces deux mondes en théorie relativement éloignés.
Pour en savoir plus, nous avons demandé à ces agricultrices de répondre à quelques questions.
Et si vous souhaitez développer une application libre (avec une interface pour smartphone) répondant à leur problématique, n’hésitez pas à les contacter.
Bonjour, pouvez-vous vous présenter, ainsi que votre projet ?
Nous sommes 8 agricultrices regroupées en collectif GEDA (Groupe d’Études et de Développement Agricole) au niveau d’un canton au Nord de Rennes.
Nous échangeons régulièrement sur des thèmes variés techniques ou pas, professionnels ou pas suivant nos propres choix. Nous cherchons également à faire mieux connaitre notre métier en intervenant dans les écoles primaires et maternelles. Nous collaborons également avec les élus de notre territoire. La réflexion collective est en effet un moyen de nous sentir rassurées dans notre métier. Elle nous donne la force d’oser dialoguer avec l’ensemble des acteurs non agricoles de notre territoire et de partager nos travaux au-delà des frontières de nos fermes.
Nous avons décidé en 2012 d’en connaitre davantage sur les médecines alternatives en élevage bovin pour maîtriser la santé de nos troupeaux d’une manière plus respectueuse de l’environnement et de la santé humaine. Très vite nous avons donc commencé à tester l’homéopathie et à observer des résultats positifs sur nos troupeaux. Et depuis notre soif de savoirs et d’expériences s’est accrue : l’aromathérapie, les méthodes d’observation du troupeau (Obsalim®), la phytothérapie, … sont aujourd’hui autant de voies que nous souhaitons découvrir et tester sur nos exploitations pour adapter au mieux notre stratégie d’exploitation. En parallèle notre envie de communiquer pour revaloriser notre beau métier s’est développé. De là est né notre projet sur trois ans qui nous permettra de :
Pour atteindre ces objectifs, nous avons notamment décidé de travailler à la conception d’un outil de suivi de notre expérimentation sur Smartphone. C’est dans ce cadre que notre collectif vous a contacté.
Pour cela, vous souhaitez éventuellement faire réaliser un projet logiciel. Pouvez-vous nous en dire plus ?
Pour bien appréhender les problèmes de santé des animaux, une observation minutieuse des bovins est indispensable au quotidien et à tout moment. Un suivi également des traitements alternatifs appliqués (homéopathie, aromathérapie,..) est indispensable aussi pour ensuite pouvoir identifier les facteurs d’échecs ou de réussites de nos expérimentations. Un support pour enregistrer ces informations est donc nécessaire et doit correspondre à nos conditions de travail : plus on a d’animaux, plus le nombre de remarques et d’actions effectuées est important. Comment tout noter en permanence de façon confortable et surtout efficace ?
De nombreux agriculteurs sont aujourd’hui équipés de smartphones. Celui-ci permettrait un enregistrement rapide et confortable quel que soit le lieu d’observation : de la salle de traite aux pâturages. Toutes les informations concernant chaque animal dès sa naissance doivent pouvoir être enregistrées dans cette application: les événements importants et marquants, ses particularités (caractère, physique,…), son comportement, avec les dates, etc… Pour être efficace dans la pratique des médecines alternatives, le moindre événement dans la vie de l’animal peut être important et le choix du traitement à appliquer tout comme sa réussite en dépendent. Ce logiciel nous permettra également de capitaliser plus facilement puis d’analyser collectivement nos résultats d’expérimentations de soins alternatifs aux traitements conventionnels.
Le logiciel libre semble porter certaines valeurs communes avec votre projet, comme par exemple la mutualisation, la coopération, la volonté de partager le savoir et les connaissances, etc. Pourtant, le monde du logiciel et celui de l’agriculture semblent bien éloignés. Aviez-vous entendu parler de logiciel libre ou de culture libre avant d’avoir ce projet logiciel ?
Bien sûr nous en avions entendu parler mais uniquement dans le cadre de la sphère privée avec les logiciels libres de traitement de texte par exemple.
Avant l’émergence de notre projet collectif, nous n’avions pas vraiment fait le lien entre notre métier et le monde de la culture libre, mais dès que l’idée d’un logiciel a émergé nous avons tout de suite pensé à une application gratuite et diffusable à tous. Pourquoi ? Tout simplement parce que notre démarche collective qui vise l’échange et le partage, la reconquête notre autonomie, notre liberté de choisir et celle du mouvement des logiciels libres sont parallèles et cohérentes. Dans les 2 cas il s’agit de démarche de partage et de liberté.
Pour aller plus loin dans le parallèle, grâce à ce projet et en partenariat avec le lycée agricole de notre secteur, nous voulons également transmettre nos expériences au plus grand nombre agriculteurs et aux générations futures d’agriculteurs. Les communautés qui prônent le logiciel libre sont également dans cette démarche puisque les outils développés sont transmissibles, modifiables et adaptables librement.
Et nous ne nous étendrons pas sur la similitude entre les semences agricoles qui pourraient être comparées à des logiciels. Si aujourd’hui nous avons le droit de pouvoir ressemer l’année suivante notre propre semence récoltée (cela est de plus en plus remis en question), nous ne pouvons échanger ou vendre des semences non certifiées. Pourquoi devoir en permanence dépendre des grosses firmes multinationales “de semences” ? Le côté économique est un élément important car une semence “certifiée” a un coût beaucoup plus élevé qu’une semence récoltée sur l’exploitation. Et on ne parle que de blé et d’orge car le maïs hybride ne se développera pas ou de manière dégénérée l’année suivante si on tente de le semer. Sur ce point encore nos idées se rejoignent : à quand la semence libre ? 🙂
Pour les non-initiés, l’informatique (et internet) semble jouer un rôle croissant dans le quotidien d’une exploitation agricole. Vous confirmez ?
Effectivement, sans internet, l’exploitation fonctionne au ralenti…L’accès à l’information se fait de plus en plus via les sites agricoles spécialisés : marchés, réglementation, résultats d’analyses (réaction plus rapide si résultats connus précocement).
La gestion financière de l’exploitation se fait au jour le jour et est facilitée par la consultation régulière des comptes bancaires. La gestion administrative, de plus en plus exigeante et importante est facilitée par les messageries électroniques qui permettent de communiquer plus rapidement et efficacement avec nos différents partenaires, le téléchargement de formulaires.
La gestion des cultures et de ses différents enregistrements se fait fréquemment sur des logiciels spécialisés qui permettent de répondre aux exigences réglementaires (intrants…).
La gestion des troupeaux peut être gérée informatiquement via différents supports : quantités de lait produites, gestion de la reproduction via des aides à la détection de chaleurs, de vêlage, gestion de l’alimentation (en production porcine notamment). L’identification animale se fait via des serveurs spécialisées qui permettent l’accès aux bases de données animales.
Merci ! 🙂 Un petit mot pour la fin ?
Nous aurons bien sûr besoin d’un développeur pour notre logiciel :=), donc si des personnes sont intéressées, contactez-nous par email : frgeda.bretagne (chez) gmail (point) com
Pour financer notre projet sur trois ans, nous avons répondu à l’appel à projet de la Région Bretagne sur Agriculture Écologiquement performante, alors croisez les doigts pour nous 😉
Et surtout merci à vous de nous guider pour nos premiers pas dans ce monde du logiciel libre!!!!
Le travail intellectuel des programmeurs souffrirait-il d’un manque de visibilité et de reconnaissance aux yeux d’une logique managériale qui cherche à mesurer le travail effectif avec des critères dépassés ? C’est ce que laisse entendre ce témoignage qui au détour d’une plaisante anecdote met l’accent sur un relatif malaise d’une profession qu’il est difficile de cerner de l’extérieur, et même de l’intérieur d’une entreprise.
Are Your Programmers Working Hard, Or Are They Lazy? article paru sur le blog de l’auteur
Traduction Framalang : sinma, goofy, KoS
Quand quelqu’un effectue une tâche physique, il est facile d’évaluer à quel point il travaille dur. Vous pouvez le voir physiquement en mouvement et en transpiration. Vous pouvez aussi voir le résultat de son travail : le mur de briques s’élève, le trou dans le sol devient plus profond. Reconnaître et récompenser un dur labeur est un instinct assez fondamental chez l’être humain, c’est l’une des raisons pour lesquelles nous trouvons les sports d’endurance si fascinants. Cette reconnaissance d’un dur travail physique devient un problème quand on l’applique à la gestion de personnes qui travaillent à des activités techniques ou créatives. Souvent, les travailleurs intellectuels efficaces n’ont pas l’air de travailler très dur.
En 2004, j’étais développeur junior dans une grande équipe qui s’occupait du système de fourniture et de facturation d’une entreprise de télévision par câble. Comme tous les grands systèmes, il était constitué de plusieurs unités relativement indépendantes dont s’occupaient des personnes ou des équipes différentes. Les départements de TV analogiques et numériques étaient presque entièrement séparés, pris en charge par des équipes différentes.
L’équipe de la TV analogique avait décidé de fonder son système autour d’une pré-version de Microsoft Biztalk. Quatre gars de chez nous et une équipe de Microsoft le développaient et le faisaient tourner en production. Ils avaient tous l’air de travailler très dur. On les voyait souvent travailler tard dans la nuit et pendant le weekend.
Chacun laissait tomber ce qu’il était en train de faire si un problème survenait en production, ils se réunissaient souvent autour du bureau d’un type, faisaient des suggestions pour régler ce qui n’allait pas, ou pour réparer quelque chose. L’activité était permanente, et tout le monde pouvait voir non seulement qu’il y avait un véritable esprit d’équipe, mais que tout le monde travaillait très très dur.
L’équipe chargée de la TV numérique était tout à fait différente. Le code avait été, en majorité, écrit par une seule personne que l’on appellera Dave. Il était développeur de maintenance junior dans l’équipe. Au départ, j’ai eu beaucoup de difficultés à comprendre le code. Au lieu d’une seule longue procédure dans un endroit précis où tout le travail se serait effectué, il y avait des tas de petites classes et méthodes avec seulement quelques lignes de code. Plusieurs collègues se plaignirent que Dave rendait les choses extrêmement compliquées. Mais Dave me prit sous son aile et me conseilla de lire quelques livres sur la programmation orientée objet. Il m’apprit les patrons de conception, les principes SOLID, et les tests unitaires. Le code commença alors à avoir du sens, et plus je travaillais dessus plus j’appréciais l’élégance de sa conception. Il ne posait pas de problème en phase de production, il ronronnait dans son coin et faisait le boulot. Il était assez facile d’opérer des modifications dans le code, du coup l’implémentation de nouvelles fonctionnalités se faisait souvent sans aucun problème. Les tests unitaires permettaient de trouver la plupart des bugs avant la mise en production.
Le résultat de tout cela est que nous n’avions pas l’air de travailler très dur du tout. Je rentrais chez moi à 18h30, je ne travaillais jamais pendant les weekends, nous ne passions pas des heures attroupés autour du bureau de quelqu’un d’autre pour deviner le problème avec un quelconque système planté en production. De l’extérieur, notre tâche devait sembler beaucoup plus facile que celle des gens de la TV analogique. En vérité, les exigences étaient très similaires, mais nous avions un logiciel mieux conçu et implémenté, et une meilleure infrastructure de développement, notamment les tests unitaires.
La direction fit savoir que des augmentations seraient accordées sur la base de nos performances. Quand ce fut mon tour de parler au directeur, il expliqua qu’il était normal que les augmentations soient accordées à ceux qui travaillaient vraiment dur, et que l’entreprise ne semblait pas importer beaucoup à notre équipe, au contraire de ces héros qui lui consacraient leurs soirées et leurs weekends.
photo par nic’s events – CC BY-SA 2.0
Cette entreprise était l’un des rares laboratoires où l’on pouvait comparer directement les effets d’une bonne ou d’une mauvaise conception logicielle et le comportement d’une équipe. La plupart des organisations ne permettent pas une telle comparaison. Il est très difficile de dire si ce type, transpirant sang et eau, travaillant tard les soirs et weekends, constamment sur la brèche, fait preuve d’une grande volonté pour faire fonctionner un système vraiment très complexe, ou s’il est simplement nul. Sauf si vous pouvez vous permettre d’avoir deux ou plusieurs équipes concurrentes travaillant à résoudre le même problème, mais bon, personne ne fait ça, on ne saura donc jamais. Et au contraire, le type assis dans son coin, travaillant de 9 heures à 17 heures et qui semble passer beaucoup de temps à lire sur internet ? Est-il très compétent pour écrire un code stable et fiable, ou son boulot est-il plus facile que celui des autres ? Pour l’observateur moyen, le premier travaille vraiment dur, pas le second. Travailler dur c’est bien, la paresse c’est mal, n’est-ce pas ?
Je dirais qu’avoir l’air de travailler dur est souvent un signe d’échec. Le développement logiciel est souvent mal fait dans un environnement sous pression et dans lequel on est souvent interrompu. Ce n’est généralement pas une bonne idée de travailler de longues heures. Quelquefois, la meilleure façon de résoudre un problème est d’arrêter d’y penser, d’aller prendre l’air, ou encore mieux, de prendre une bonne nuit de sommeil et de laisser faire notre subconscient. Un de mes livres favoris est « A Mathematician’s Apology » (traduit sous le titre L’apologie d’un mathématicien) par G. H. Hardy, un des mathématiciens anglais les plus importants du XXe siècle. Il y décrit sa routine : quelques heures de travail le matin suivies par un après-midi à regarder le cricket. Il dit qu’il est inutile et contre-productif d’effectuer un travail mental intensif plus de quatre heures par jour.
photo par sfllaw – CC BY-SA 2.0
J’aimerais dire aux manageurs de juger les gens en regardant leurs résultats, leurs logiciels qui tournent bien, et non en regardant si les programmeurs ont l’air de travailler dur. C’est contre-intuitif, mais il est sans doute préférable de ne pas vous assoir tout près de vos développeurs, vous pourrez ainsi avoir une meilleure idée de ce qu’ils ont produit, sans être affecté par des indicateurs conventionnels ou intuitifs. Le travail à distance est particulièrement bénéfique ; vous devez apprécier vos employés pour leur travail, plutôt que par la solution de facilité qui consiste à les regarder assis à leur bureau 8 heures par jour, martelant de façon lancinante sur leur IDE, ou se pressant autour du bureau des autres pour offrir des suggestions « utiles ».
Aujourd’hui nous choisissons de mettre en lumière un jeune développeur qui devrait donner des idées à tous les étudiants en informatique qui nous lisent. Comme vous allez le voir, en choisissant la voie de l’open source, les projets qui paraissaient hors d’atteinte sont finalement accessibles. Rien n’est gagné d’avance mais la voie est libre !
De Firefox à Chromium en passant par Midori, ce ne sont pas les navigateurs Web qui manquent. Il y en a pour tous les goûts, des plus complets aux plus légers. Parmi eux se trouve QupZilla, un navigateur lancé en 2010 par son actuel développeur principal, David Rosca. Alliant légèreté et fonctionnalités, il a aussi la particularité d’être développé par un étudiant qui a lancé ce projet à l’âge de 17 ans, alors qu’il était encore lycéen. Il étudie maintenant l’informatique à l’Université technique de Prague, en République Tchèque. Aujourd’hui, il répond à nos questions pour le Framablog.
Contributeurs Framasoft :
David Rosca aka Nowrep, développeur de QupZilla
F : Bonjour David, merci de nous accorder cette interview. Peux-tu nous présenter le projet QupZilla ?
David : QupZilla est un navigateur web multi-plateforme écrit sur l’infrastructure Qt. Il utilise le moteur de rendu Webkit à travers le module Qt. L’utilisation de Qt fait que QupZilla est parfaitement adapté à la plate-forme KDE mais il fonctionne aussi très bien sur les autres environnements. Il fonctionne avec tous les systèmes d’exploitation. La dernière version (1.4.1) est sortie il y a peu de temps.
Il est important de dire que QupZilla est un navigateur web qui a pour objectif de rester léger, ne vous attendez donc pas à ce qu’il devienne aussi énorme que les navigateurs les plus courants.
F : Comment a démarré cette aventure ?
David : Cela ne devrait pas vous surprendre : j’aime coder et créer de nouvelles choses. J’avais déjà quelques expériences dans l’écriture d’applications et j’étais assez confiant sur les langages de script. Mon souhait était de créer une vraie application. L’élément déclencheur a été de passer sous un système d’exploitation Linux, à partir de ce moment, je me suis dit : « Pourquoi pas ? Il n’y a plus rien qui t’arrête maintenant ! ». En fait mon plus gros problème a été de trouver quel type d’application créer. J’avais commencé à suivre quelques tutoriels, je commençais à comprendre les bases de ce type de programmation mais l’ennui serait vite arrivé si je n’avais pas su quelle appli développer. Au cours d’une discussion, un ami m’a suggéré de créer un navigateur, c’était sans doute une plaisanterie mais j’ai vraiment aimé cette idée et j’ai donc commencé à travailler dessus.
F : Une fois que tu as su quoi créer, comment t’es-tu organisé ?
David : J’ai d’abord choisi un langage de programmation. Mon choix s’est porté vers Python, un langage plus facile que le C++. Bizarrement, choisir la facilité a été la cause de mon plus gros problème. Quand vous apprenez un nouveau langage de programmation, vous rencontrez de nombreux problèmes et vous cherchez des solutions sur Internet. Plus votre langage est populaire, plus vous trouverez de réponses. Mais même si PyQt (Python pour Qt) est très populaire, la majorité des tutoriels, exemples, etc. sont pour le C.
J’ai donc essayé de traduire le C++, utilisé dans les tutoriels, en Python. C’était très difficile car je n’avais aucune expérience du C++ et que je commençais à peine à apprendre Python. J’ai donc finalement décidé d’utiliser le C++ et j’ai réécrit tout le code que j’avais. Et ça a vraiment été une bonne chose.
À ce moment-là, je ne pensais pas que mon code puisse être rendu public. Je plaisantais bien sûr sur le fait qu’un jour, j’aurais des centaines de milliers de téléchargements, mais c’était tout. Je ne pouvais même pas imaginer que quelqu’un puisse vouloir participer à mon projet. Ce ne sont donc pas les choses auxquelles vous pensez quand vous êtes en train d’apprendre un nouveau langage et que vous commencez un « projet d’apprentissage ».
F : Tu as choisi de développer ton logiciel sous licence GPLv3. Peux-tu nous expliquer pourquoi ?
David : Pour être honnête, j’ai choisi la GPLv3 uniquement parce que la majorité des projets open source l’utilisaient (kernel linux inclus, mais en GPL V2). Je ne connaissais pas vraiment les différences entre les licences. Mais maintenant, je suis content de mon choix. Je ne voudrais pas choisir une autre licence pour Qupzilla. Je ne sais pas exactement ce que serait la licence de mes rêves, je ne suis pas un expert en licence. Mais je suis vraiment satisfait avec la GPLv3.
F : Cela fait maintenant plusieurs années que tu travailles sur QupZilla, peux-tu nous dire ce que cela t’a apporté, ce qui a marché et moins bien marché ?
David : Tu as raison, ça fait un bon moment que j’ai commencé à coder QupZilla. Même si il y a eu des périodes où je n’avais pas assez de temps pour développer, parfois à cause de l’école ou simplement par manque d’intérêt, je suis toujours revenu vers QupZilla. QupZilla m’a d’abord apporté beaucoup d’expérience, à la fois en codage, en utilisation de nouveaux outils et en gestion d’un projet qui au final n’est pas si petit. J’ai aussi rencontré beaucoup de nouvelles personnes. Pour résumer, j’ai savouré chaque instant. Bien sûr, il y a eu quelques erreurs, petites ou grandes. C’était essentiellement à cause d’un manque de connaissances et d’expérience dans les domaines concernés. Mais j’en ai toujours tiré une leçon. Il y a beaucoup de choses que je ferais différemment si je pouvais revenir en arrière dans le temps. Par exemple, j’aurais commencé à écrire des tests pour les fonctions de base dès le début du projet, pour éviter les régressions (c’est ce que je fais maintenant).
F : Aujourd’hui, QupZilla est un projet bien vivant, apprécié, et qui compte de nombreux contributeurs. Il est intégralement traduit dans plus de 20 langues. Imaginais-tu que ça puisse prendre une telle ampleur alors que le marché des navigateurs est extrêmement concurrentiel ? Comment a-t-il selon toi trouvé son public ?
David : Les navigateurs légers sont très populaires, principalement sur les machines Linux étant donné qu’il est possible de les faire fonctionner sur de très vieux matériels. Du coup, j’ai pensé qu’il y avait peut-être une place pour QupZilla. Maintenant, je peux dire que j’avais raison. Je pense également que « léger » ne veut pas forcément dire « manque de fonctionnalités ». C’est cette optique de développement que suit QupZilla.
F : Tu as choisi d’utiliser de nombreux outils facilitant le travail communautaire autour de ton projet : Qt comme base de travail, Github pour le code, récemment Transifex pour la traduction. Quels étaient tes critères ? Ont-ils été satisfaits ?
David : J’ai choisi Qt parce qu’il est disponible partout. Il convient parfaitement aux applications multi-plateformes. GitHub comme hébergeur pour le dépôt git est aussi le choix n°1. Ils offrent un bon plan pour les projets open source, et avec l’approche « codage social », il est plus facile de trouver de nouveaux contributeurs. Pour moi, GitHub est le meilleur choix pour n’importe quel projet open source.
J’ai récemment déplacé toutes mes traductions vers Transifex. Ça facilite la gestion, et c’est aussi un moyen de trouver de nouveaux traducteurs (ce qui s’est déjà confirmé). Je ne suis toutefois pas satisfait de la vitesse à laquelle ils implémentent les nouveaux éléments (essentiellement les nouvelles langues). Il faut plus d’un an et demi pour une demande de nouvelle langue. Du coup, il y a des soucis, notamment avec les traductions serbes.
F : Comment vois-tu la suite de QupZilla ? Tu as longtemps été le seul développeur. Tu as maintenant quelques contributions au niveau du code. Penses-tu à l’avenir te faire davantage épauler ?
David : Je ne pense pas que ça va changer tant que ça. Ce n’est pas vraiment facile d’attirer de nouveaux contributeurs. La situation actuelle me convient : je suis le développeur principal et d’autres personnes m’envoient des patch (correctifs et contributions) de temps en temps. Mais ça va peut-être changer si QupZilla a de la chance 🙂
F : Nous savons que les projets grandissants ont souvent besoin de trouver de nouveaux contributeurs pour avancer. Peut-être même qu’en ce moment, l’un de tes plus importants contributeurs est en train de lire cette interview. Peux-tu nous dire quels sont tes besoins humains sur le projet ?
David : Il n’y a jamais assez de contributeurs. Non seulement pour coder, mais aussi pour traduire, tester les nouvelles versions, etc. Mais ce qui aiderait vraiment QupZilla, mais aussi tous les autres projets basés sur QtWebKit serait d’insister d’avantage sur la partie en C++ de QtWebKit. Il y a en ce moment une nouvelle version pour Qt 4.8, QtWebKit 2.3. C’est une release vraiment bonne. Cependant, le développement est nécessaire pour garder le projet compétitif. Ce serait donc la meilleure façon d’aider QupZilla.
F : Tu fais maintenant partie de la grande famille du logiciel libre. Es-tu impliqué dans d’autres projets ? Souhaites-tu t’investir sur certains en particulier ?
David : J’ai envoyé de petits correctifs pour de nombreux autres projets, mais je n’ai jamais fait quelque chose de grand. Par exemple, je peux parler du lecteur de musique Tomahawk ou encore QtWebkit (sur lequel QupZilla est basé). J’aimerais contribuer d’avantage à QtWebKit, mais ce n’est pas facile de travailler sur un projet aussi important. J’aimerais aussi participer au Google Summer of Code project pendant les vacances d’été.
F : Tu es pour le moment étudiant, mais la vie professionnelle arrive à grand pas. Comment vois-tu ton avenir ?
David : Tu as raison, j’étudie maintenant à l’université. J’ai choisi une université ouverte sur l’open source, mes expériences ont donc déjà été utiles.
J’espère vraiment réussir à travailler dans une société basée sur des technologies open source. J’aime la communauté open source. Mais qui sait ce qui arrivera ? Quoi qu’il en soit, je n’ai pas l’intention d’arrêter de contribuer à des projets libres et open source.
F : Merci d’avoir pris le temps de répondre à nos questions. Nous te souhaitons une bonne continuation, en espérant voir Qupzilla grandir dans le bon sens.
David : Merci à vous aussi.
Bientôt la dernière séance… rejoignez-nous jeudi prochain sur le framapad de traduction
Traduction Framalang :
Frank Karlitschek
Frank Karlitschek est né en 1973 à Reutlingen, en Allemagne, et a commencé à écrire des logiciels à l’âge de 11 ans. Il a étudié l’informatique à l’université de Tübingen et s’est impliqué dans le logiciel libre et les technologies de l’internet dans le milieu des années 1990. En 2001, il a commencé à contribuer à KDE en lançant KDE-Look.org, un site communautaire d’œuvres qui deviendrait plus tard le réseau openDesktop.org. Frank a initié plusieurs projets et initiatives open source comme Social Desktop, Open Collaboration Services, Open-PC et ownCloud. En 2007, il a fondé une société appelée hive01 qui offrait des services et des produits autour de l’open source et des technologies de l’internet. Aujourd’hui, Frank est membre du conseil et vice-président de KDE e.V. et c’est un intervenant habitué des conférences internationales.
Il y a dix ans, j’ai sous-estimé la valeur d’un modèle économique. Logiciel libre et modèle économique ? Deux concepts incompatibles. Du moins, c’est ce que je pensais lorsque j’ai commencé à contribuer à KDE en 2001. Le logiciel libre, c’est pour le plaisir et pas pour l’argent. N’est-ce pas ? Les libristes veulent un monde où chacun peut écrire du logiciel et où les grandes entreprises, telles que Microsoft ou Google, sont superflues. Tout logiciel devrait être libre et tous ceux qui souhaitent développer du logiciel devraient en avoir la possibilité — même les développeurs du dimanche. Donc, gagner de l’argent importe peu. N’est-ce pas ? Aujourd’hui, j’ai une opinion différente. Les développeurs devraient parfois être rémunérés pour leurs efforts.
La plupart des développeurs de logiciels libres ont deux principales motivations pour travailler sur le logiciel libre. La première motivation est le facteur plaisir. C’est une expérience fantastique de travailler avec d’autres personnes très talentueuses du monde entier et de créer des technologies exceptionnelles. KDE, par exemple, est une des communautés les plus accueillantes que je connaisse. C’est tellement amusant de travailler avec des milliers de contributeurs du monde entier pour créer des logiciels qui seront utilisés par des millions de personnes. Pour faire simple, tout le monde est expert dans un ou plusieurs domaines et nous collaborons pour créer une vision partagée. Pour moi, c’est toujours génial de rencontrer d’autres contributeurs de KDE, d’échanger des idées ou de travailler sur nos logiciels ensemble, que nous nous rencontrions en ligne ou dans la vie réelle à une des nombreuses conférences ou événements. Et il s’agit aussi d’amitié. Au fil des années, je me suis fait beaucoup de bons amis au sein de KDE.
Mais les contributeurs de KDE ne sont pas uniquement motivés par le plaisir de rejoindre KDE. Il y a aussi l’idée que chacun de nous peut rendre le monde meilleur par nos contributions. Le logiciel libre est essentiel si vous vous souciez de l’accès à la technologie et à l’informatique pour les pays en voie de développement. Cela permet aux personnes pauvres d’avoir leur place dans l’ère de l’information sans acheter des licences coûteuses pour des logiciels propriétaires. Il est essentiel pour les personnes qui se soucient de la confidentialité et de la sécurité, parce que le logiciel libre est le seul et unique moyen de savoir exactement ce que votre ordinateur fait avec vos données privées. Le logiciel libre est important pour un écosystème informatique sain, parce qu’il permet à tout le monde de bâtir à partir du travail des autres et de vraiment innover. Sans le logiciel libre, il n’aurait pas été possible à Google ou Facebook de lancer leurs entreprises. Il n’est pas possible d’innover et de créer la nouvelle technologie marquante si vous dépendez de logiciels propriétaires et que vous n’avez pas accès à toutes les parties du logiciel.
Le logiciel libre est aussi indispensable pour l’éducation, parce que tout le monde peut voir les entrailles du logiciel et étudier son fonctionnement. C’est comme cela que le logiciel libre contribue à faire du monde un endroit meilleur et c’est pourquoi je participe à des projets de logiciel libre comme KDE.
Voilà les principales raisons pour lesquelles je veux que le logiciel libre et particulièrement le bureau libre soient largement répandus. Pour y parvenir, il nous faut bien plus de contributeurs qu’aujourd’hui. Par contributeurs, j’entends des gens qui écrivent les infrastructures centrales, le bureau et les grandes applications. Nous avons besoin de gens qui travaillent sur l’utilisabilité, sur les illustrations, sur la promotion et sur bien d’autres aspects importants. KDE est déjà une grande communauté avec des milliers de membres. Mais nous avons besoin de davantage de gens pour aider à rivaliser de manière sérieuse avec le logiciel propriétaire.
La communauté du logiciel libre est minuscule comparée au monde du logiciel propriétaire. D’un côté, ce n’est pas un problème car le modèle de développement logiciel distribué du monde du logiciel libre est bien plus performant que la façon d’écrire du logiciel à sources fermées. Un grand avantage est, par exemple, la possibilité de mieux réutiliser du code. Mais même avec ces avantages, nous avons besoin de bien plus de contributeurs qu’aujourd’hui si nous voulons réellement conquérir le marché de l’ordinateur de bureau et celui du mobile.
Nous avons aussi besoin d’entreprises pour nous aider à apporter notre travail sur le marché de masse. Bref, nous avons besoin d’un grand écosystème en forme permettant de vivre en travaillant sur le logiciel libre.
J’ai commencé à contribuer à KDE il y a plus de 10 ans et, depuis, j’ai vu d’innombrables volontaires très motivés et talentueux rejoindre KDE. C’est vraiment génial. Le problème, c’est que j’ai aussi vu beaucoup de contributeurs expérimentés abandonner KDE. C’est vraiment triste. Parfois, c’est simplement la marche normale du monde : les priorités changent et les gens se concentrent sur autre chose. Le problème, c’est que beaucoup abandonnent aussi à cause de l’argent. Il arrive un moment où les gens décrochent leur diplôme et veulent bouger de leur chambre d’étudiant.
Plus tard, ils veulent se marier et avoir des enfants. À partir de là, ils doivent trouver du travail. Il y a quelques entreprises dans l’écosystème de KDE qui proposent des postes liés à KDE. Mais cela ne représente qu’une petite part des emplois disponibles dans le secteur informatique. Du coup, beaucoup de membres chevronnés de KDE doivent travailler dans des entreprises où ils doivent utiliser des logiciels propriétaires qui n’ont rien à voir avec KDE ou le logiciel libre. Tôt ou tard, la plupart de ces développeurs abandonnent KDE. J’ai sous-estimé cette tendance il y a 10 ans, mais je pense que c’est un problème pour KDE sur le long terme, parce que nous perdons nos membres les plus expérimentés au profit des entreprises de logiciel propriétaire.
Dans le monde idéal que j’imagine, les gens peuvent payer leur loyer en travaillant sur les logiciels libres et ils peuvent le faire de telle sorte que ça n’entre pas en conflit avec nos valeurs. Ceux qui contribuent à KDE devraient avoir tout le temps qu’ils veulent pour contribuer à KDE et au monde libre en général. Ils devraient gagner de l’argent en aidant KDE. Leur passe-temps deviendrait leur travail. Cela permettrait à KDE de se développer de manière spectaculaire, parce que ce serait super de contribuer et de fournir en même temps de bonnes perspectives d’emploi stables et à long terme.
Du coup, quelles sont les solutions possibles ? Que pouvons-nous faire pour que ça arrive ? Y a-t-il des moyens pour que les développeurs paient leur loyer tout en travaillant sur du logiciel libre ? Je voudrais exposer ici quelques idées que j’ai rassemblées au cours de plusieurs discussions avec des contributeurs au logiciel libre. Certaines d’entre elles sont probablement polémiques, parce qu’elles introduisent des idées complètement neuves au sein du monde du logiciel libre. Mais je pense qu’il est essentiel pour nous de voir au-delà de notre monde actuel si nous voulons mener à bien notre mission.
Aujourd’hui, de plus en plus d’entreprises apprécient l’importance du logiciel libre et contribuent à des projets de logiciels libres, ou sortent même leurs propres projets de logiciel libre. C’est une chance pour les développeurs de logiciels libres. Nous devrions parler à davantage d’entreprises et les convaincre de s’associer au monde du logiciel libre.
Il devrait y avoir une manière facile pour les utilisateurs de donner de l’argent directement aux développeurs. Si un utilisateur d’une application populaire veut soutenir le développeur et promouvoir ses développements à venir pour cette application, donner de l’argent devrait ne tenir qu’à un clic de souris. Le système de dons peut être construit au sein même de l’application pour rendre le don d’argent aussi facile que possible.
L’idée derrière les primes est qu’un ou plusieurs utilisateurs d’une application peuvent payer pour le développement d’une fonctionnalité particulière. Un utilisateur peut soumettre la liste de ses demandes de nouvelles fonctionnalités sur un site web et annoncer combien il est prêt à payer pour cela. D’autres utilisateurs qui apprécient ces propositions pourraient ajouter de l’argent à la demande de fonctionnalité. Au bout d’un moment, le développeur commence à mettre au point la fonctionnalité et récupère l’argent des utilisateurs. Cette possibilité de primes n’est pas facile à introduire dans le processus. Des gens ont déjà essayé de mettre en place quelque chose de similaire, sans succès. Mais je pense que ça peut marcher si on s’y prend bien.
L’idée est que le développeur d’une application vende directement du support aux utilisateurs de l’application. Par exemple, les utilisateurs d’une application achètent du support pour, supposons, 5 € par mois et obtiennent le droit d’appeler directement le développeur à des plages horaires spécifiques de la journée, ils peuvent poser des questions à une adresse de courriel spécifique, ou le développeur peut même aider les utilisateurs par le biais d’un bureau à distance. J’ai bien conscience que beaucoup de développeurs n’aimeront pas l’idée que les utilisateurs puissent les appeler et leur poser des questions bizarres. Mais si cela signifie qu’ils gagnent suffisamment avec le système de support pour travailler à plein temps sur leurs applications, alors c’est certainement une bonne chose.
L’idée c’est que les utilisateurs finaux puissent devenir les soutiens d’une application. Le bouton « Soutenez ce projet » pourrait être intégré directement dans l’application. L’utilisateur devient alors un soutien par un paiement mensuel de, par exemple, 5 € qui vont directement au développeur. Tous les soutiens sont listés dans la fenêtre « À propos de l’application » avec leurs photos et leurs noms réels. Une fois par an, tous les soutiens sont aussi invités à une fête spéciale avec les développeurs. Il est possible qu’un développeur puisse devenir capable de travailler à plein temps sur une application, si assez d’utilisateurs deviennent des soutiens.
Certaines applications ont intégré des services web, et certains de ces services Web exécutent des programmes affiliés. Par exemple, un lecteur multimédia peut être intégré à la boutique en ligne de MP3 Amazon ou un lecteur PDF peut être intégré à une boutique en ligne de livres numériques. À chaque fois qu’un utilisateur achète du contenu via cette application, le développeur obtient un peu d’argent.
Beaucoup de gens ne savent pas qu’il est possible de vendre des binaires de logiciels libres. La licence GPL exige simplement de fournir également le code source. Il est donc parfaitement légal de vendre des binaires bien empaquetés de notre logiciel. En réalité, les sociétés comme Red Hat et Novell vendent déjà notre logiciel dans leurs distributions commerciales. Mais les développeurs n’en bénéficient pas directement. Tous les revenus vont aux sociétés et rien ne va aux développeurs. On devrait donc permettre aux développeurs de logiciels libres de vendre à l’utilisateur final des applications bien empaquetées, optimisées et testées. Cela pourrait particulièrement bien fonctionner pour Mac ou Windows. Je suis sûr qu’un tas de gens seraient prêts à payer quelque chose pour des binaires d’Amarok pour Windows ou de digiKam pour Mac, si tout l’argent allait directement au développeur.
La plupart de ces idées ne sont pas faciles à mettre en œuvre. Cela nécessite de modifier notre logiciel, nos méthodes de travail et même nos utilisateurs, qu’il faut encourager à montrer qu’ils apprécient le logiciel que nous créons, en nous aidant à financer son développement.
Cependant, les bénéfices potentiels sont énormes. Si nous pouvons assurer des sources de revenus pour notre logiciel, nous pouvons conserver nos meilleurs contributeurs et peut-être en attirer de nouveaux. Nos utilisateurs auront une meilleure expérience avec un développement logiciel plus rapide, la possibilité d’influencer directement le développement par le biais de primes et un meilleur support.
Le logiciel libre n’est plus seulement un loisir sur votre temps libre. Il est temps d’en faire un business.
