Hi, here‘s the second post of our series about the new direction we plan to take regarding plugin maintenance and evolutions. In our first post we shared with you our new purpose « Get together safely, in your own way, in WordPress », let’s see how the feedback you shared with us here & there helped shape the new way, I believe, we should use to reorganize and simplify BuddyPress.

Key feedback about the BuddyPress plugin’s organization

  • « Ultimately the easier it is to use BuddyPress the more vibrant the ecosystem around it becomes »
  • « I would replace BuddyPress’ systems while building new things and break backwards compatibility on purpose, start on a new plugin »
  • « I’ve always heard/read was that those features were better off served by plugins. Whereas users would be more likely to expect them inside the core plugin »
  • « I may only want to use certain aspects of BuddyPress and NOT the whole pack »
  • « It would be neat though to have a BP-lite »
  • « A “BuddyPress lite” plugin if you’re talking about “restarting from another plugin” might be worth some discussion. »
  • « We are into the WordPress Official Plugins directory, we should really use this advantage and split BuddyPress into smaller parts »
  • « BuddyPress plugins directory ».

I believe we need an important change about the way we package features 📦. I’m convinced the BuddyPress « lite » idea is the right direction to take. Although as a developer we might not see a difference from the modularity of BuddyPress’s current code base (optional components can be activated or not), I can understand some users’ point of view: « why am I downloading code I will never use? ».

Since 10.0, we now have the « BuddyPress Add-ons » tab ➕ inside the « Add Plugins » Administration screen. This tab is listing the plugins BuddyPress favorited inside the WordPress.org plugins directory. So far we are only favoriting the ones the BuddyPress development team is maintaining. We can use this space to progressively move optional components into it. Of course, we would then also improve & ease as much as possible the install process putting together a step where we’re asking what BuddyPress Add-ons site owners wish to download, install and activate.

Progressively turning optional components into BuddyPress Add-ons would benefit end-users and third party plugin authors. The latter would be able to build alternatives to our optional components to challenge the BuddyPress development team and give end-users more choices to get the features meeting their needs. Of course they would keep the ability to simply extend Core or optional features.

Another benefit about packaging each optional component as an add-on is: we’d then be able to have usage statistics about them and prioritize our work according to their popularity.

This tab (in other words the plugins favorited by the BuddyPress team) could welcome third party plugins to progressively build a « safe » BuddyPress plugins/add-ons directory. Bringing this safety to our end-users would be the result of third party plugin authors engagement to:

  • define their dependency to BuddyPress in their plugin’s main file header to get ready for a potential « Plugin dependencies » merge into WordPress core.
  • maintain their plugins in the long term, and eventually invite new maintainers to take over their work when they feel they cannot do it anymore.
  • bring free support to their users,
  • embrace the WordPress etiquette, code formatting, i18n & security best practices,
  • test every new BuddyPress beta versions and report issues when needed.
  • Stay updated by reading important developer notes.
  • Make sure their plugin is fully compatible with latest BuddyPress version.
  • Get involved at least twice a year into contributing to one or more of these areas: BuddyPress support, documentation, translation, events or code.

I’m convinced that end-users care more about features being actively maintained ⚡️than all of the features being included in one large plugin.

The first concrete step

A first version of the long awaited Media component was released as a BuddyPress Add-on 🖼️ on March 25 🎂. There’s still a lot of work to do but I believe it has a solid foundation: it uses ReactJS, blocks, the BP REST API and something I would name a « BuddyPress » way of storing media data.

BP Attachments

One month after its release usage statistics is very low (fewer than 10 active installs). As it so far hasn’t gained much traction in an area that is served by existing third-party plugins, it’s suggesting to us that end-users do not consider the “Made/Maintained by BuddyPress” to be a sufficient advantage in and of itself. That’s a good thing: it’s challenging us to improve the plugin and to better communicate about it.

Moreover, BP Attachments is an interesting playground for us to use to find the best way for plugin developers to carry on being backward compatible with BuddyPress versions below and upper 12.0.0.

To conclude with this feedback category, yes we need to reboot. But let’s do it gently to onboard & keep on board as much as possible the members of our community:

  • shrinking one step at a time BuddyPress to its Core features,
  • moving optional components or new ones into external Add-ons,
  • and putting backward compatibility inside another plugin (BP Classic).

It should leave end-users the time to get used to a simplified & reorganized BuddyPress and to plugin developers to upgrade their works.

Our next post of this series will talk about some other BuddyPress « features » we are thinking of considering the feedback you gave us.

Props: many thanks to @dcavins for his review 😍.