PROJET AUTOBLOG


Philippe Scoffoni

source: Philippe Scoffoni

⇐ retour index

Liberapay : un nouvel outil de financement participatif

dimanche 10 avril 2016 à 10:58

prendre donner contributionVous vous souvenez peut-être de cet article sur le service de financement participatif Gratipay. De quoi s’agissait-il ?

Le principe est assez simple. Tout d’abord, il vise à établir une relation de financement « durable ». C’est un point qui est intéressant, car il permet à un auteur ou un projet de bénéficier d’un revenu à peu près stable dans le temps. Les participants s’engagent à verser une somme donnée toutes les semaines. Pas de dons ponctuels avec Gratipay.

Mais ce service avait comme principal défaut d’être hébergé par une entité nord-américaine, donc peu adaptée à une utilisation par des Européens. Il était notamment impossible de récupérer les fonds collectés.

L’un des contributeurs du projet, Changaco a décidé de créer une version européenne de ce service sous le nom de Liberapay

Principe de fonctionnement de Liberapay

Il est simple. Vous vous inscrivez pour créer un compte et ajouter à votre portefeuille un certain montant. À ce stade, il y a un prélèvement effectué sur le montant destiné à couvrir uniquement les frais bancaires.

C’est une première différence notable par rapport aux plateformes comme Flattr. C’est aussi une des particularités intéressantes de Gratipay qui a été ici reprise. Liberapay ne se rémunère pas sur les sommes versées. Il incombe en effet aux utilisateurs de la plateforme de financer son fonctionnement. C’est ce qui m’avait séduit dans Gratipay.

J’ai créé un compte sur Liberapay, car je suis d’une indécrottable curiosité. J’ai approvisionné mon compte et décidé d’allouer un euro par semaine à l’équipe Liberapay. Gageons que tous les utilisateurs du service auront le même comportement afin d’éviter de scier la branche sur laquelle ils sont assis.

Les services gratuits s’appuyant sur le seul bénévolat et/ou de rares mécènes courent le risque de disparaître. Regardons ce qui se passe pour l’hébergeur associatif Olympe qui lance une campagne de financement pour pouvoir continuer d’exister. On peut espérer qu’avec 92 000 utilisateurs, les 40 000 € attendus puissent être trouvés. A moins de 50 centimes par utilisateurs cela semblerait une évidence. Et pourtant rien n’est moins sur. Le résultat de cette campagne sera intéressant à suivre de ce point de vue.

Concernant les sommes versées sur Liberapay, je préfère utiliser le terme contribution que don qui me semble porteur d’une sémantique plus proche de la finalité de ce service.

Les contributions peuvent s’effectuer au profit de personnes ou d’équipes. Dans ce dernier cas, ce sont les membres de l’équipe qui définissent les règles de répartition des sommes perçues. Bien entendu, les sommes reçues doivent être déclarées à l’administration fiscale selon votre statut.

De ce point de vue, un statut d’autoentrepreneur semble être le minimum requis, mais c’est à confirmer. Vous pouvez vous reporter à cet article sur le forum de Ulule ou encore à cet article concernant la déclaration de revenus perçus en Bitcoin que m’a fait passé Changaco.

Il est également possible de créer des communautés, mais leur usage est essentiellement à but « social », car elles ne peuvent pas recevoir de contributions.

Liberapay est donc particulièrement bien adapté au financement de créations sous licence libre dont des logiciels bien sûr. C’était un des outils manquants. Il en reste bien d’autres à mettre en place, dont un fond de dotation, ouvrant la porte aux mécanismes du mécénat financier et de compétences par exemple. À la clé des réductions fiscales pour les donateurs. Je ne parle pas de changer également la paradigme monétaire dans lequel nous vivons et qui réglerait bien des soucis.

À ceux qui objecteraient que l’absence de possibilité de faire un don ponctuel est un manque, je répondrais qu’il leur suffit d’approvisionner leur portefeuille une fois, de décider du montant hebdomadaire et de stopper par la suite le versement. Un peu contraignant, mais ça doit marcher.

Mais qui est Liberapay ?

