Construire des communs/Partage

Sommaire

Introduction

Définir quels sont les "communs" proches ou similaires ? Si ils ont été contactés pour essayer de mutualiser avec eux ? Comment le "commun" est travaillé pour favoriser sa réplication, sa diffusion ?

Description -> Le projet diffuse ses recettes de fonctionnement pour facilement les reproduire. Il est pensé de manière "modulaire" (separation of concerns") de manière à s'appuyer lui-même sur d'autres "communs" ou produire de multiples nouveaux communs appropriables plutôt qu'un seul qui ne pourra pas être réutilisable. Il est pensé pour mutualiser avec d'autres initiatives proches dans le but d'éviter des démarches de compétition et afin de mettre les forces autour d'un même projet.

Intérêt -> C'est la capacité à unir des personnes autour d'un enjeu qui va permettre de le développer rapidement. Aussi, documenter son fonctionnement permet la réplication du projet par d'autres et facilite l'appropriation du concept par tous. Réussir à mutualiser est une des clés du développement des communs.

Exemples -> Partager ses recettes ou "codes-sources" grâce au site http://movilab.org par exemple. Rejoindre des groupes de travail thématiques. Par exemple, Disco Soupe a mis en ligne toutes les informations pour facilement démarrer une discosoupe sur son territoire. Dès qu'une initiative démarre, un travail de veille est à réaliser pour se mettre en lien avec des personnes qui ont un projet similaire, ou rejoindre un projet déjà existant. Il y a par exemple une mutualisation très importante autour de 'encyclopédie wikipédia : Plutôt que des centaines d'encyclopédies concurrentes, le projet a réussi à fédérer un grand nombre d'acteurs. Des initiatives similaires décident parfois de se regrouper pour unir leurs forces.

Repérer les communs proches

Repérage de biens communs existants :

http://encommuns.org
http://www.bollier.org/commons-resources/commons-projects
http://p2pfoundation.org
Faire des recherche de communautés
- Faire des recherches dans les communautés Facebook, yahoo groups, google groups ou sur des moteurs de recherche

Il est nécessaire d'avoir un espace où lister tous les usages (ou raison d'être) souhaités et y mettre en face les initiatives existantes ou celles à venir. Cela permet de sélectionner ensemble l'initiative en "commun libre" sur laquelle se baser collectivement et se mettre d'accord pour la construire ensemble.

Exemples de ce type d'organisation par usage/raison d'être :

le réseau "Tilios" a sélectionné les outils sur lesquels mutualiser collectivement pour développer un système d'information des tiers lieux : http://movilab.org/index.php?title=%C3%89valuation_de_la_mise_en_place_d%27une_bo%C3%AEte_%C3%A0_outils_pour_les_Tiers_Lieux

C'est l'un des enjeux sur le site http://encommuns.org de présenter les communs de cette manière, par usager / raison d'être

Organiser la mutualisation

Des méthodologies travail doivent être mise en place pour favoriser la mutualisation

Un exemple intéressant est celui de snowdrift qui avant de démarrer a fait un benchmarking très complet et public de l'existant : https://wiki.snowdrift.coop/market-research/other-crowdfunding

Permettre l'accès aux ressources

