Inter-site functionality
The vision: International organizations can implement networks of sites that freely and securely share selected data (user accounts, categorization, content). Networks of drupal sites can discover each other through shared features and focuses, connect in webs of sites, and pool knowledge and contacts to weave isolated initiatives into strengthened movements for change.
If Drupal's fame for enabling collaborative communities was built largely on a single-site model, there's a good case to be made for the claim that it's connections among and between sites that will be the next big step.
In this session we will map out concrete next steps in extending the ability of discrete Drupal sites to link up and share information with each other - pooling user accounts, nodes, taxonomies.
Of course, we already have some good beginnings for inter-site pooling of information: syndication, blog-based protocols, the rudiments of remote authentication and networks of sites (drupal.module), and even Drupal-specific XML exchanges.
But there's a distance to go. Inter-site collaboration could include:
- Tightly integrated content categorization, lending itself to, e.g., organization/network-wide syndication feeds by category.
- Single user identity across organization/network.
- Pooled content/collective databases, reducing duplication.
This is really significant
This may be more important and significant than what most people are likely comprehend at first glance. This will allow groups to share resources while maintaining autonomy and control of their web sites/organizations. It can also be used to create gestalt mega-sites where the whole is greater than the sum of its parts. Sort of a Lego or Tinker-Toy way of combining web sites into a larger whole.
An example of how this might be put to use: In Portland, Oregon, we have neighborhood associations, citizen activists who pool resources and work together to improve their neighborhoods. Most neighborhood associations are members of coalitions covering a larger geographical region. In turn, there are about seven or eight coalitions in the city as a whole. But Portland has many smaller neighboring cities, each with their own groups. Sometimes these neighboring groups work together on common interests. And sometimes there are committees which span organizations (at various levels). At each level, there is a need to communicate and coordinate with peers, and those higher and lower in the broad organizational structure.
Each neighborhood association would like to have their own site, as well as each coalition and many of the standing committees. Clearly there is a benefit is sharing resources as the boundaries between each of these groups is fuzzy at best.
The same model might apply to businesses and a local business alliance or chamber of commerce, etc.
I have two web sites, one related to hiking and another related to urban/suburban walking. While related, they are distinct from one another. Would love to be able to share resources between the two. So the list of potential applications of this just keeps going on and on. There are so many. I suspect this feature, if done properly, will link organizations and web sites in very organic ways. It may be much bigger than most will suspect. It could make Drupal the 800 pound gorilla on top of the CMS hill.
It is important to be able to fine-tune relationships. Say you have three groups: A, B & C. B might want to share members with both A & C, but A may only want to share with B (but not C), and C only with B (but not A). Also, reciprocal relationships should not be assumed. It should be possible to share only one way. For example A might want to share its members with B, while B doesn’t want to share its members with A. Of course A has to consent to sharing its resources to B. If you can’t specify whom you’re sharing your resources with, and which resources, this won’t be successful. This, of course, is the problem with the current Drupal sharing scheme.
I can envision that some of these sites will run on a shared server, and some might not. In the case of a shared server, there might be things which can be done to optimize the pooling of resources, so some thought should go into that.
But the existing sharing model of Drupal just doesn’t work. Organizations might want to share resources, such as members, but not with unrelated organizations who merely happen to be using Drupal.
I’m really happy to see this idea take root. I hope it becomes part of 4.8. Can’t happen soon enough!
I agree
Yep, I agree! Inter-site functionality is a big one for me. I have been running a networking website for the refugee sector in Brisbane (I'll migrate it to Drupal one day) and I can see huge potential for such a site for the whole community sector in Brisbane. But, given the huge numbers of organisations a centralised site would be hard to achieve - particularly ownership and control issues. But if organisations could have their own site and control what info is shared and how, I could see and organic growth of shared, widely accessible information. Wonderful!
Thanks for the great work on this.
Warm regards,
Chris
www.barc.org.au
Many Sites, Loosely Joined (he Problem of Many-in-One)
Yes! Pursuing this approach would make Drupal the clear leader in solving the problem of linking related sites into a coherent meta-structure.
This is one of those problems where the need for the solution will not be widely understood until the solution is built, mainly because most people suffering from the problem do not realize that it is a solvable issue. They certainly realize that maintaining multiple inter-related web sites is painful, but do not understand how widely the pain is shared, in slightly different forms, and how a solution could be engineered at the CMS/CMF level.
I consider it a problem pattern: “The Problem of Many-in-One”.
I've blogged it in the generic at http://danbashaw.com/sand/?p=8, and workshopped on a specific instance of it at http://www.webofchange.com/council-of-canadians.
The Problem of Many-in-One – Excerpts:
The “Problem of Many-in-One” is a shorthand term for the commonly encountered challenge of creating a web presence for an umbrella organization that is composed of autonomous chapters. A typical solution is sketched below, with an organizational web site exchanging content with autonomous chapter web sites…
The Problem of Many-in-One is a recurring ‘problem pattern’ that many web developers have confronted and solved for individual clients, but that currently lacks a robust solution at the content management (CMS) level: Instead we reinvent a solution each time the problem arises.
I think that instead of continuing to cobble together ad hoc solutions, we can tackle the problem head-on, at the CMS level…
Full Text: http://danbashaw.com/sand/?p=8
The Problem of Many-in-One/Council of Canadians Peer-to-Peer Session
During the Peer-to-peer breakout sessions … a group of us created an ad hoc session focusing on the web site design and development issues faced by the Council of Canadians, a progressive national organization with 70 local chapters scattered across the country.
The Council’s challenge is to create a unified yet flexible web presence for the largely autonomous chapters, while still keeping control of branding and much of the messaging…
For many of the session participants, the Council’s problem was a familiar one, but also one for which no out-of-the-box solution was available: Many of us had developed specific solutions that addressed the problem for a specific client, based on Drupal or other CMS technologies, but all recognized that the problem was one that continues to recur, and that is not addressed by the rudimentary multi-site capabilities of the various open source solutions available…
Full Text: http://www.webofchange.com/council-of-canadians
I see the “Many Sites, Loosely Joined” (Inter-site functionality) problem as an even more generalized framing than the “Problem of many-in-One”. A robust Drupal solution would save gazillions of person-hours, and, as a minor side effect, ensure Drupal world dominance.