Liberapay est porté par une association loi 1901 du même nom dont les statuts sont disponibles en ligne. A la question, mais où est l’argent ? La réponse est simple, car l’association fait appel aux services de Mangopay. Liberapay utilise l’interface de programmation de ce service pour gérer les transactions et les portefeuilles des utilisateurs. C’est également Mangopay qui s’occupe des démarches administratives
auprès le l’ACPR. Parmi les utilisateurs de ce service se retrouvent des plateformes comme Ulule.

Voici donc un outil d’un nouveau genre dans la planète des services de financement participatif qui vient combler un manque. Tout est dans les mains d’utilisateurs et leur volonté de jouer le jeu de la contribution.

Vous pouvez donc dès à présent vous inscrire sur Liberapay et financer, si vous le souhaitez, du temps pour que je puisse plus régulièrement écrire sur ce site 😉 Le bouton est à quelques pixels plus bas.

Chiche ?


Réagir à cet article

Article original écrit par Philippe Scoffoni le 10/04/2016. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

.

Interview sur Nipsource

jeudi 7 avril 2016 à 23:09

microphone-1280Article flash pour vous indiquer que vous pouvez écouter une interview que j’ai donnée à l’équipe de NipSource : Cyril et Julien. La discussion tourne autour de mes activités professionnelles et des services à base de logiciels libres que je propose. On y parle aussi à nouveau de l’affaire des CHATONS, mais aussi du modèle économique du logiciel libre et de son avenir. Il y est également question des critères pour choisir un logiciel libre.

Bref, si vous voulez en savoir un peu plus sur ma vie de chef d’entreprise du monde du logiciel libre suivez ce lien pour retrouver cette petite heure d’échange très sympathique.

Merci encore à Cyril et Julien de m’avoir invité 🙂 !


Réagir à cet article

Article original écrit par Philippe Scoffoni le 07/04/2016. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

.

Interview sur Nipsource

jeudi 7 avril 2016 à 23:09

microphone-1280Article flash pour vous indiquer que vous pouvez écouter une interview que j’ai donnée à l’équipe de NipSource : Cyril et Julien. La discussion tourne autour de mes activités professionnelles et des services à base de logiciels libres que je propose. On y parle aussi à nouveau de l’affaire des CHATONS, mais aussi du modèle économique du logiciel libre et de son avenir. Il y est également question des critères pour choisir un logiciel libre.

Bref, si vous voulez en savoir un peu plus sur ma vie de chef d’entreprise du monde du logiciel libre suivez ce lien pour retrouver cette petite heure d’échange très sympathique.

Merci encore à Cyril et Julien de m’avoir invité :-) !


Réagir à cet article

Article original écrit par Philippe Scoffoni le 07/04/2016. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

.

Owncloud : optimiser la vitesse de transfert des gros fichiers

dimanche 3 avril 2016 à 22:05

fuploadJe commence à avoir un peu de recul sur la mise en pratique d’Owncloud dans divers contextes d’utilisation professionnelle. Le dernier en date m’a permis de mettre le doigt sur un « détail » important à connaître.

Le cas en question consistait à synchroniser les fichiers stockés sur un serveur motorisé par Openmediavault vers une instance Owncloud afin de permettre à mon client de mettre à disposition des fichiers, mais aussi de disposer d’une sauvegarde externalisée.

J’ai utilisé la version « ligne de commande » du client de synchronisation d’Owncloud afin de lancer les synchronisations directement depuis le serveur. Openmediavault utilise une version 7 de Debian. J’ai fait l’installation du client Owncloud de façon assez classique en ajoutant les dépôts pour Debian 7. À l’installation on récupère pas mal de dépendances, mais rien de catastrophique. L’utilisation de la commande owncloudcmd est documentée sur le site du projet.

C’est environ 700 Go de données qu’il s’agissait de synchroniser. Ayant accès à une fibre de 300 Mbps, je n’étais pas trop inquiet. J’avais estimé à environ 6/7 heures la durée de la synchronisation initiale.

Lancé durant un week-end afin de disposer de toute la bande passante, je constate au bout de 10 heures que le transfert n’est pas terminé. Seuls 450 Go ont été transférés. Je laisse passer encore quelques heures pour constater que la synchronisation n’a avancé que de quelques dizaines de Go. Fatalement, coup de stress, je commence à investiguer.

