I'm currently writing a Master's thesis with a title "Streamlining the Creation of Social Networking Sites with Drupal". In this work I have done some background research on social media and social networking sites. There is some basic functionality which I have categorized in the table below on the first column. Each column describes one method of duplicating a Drupal installation, and the last column is the combination of using installation profiles and the Features module.
I made this wikipage to get some feedback from the community, because I haven't tested all the different functionality with all three methods. Some of the results which I have written are assumptions, so they can be discussed and changed. If someone is really contributing to this, I will mention his name on my thesis for sure ;)
Main idea behind the whole duplicating process is to make it as easy as possible for the Drupal developer. Database dumps are straight-forward, but cannot be easily changed for different purposes. Installation profiles help to set up the the site, but are very tedious to build. Features provide a user interface to create them and can be easily recreated. With the help of installation profiles Features can be enabled and provided as out-of-box customized Drupal distribution.
As everyone can see, all the functionality listed on the table is quite abstract, so on some cases there are several modules to choose from.
Because wikipages cannot be commented, discussion takes place here http://groups.drupal.org/node/58083
Comparison of different methods for duplicating a Drupal installation, focused on social functionality.
Scale: weak | fair | adequate | good | excellent
| Feature in SNS | Database dump | Installation profiles | Features | Installation profiles + Features |
| Relationships | Fair. Depends how complicated relationships site has. | <- | Adequate. User relationships and related Views can be included in a Feature. Overlapping features makes defining views difficult. | <- |
| Commenting | Adequate. Comments don't require much settings. | Good. Commenting can be set per content type with variable_set() | Excellent. Features recognizes settings per content type. | <- |
| Private messaging | Good. Once set up doesn't require much changes. | Good. All settings can be set during installation. | Fair. Problems with menu settings. | Excellent. Can be placed into menu during install. |
| Mail notifications | Fair. Once set up doesn't require much changes. Templates need to be set per site. | <- | unknown | unknown |
| Chatting | Drupal doesn't currently have a good solution for instant messaging. | <- | <- | <- |
| Micro-blogging | Weak. Requires lots of integration to Views and Activity which can differ from site to site. | <- | Excellent. Views can be included. | <- |
| Activity | Weak. Requires site specific settings and integration with Views. | <- | Good. Views integration helps, but site specific templates for notifications need to be set up. | <- |
| Content types | Fair. Requires site specific set up. | Adequate. Content types can be set up, but integration to CCK requires lots of set up. | Good. CCK fields and field groups are recognized. Handling of disabled content needs some attention. | Good. Like Features + content types can be set up during installation. |
| WYSIWYG-editing | Good. Once set up doesn't require much changes. Editors are not included in modules, so they have to be downloaded and installed separately. | <- | Fair. Modules and some settings can be set up, but integration to input formats is tricky. Some settings are not recognized. | unknown |
| Files | Adequate. Once set up doesn't require much changes unless special modules are used for advanced functions. | Good. Settings per content type can be set. | <- | <- |
| Voting etc. | Fair. Requires site specific set up. | unknown | unknown | unknown |
| Sign-ups | Weak. Requires site specific set up and integration to Views and Panels. | <- | unknown | unknown |
| Groups | Fair. Requires site specific set up. | <- | unknown | unknown |
| Aggregation | <- | <- | <- | <- |
| Feeds | Weak. Feeds are mostly included in Views. | <- | Good. Each views can have several feeds which can be included in a Feature. | <- |
| Theming | Weak. Database doesn't store anything related to looks, unless theme has some settings which affect it. | Fair. A theme can be set during installation and some settings for it. | Adequate. Theme settings can be included in the Feature. Can CSS be included in a Feature??? | Good. Theme can be set during installation and Features can set the settings. |
| Tagging | Weak. Requires site specific set up. | Good Settings per content type can be set, and taxonomies created with terms. | Adequate. Settings per content type can be set but taxonomies cannot be included (at least without the help of taxonomy_export module). | Good. Features helps with set up and installation profiles can create taxonomies to use with content types. |
| Search | Good. Part of core, doesn't have much settings. | <- | <- | <- |
| Subscribing content | Fair. Requires site specific set up. | <- | unknown | unknown |
| Registration | Fair. Requires site specific set up. | <- | Good. Features recognizes which fields are used with Content Profile User Registration. | <- |
| Single-sign on | unknown | unknown | unknown | unknown |
| Inactive users | Adequate. Inactive user-module has settings which can be set once and are not likely to change often. | <- | Good. Strongarm recognizes settings from Inactive user-module. | <- |
| Roles and permissions | Fair. Requires site specific set up | Adequate. Roles can be created during installation and give permissions, but is tedious. | Good. A Feature can include all the required permissions. | Excellent. Installation profiles can create required roles and Features can take care of the permissions. |
| Configurations variable_get() - settings pages | Adequate. variables are stored in the variables table, but no break down between modules and contexts can sometimes be difficult to extract. | unknown | unknown | unknown |