That may be good for Devs. But users like us will want

Responsive theme + modern UX + profile + friend finding + blogs + photos + event + location bundled into one and in harmony with each other, that does not have to hunt for necessary stuffs in the repo.

Users like us mean who need out-of-the-box stuff, easy install and can have more time for actual content and getting users for our sites. Drupal out-of-the-box has actually "Views" and CCK, with which you can create almost anything. That apart Drupal also has https://www.acquia.com/downloads and Drupal Commons, drupal's equivalent of Elgg, that bundles everything needed for social networking.

if no-one has ownership of the plugins, that could be resolved with or without making them standalone and removing them from core.

in many ways it would be good to have the bundled plugins evolve independently, as with other plugins. what will make or break this will be the issue of how skilled the desginer(s) / coder(s) is/are that take on the plugins.

one reason why this is not such a great idea is that for elgg to be coherent as a platform, there needs to be consistency of features and design across the basic components of the platform and even now, with these plugins as part of core, there is not really enough consistency between the plugins at the code level. this inconsistency makes developing code that interacts with multiple plugins harder than it should be and also less efficient.

i think that a more efficient approach would be to create a class (or similar structure) that defines something like ElggEntityPlugin that provides a standard interface for handling elgg entities - which can then be extended for the needs of each specific plugin. this would provide both a simple way to start creating new plugins for new entity types and also a way to unify the existing code in a way that provides ease of use and ease of understanding. this would also make the individual plugins easier to maintain and more attractive to devs in the community who may come to 'own' them.

My guess is that the overwhelming majority of Elgg users are not developers but people who are looking for more than just a social network framework but are quite happy that Elgg comes with some additional functionality out-of-the-box to ease the start of an Elgg site.

Separation of repos but still keeping them included in the core releases might be a problem with tracking BC breaks in core and fixing them before a major release. Even more so with not including them in core anymore at all. I understand that you are trying to concentrate the limited development resources on core but this will sooner or later result in the bundled plugin (or then "featured" plugins) will be left behind just because they get out of focus even more.

Even with keeping the plugins bundled people can replace any of them with another one of their choice already (with different or additional functionality). I don't know if separating the repos would attract some developers to support the bundled plugins instead of working on alternative versions of these plugins instead.

Is it even possible to separate all bundled plugins from core. The Groups plugins comes to my mind here. And you might also think of CKeditor, htmlawed, notifications, messages, search and maybe even more. Even with their functionality being provided by plugins I would see a lot of this functionality as "Elgg core functionality". How many plugins would remains that could be separated without losing key functionality? And would it be worth the effort to separate these few from core? To a certain extend the bundled plugins also provide some examples / templates for creating custom plugins.

I'm thinking we remove: blog, bookmarks, discussions, file, messageboard, pages, thewire, maybe messages. Places where users spend most of their time. Keeping these plugins bundled (and synced with core versioning) means almost no meaningful UX changes can occur between major versions. Bad!

We can still get cool extensions like file_tools, but it leaves the default experience pretty crappy. Wouldn't it be better to just offer a plugin with all that functionality (and plenty of settings to disable what you don't want)?

I recognize there's no free lunch here. The status quo probably makes Elgg a more stable platform with regard to reducing compatibility problems between plugins; you know you can build on top of the file plugin and it'll pretty much Just Work from 2.0.0 to 2.11.4.

But the cost is that the default UX is only going to become more stale and unacceptable to end users. Per's aalborg_theme breathed life into Elgg, but we can't stop there.

I think it depends on who our target users are - high level devs?  Then yeah, lets pull them.  For the most part I rarely use them in my projects anyway as everything ends up so customized.

If we care about the hobby users or people installing Elgg to try it out I think we need to keep things bundled.  You mentioned Drupal earlier, but even Drupal core comes bundled with some content modules, blog/book/forums

i would really like to see the forum functionality expanded and improved to bring it to a level that is comparable to other forums (even ones that were around 10+ years ago! lol). if putting the plugins in their own repos helps facilitate that, then i say do it!

who would take responsibility for them though? i would do but i have other priorities that already have me swamped and that is unlikely to change in the near future, so i can't say yes to that. i would probably contribute to them though.

Note we can still offer an official distribution of Elgg with any plugins, even in .zip. Removing the plugins from the repo would be just so plugin versioning could be sane. It also would allow making GitHub users plugin-level contributors, which might help with the ownership part.

Everyone wants a different feature expanded and improved :) The hope is we can say, "yes you can add that feature today" instead of "well, make a PR on master and no one will look at it until 3.0 is in development and even then only devs willing to set up a new Elgg 3.0 install will be able to evaluate it."

What is the long term plan? For 2.X I would expect the plugins stay bundled even if there would be enhanced versions of these plugins in development in separate repos. Would these enhanced versions of the plugins then be re-bundled (in their current form at that time) in the next major core release (say 3.0)? Or wouldn't there be any efforts made to have them working on the next major release at the time of its release (getting the separate but bundled plugins compatible = "blocker issue")?

How to handle compatibility of 3rd party plugins with the enhanced versions of the formerly bundled plugins? Right now I can expect that people using Elgg 1.X or 2.X will use a specific version of the bundled plugins and I can make my 3rd party plugin work for the version of Elgg. But if there are not one but two branches of the featured plugins to be used with a Elgg core version I would have to maintain different versions of my 3rd party plugin just to get it working for all users. Even worse (impossible) to maintain a "meta" plugin (e.g. Elggx Fivestar) that relies not only on a single plugin of the featured plugins to be available in a specific version but basically all of them? Another example of a "meta" plugin could be a theme plugin. How to develop a theme for a specific Elgg version if the featured plugins (which I would expect would still be in use by the majority of people) have no stable UI?

Dependencies on each other is also true for the bundled plugins: embed plugin relies on files plugin, ckeditor plugin relies on embed plugin (when used). So, there would be about 7 -8 plugins remaining that could get separated. Separation offers the theoretical chance that these plugins could be modified / enhanced on a larger scale than before. But are there development resources to be expected to do it? And to do it faster than doing it with the following major release of Elgg core? The plan is to release major releases of Elgg faster anyway? Wouldn't it be still too long then for getting larger changes in the plugins done then? Or would it just turn out to be a much larger effort for maintaining compatibility with these plugins for site admins and 3rd party plugins / theme developers without much gain regarding enhanced functionality within these plugins? I just want to refer on the planned bi-weekly release schedule / 3-monthly minor release schedule. That was the plan but realistically this schedule wasn't really followed at any time - and I don't mean that as criticism at all! It just shows that the development resources of all of us are limited and we can't achive everything exactly as planned.

Good point.

To be clear you are suggesting that we can add features and breaking changes to the core plugins by separating them and versioning them independently of core?