Premier constat, la machine virtuelle où est installé Owncloud mouline furieusement. Le serveur web et la base de données tournent à plein régime. J’augmente les ressources allouées à la machine virtuelle qui bien évidemment ne fait que mouliner davantage. Le plus suspect est qu’il n’y a que très peu de trafic réseau.

Mes investigations se portent sur le client de synchronisation et son historique. Je constate alors que ce dernier envoi des rafales de requêtes pour certains fichiers. Il s’agit de gros fichiers. En l’occurrence des rushs de vidéo. Il y a là des fichiers qui font jusqu’à 14 Go pièces. De belles bêtes 🙂 !

En creusant un peu, je découvre le fonctionnement « intime » du client de synchronisation. Lorsque les fichiers sont gros (disons plus de 5 à 10 Mo), le client les saucissonne pour les envoyer dans un répertoire de cache sur le serveur. Ces petits fichiers portent le doux nom de « chunk ». Par défaut, leur taille est de 5 Mo. L’objectif est de permettre une reprise en cas de coupure du transfert d’un gros fichier. Une fois tous transférés, les fichiers sont réassemblés sur le serveur pour constituer le fichier final. Sur le serveur Owncloud, les fichiers partiellement transférés portent une extension .part et grossissent par à-coups.

Mais, lorsque l’on dispose d’une liaison haut débit, cette taille de fichier n’est plus adaptée. À 5 Mo, le transfert des données prend environ 0,20 seconde. De fait, le client de synchronisation passe plus de temps à établir la connexion avec le serveur Owncloud, lui donner quelques informations qu’il enregistre dans la base de données, qu’à faire le transfert. Résultat le transfert devient épouvantablement lent au regard des possibilités de la liaison. C’est un souci que j’ai retrouvé sur les forums d’Owncloud à plusieurs reprises.

La solution consiste à modifier la taille par défaut du chunk pour privilégier le transfert de données par rapport au dialogue entre le client et le serveur.

Pour cela, vous devez sous GNU/Linux positionner des variables d’environnement. J’ai fait cela dans le fichier .profile de l’utilisateur qui lance la commande de synchronisation.

export OWNCLOUD_CHUNK_SIZE=5242880
export OWNCLOUD_MAX_PARALLEL=3

La première variable vous l’aurez compris permet de définir (en octets) la taille du chunk. Le second définit le nombre de connexions parallèles maximum pour le transfert de fichiers. La valeur par défaut est de 3.

Dans mon cas, j’ai donc poussé la taille du chunk à 100 Mo et monté la valeur de la seconde à 5. Résultat, 3 heures plus tard le transfert était terminé. La charge du serveur est restée relativement faible.

À noter que j’ai quand même dû faire le ménage dans le dossier cache sur le serveur. En changeant la valeur, visiblement le client à recommencé les transferts en cours. Il restait donc plein de fichiers de 5 Mo que j’ai supprimé manuellement.

Ces variables doivent fonctionner aussi pour le client de synchronisation traditionnel, bien que je n’en ai pas fait le test. De même, il doit être possible sous Windows de spécifier ces variables d’environnement, là encore je vous laisse vous dépatouiller avec ce dernier 🙂


Réagir à cet article

Article original écrit par Philippe Scoffoni le 03/04/2016. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

.

Owncloud : optimiser la vitesse de transfert des gros fichiers

dimanche 3 avril 2016 à 22:05

fuploadJe commence à avoir un peu de recul sur la mise en pratique d’Owncloud dans divers contextes d’utilisation professionnelle. Le dernier en date m’a permis de mettre le doigt sur un « détail » important à connaître.

Le cas en question consistait à synchroniser les fichiers stockés sur un serveur motorisé par Openmediavault vers une instance Owncloud afin de permettre à mon client de mettre à disposition des fichiers, mais aussi de disposer d’une sauvegarde externalisée.

