Mutualiser, partager ses ressources, documenter pour répliquer ou diffuser

From P2P Foundation
Jump to navigation Jump to search

Quels sont les "communs" proches ou similaires ? Ont il été approchés pour 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 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 l'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

Il est nécessaire d'avoir un espace où lister tous les usages 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'usage :


C'est l'un des enjeux sur le site encommuns.org de présenter les communs de cette manière.


Un prototype d'outil est visible ici : unisson.co

Organiser la mutualisation

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

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éutilisables 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 :


Une méthode de construction de recettes


Quels outils pour décrire une recette

Rejoindre des groupes de travail thématiques.

Quelques exemples de réseaux de partage :


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 des communs

Il y a un enjeu à penser les communs selon un usage précis, 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

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”.


Penser le développement informatique en logique décentralisée.

Vidéo

Une introduction à l'intérêt d'utiliser les approches décentralisées

Explications

Si chaque projet pense son développement comme une aggrégation de services, nous allons avoir accès à des services qui existent ailleurs et l’on pourra faire notre marché pour agréger notre information (Components on the shelf). Cela va renforcer de plus en plus le niveau technique des services et évitera la duplication de code. Pa référencement croisé, il sera possible de combiner les services et créer des applications à partir de ces services.

Théoriquement, chaque service doit être designé dans l’esprit KISS (Keep It Simple and Stupid) pour éviter du bruit sur des cas spécifiques. Un service doit fournir le strict minimum pour être nécessaire à son utilisation. Si l’on veut ajouter des améliorations au service, il faut que ce soit un mécanisme d’extension (c’est un exemple visible sur les cartographie : features sur geojson), ou alors créer un service complémentaire pour s’occuper de la préocupation particulière.

Techniquement, comme l'explique la plateforme "Assemblée virtuelle" cela utilisera 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é.

Pour l’instant, dans Unisson, un dataserver a été crée qui est un incubateur de services “rest”, tous sur le même serveur et dans le même dépôt. Avec plusieurs premiers services, comme un module de cartographie, de kanban, de gestion de média...

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

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

Retrieved from "https://wiki.p2pfoundation.net/index.php?title=Mutualiser,_partager_ses_ressources,_documenter_pour_répliquer_ou_diffuser&oldid=98423"