Le projet est pensé de manière "modulaire" (separation of concerns") de manière à s'appuyer lui-même sur d'autres "communs" ou produire de multiples nouveaux communs appropriables plutôt qu'un seul qui ne pourra pas être réutilisable. Chaque ressource doit être pensée comme un commun et donc être accessible, sous des licences juridiques ouvertes, etc...

Partager son fonctionnement et diffuser cette information.

Faciliter la diffusion à travers des recettes

Une initiative est d'autant plus valorisée qu'elle décrit son fonctionnement, et arrive à décrire un mode d'emploi pour le copier (recette). L'initiative sera plus riche si elle arrive à se connecter à des communautés apprenantes pour échanger, continuer à s'inspirer et inspirer les autres.

Les recettes permettent d'essaimer et de copier les bonnes idées beaucoup plus facilement. Elles évitent de reproduire les mêmes erreurs ou de perdre du temps sur une solution déjà trouvée.

Astuces pour une bonne recette

Privilégier le concret, les exemples.

Ne garder que ce qui est réutilisable comme par exemple un mail d'annonce, un formulaire, ...

Identifier les éléments de contexte qui ont permis la réussite de cette initiative, et prévenir des éventuels freins.

Quelques exemples de recettes :

Le manuel du jardin partagé
https://www.colibris-lemouvement.org/agir/fiches-pratiques/
http://movilab.org
http://movilab.org/index.php?title=Page_mod%C3%A8le_d%27un_code_source_d%27innovation_sociale
http://wiki.lacoroutine.org/contribution:coucourses

Une méthode de construction de recettes - http://movilab.org/index.php?title=La_m%C3%A9thodologie_Movilab

Quels outils pour décrire une recette

Mediawiki (utilisé par Movilab). Possibilité de démarrer un wiki sur http://referata.com/ et http://www.shoutwiki.com/ ou https://meta.miraheze.org/wiki/Miraheze
Dokuwiki

Rejoindre des groupes de travail thématiques.

Quelques exemples de réseaux de partage :

http://coop-group.org/tiers-lieux/wakka.php?wiki=PagePrincipale

Penser les choix pour une mutualisation avec d'autres initiatives (logique décentralisée). Faire ces choix pour que le projet puisse être un véritable "commun libre", durable sur le long terme

Penser le développement sous forme de composants simples et ouverts qui s'occupent d'une préoccupation particulière

Video

Une introduction à l'intérêt d'utiliser les approches décentralisées : http://vimeo.com/98484587

Explications

Il y a un enjeu à penser les communs selon chaque raison d'être (ou usage auquel le commun répond), en séparant un commun et de plus petits communs afin que chacun puisse être indépendant et ainsi être utilisable par d'autres, mais aussi facilement appropriable par des contributeurs. C'est ce que l'on appelle la séparation des préoccupations

Il faut garder en tête l’enjeu de développer les solutions sous forme de petits « composants » simples (ou services) qui s'occupent d'une préoccupation et que l'on peut agréger simplement (Components on the shelf -> Composants sur étagère)

Gabriel Plassat dit : "En ouvrant et en fonctionnant par sous-ensemble, les interfaces, les connexions deviennent stratégiques pour permettre des développements séparés. Ces contraintes conduisent à développer des interfaces et connexions facilement “standardisables”.

Si chaque projet pense son développement comme une agrégation de composants qui peuvent se parler (par exemple, une base de donnée commune autour des métadonnées de films), il devient alors possible de combiner les composants pour créer des applications complexes. En pensant ces composants de manière ouverte, cela permet à un nouveau projet d’accéder à ces composants plutôt que d’avoir à tout reconstruire. Si une réciprocité est mise en place, un acteur qui utilise un composant va le renforcer de plus en plus (financièrement, techniquement, etc.) et cela évitera la duplication du composant (par exemple, avoir une base de donnée commune du covoiturage plutôt que des centaines de bases concurrentes développées et enfermées par chaque acteur). Pour cela, en théorie, chaque élément doit être designé dans l’esprit KISS (Keep It Simple and Stupid) pour permettre à des cas spécifiques de pouvoir utiliser ces composants. Un élément doit fournir le strict minimum pour être nécessaire à son utilisation. Si nous souhaitons des améliorations du composant, il faut que ce soit un mécanisme d’extension, ou alors créer un élement complémentaire pour s’occuper de la préocupation particulière.

Pour en savoir plus, une vidéo de Guillaume Libersat qui a conseillé le Fresnoy sur ses développement. Il y parle de l’enjeu de créer des éléments qui puissent s’agréger plutôt que de s’attaquer frontalement au développement d’une plateforme qui ferait tout : https://vimeo.com/98484587

Techniquement, comme l'explique la plateforme "Assemblée virtuelle" utilise les « Linked Datas » qui sont un ensemble de protocoles et de langages en cours d’élaboration par le W3C, qui permettent de créer des liens directement entre les données de la même manière que le web actuel en crée entre les pages. Ces liens véhiculent du sens. Ils permettent de qualifier la nature des relations entre les données. Les linked datas sont à la base du « web sémantique » qui constitue repense notre manière d’organiser l’information. Les données sont identifiées à l’aide d’un protocole (Web Id) et non-équivoques dans la mesure où l’on peut les contextualiser en référence à des bases de données structurées comme Dbpedia. Un autre protocole (Web Acces Control) permet de définir très précisément le périmètre et les modalités de partage de vos données. Elles sont en sécurité, vous en avez le contrôle.

Avec ces solutions, il sera possible de faire de l’agrégation de données de plusieurs serveurs de données et donc il sera possible d'héberger les données à plusieurs endroits. Il sera possible d’avoir “n” services dans chaque serveur qui chacun occupera d’une préoccupation (separation of concerns). Chacun peut alors s’occuper d’un aspect (ex : Brique de paiement, de médias, etc…). Le développement peut ainsi être parallélisé.

Plus d'informations : Logique de développement par API

En savoir plus sur le Linkedata permettant la décentralisation :

What is Linked Data https://www.youtube.com/watch?v=4x_xzT5eF5Q
What is Json-LD : https://www.youtube.com/watch?v=vioCbTo3C-4
Signatures : https://www.youtube.com/watch?v=QdUZaYeQblY
Web Credentials https://www.youtube.com/watch?v=eWtOg3vSzxI
La reco W3C : https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html jsonLD.org : http://json-ld.org/ http://json-ld.org/learn.html
diigo sur le sujet https://www.diigo.com/user/oceatoon/linkeddata