J’ai utilisé la version « ligne de commande » du client de synchronisation d’Owncloud afin de lancer les synchronisations directement depuis le serveur. Openmediavault utilise une version 7 de Debian. J’ai fait l’installation du client Owncloud de façon assez classique en ajoutant les dépôts pour Debian 7. À l’installation on récupère pas mal de dépendances, mais rien de catastrophique. L’utilisation de la commande owncloudcmd est documentée sur le site du projet.

C’est environ 700 Go de données qu’il s’agissait de synchroniser. Ayant accès à une fibre de 300 Mbps, je n’étais pas trop inquiet. J’avais estimé à environ 6/7 heures la durée de la synchronisation initiale.

Lancé durant un week-end afin de disposer de toute la bande passante, je constate au bout de 10 heures que le transfert n’est pas terminé. Seuls 450 Go ont été transférés. Je laisse passer encore quelques heures pour constater que la synchronisation n’a avancé que de quelques dizaines de Go. Fatalement, coup de stress, je commence à investiguer.

Premier constat, la machine virtuelle où est installé Owncloud mouline furieusement. Le serveur web et la base de données tournent à plein régime. J’augmente les ressources allouées à la machine virtuelle qui bien évidemment ne fait que mouliner davantage. Le plus suspect est qu’il n’y a que très peu de trafic réseau.

Mes investigations se portent sur le client de synchronisation et son historique. Je constate alors que ce dernier envoi des rafales de requêtes pour certains fichiers. Il s’agit de gros fichiers. En l’occurrence des rushs de vidéo. Il y a là des fichiers qui font jusqu’à 14 Go pièces. De belles bêtes :-) !

En creusant un peu, je découvre le fonctionnement « intime » du client de synchronisation. Lorsque les fichiers sont gros (disons plus de 5 à 10 Mo), le client les saucissonne pour les envoyer dans un répertoire de cache sur le serveur. Ces petits fichiers portent le doux nom de « chunk ». Par défaut, leur taille est de 5 Mo. L’objectif est de permettre une reprise en cas de coupure du transfert d’un gros fichier. Une fois tous transférés, les fichiers sont réassemblés sur le serveur pour constituer le fichier final. Sur le serveur Owncloud, les fichiers partiellement transférés portent une extension .part et grossissent par à-coups.

Mais, lorsque l’on dispose d’une liaison haut débit, cette taille de fichier n’est plus adaptée. À 5 Mo, le transfert des données prend environ 0,20 seconde. De fait, le client de synchronisation passe plus de temps à établir la connexion avec le serveur Owncloud, lui donner quelques informations qu’il enregistre dans la base de données, qu’à faire le transfert. Résultat le transfert devient épouvantablement lent au regard des possibilités de la liaison. C’est un souci que j’ai retrouvé sur les forums d’Owncloud à plusieurs reprises.

La solution consiste à modifier la taille par défaut du chunk pour privilégier le transfert de données par rapport au dialogue entre le client et le serveur.

Pour cela, vous devez sous GNU/Linux positionner des variables d’environnement. J’ai fait cela dans le fichier .profile de l’utilisateur qui lance la commande de synchronisation.

export OWNCLOUD_CHUNK_SIZE=5242880
export OWNCLOUD_MAX_PARALLEL=3

La première variable vous l’aurez compris permet de définir (en octets) la taille du chunk. Le second définit le nombre de connexions parallèles maximum pour le transfert de fichiers. La valeur par défaut est de 3.

Dans mon cas, j’ai donc poussé la taille du chunk à 100 Mo et monté la valeur de la seconde à 5. Résultat, 3 heures plus tard le transfert était terminé. La charge du serveur est restée relativement faible.

À noter que j’ai quand même dû faire le ménage dans le dossier cache sur le serveur. En changeant la valeur, visiblement le client à recommencé les transferts en cours. Il restait donc plein de fichiers de 5 Mo que j’ai supprimé manuellement.

Ces variables doivent fonctionner aussi pour le client de synchronisation traditionnel, bien que je n’en ai pas fait le test. De même, il doit être possible sous Windows de spécifier ces variables d’environnement, là encore je vous laisse vous dépatouiller avec ce dernier :-)


Réagir à cet article

Article original écrit par Philippe Scoffoni le 03/04/2016. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

.