[Matt Mullenweg]

I think this is worth discussing since it seems to be a core philosophical issue that comes up a bunch, with people citing text I wrote for the about page!

The general rule we’ve followed in WordPress, which has been successful for user adoption, has been that something is “core” functionality of it is something the vast majority (80%+) will appreciate, or if it something that makes WP more robust even if they don’t care about it (revisions), or if it’s something we want to promote because we think it will make WP or the web an intrinsically better place (oembed).

Something might be a hugely popular plugin but not perfect for core because: it ties in a commercial service (Akismet), it needs to update more frequently than core does (faster dev cycle), or it adds more overhead than is worth it. For the last, we can often bring in the bare minimum or framework into core and leave the rest as a plugin (podcasting support in WP, and PodPress, or SEO improvements we make).

A bonus of core is that (in theory) the code gets better reviewed, can be relied on by new plugins to be there and build on, and maintained as part of the overall package. It also often brings new folks who may have just worked on plugins before into improving core which increases exponentially the impact of their work.

Of course there is lots of common sense along the way, this is just meant as a general framework for approaching the problem.

[_ck_]

I began to write several different replies to this but decided not to post it because technically this is not really a discussion or will change anything.

Let’s just say I completely disagree and leave it at that.

[kevinjohngallagher]

This is an excellent point Matt, and actually one of the strong selling points of bbPress in the past 18months has been how little is in the core.

I, like i’m sure others out there, have had wrangles with moulding bbPress to work in the way I’d like (e.g. between 4-7 clicks to delete a user, and having to leave the admin area to do it, and not be able to do it in bulk = eek). But other than some core hacks (like adding actions / filters all over the shop), it can be modified quite nicely. I often describe bbPress as “90% there”. In part, down to the excellent base, and in large part to _ck_’s plugins.

That said, I feel that one of the issues with the current development line “we” kick started in December time is that we took 2 feautres which worked brialliantly as plugins and added them to the core; without any real need for that to happen.

Why? because they were features for the end-end user. Not the person running the forum. It’s like the people who say that people won’t post on their forums without a WYSIWYG editor or Smilies, we could add them to the core, loads of folks would be happy, but we’d still not be able to moderate all those nicely styled posts with loads of ” ZoMg >.<” etc

If you look at the features you’ve added to the core of WordPress, they rarely have been for the sole benfit of the person reading the blog. They’ve mostly been to benefit the person running the blog, in the theory that that enables the end-user too.

So reguardless of what version of bbPress/WordPress/other-software we’re talking about, even if somethings in the 80/20 split, please think who it benefits and who it causes issues for. We all know there’s good and bad to every decision, but let me assure you, i’m losing sleep over moderating a bbpress forum with anonymouse posting!

WP3.0 was effectively a “developer release”, or at least not end-end-user focussed. Not sure about you, but I think it’s the smoothest, least-buggy, most impressive release in a long long time. Maybe thats what bbPress needed instead of adding core features we already had as plugins.

Of course, hindsight, pretty wonderful thing.

[johnhiler]

I think most developers who run highly trafficked websites will prefer keeping stuff out of the core, to minimize bloat and to maximize scaling. Whereas most casual webmasters running a smaller forum will want as much in the core as possible.

It’s a natural tension. I think the best way to split the difference is to keep the core lean and mean, and then to have a set of pre-packaged plugins that are included in the main download that can be turned on (or can even default to being on). I think WordPress experimented with this direction last year? Not sure where it ended up though.

A few things were moved out of bbPress plugins into core, and it hasn’t really gone that well. “Subscribe to topic” was added to the core, and then promptly had a problem with spammed topics being blasted out over email. It’s a lot easier to apply a patch to a plugin than it is to get the patch approved in the core.

The “Page Links for bbPress” plugin was also moved into the core in 1.0. There were a number of code inefficiencies in that code that are now locked into the core. There was a recent patch released for the plugin version of Page Links (only for 0.9) that fixed this; that’s an example of how it can be helpful to keep non-essential stuff out of core.

[_ck_]

Actually, there’s a super simple compromise.

Ship the most popular plugins with the program instead of folding the plugins into the core.

Focus on just making the core the best core it can be.

However this will never happen and it’s not for logical reasons, it’s “politics”.

Hence I’m not touching it further, it’s a moot point anyway, firm decisions have already been made.

ps.

(KJG on WP3) Not sure about you, but I think it’s the smoothest, least-buggy, most impressive release in a long long time.

I immediately had upgrade problems. So severe I had to nuke my entire install to get it going again, I literally could not solve it myself (imagine that).

[citizenkeith]

It’s a natural tension. I think the best way to split the difference is to keep the core lean and mean, and then to have a set of pre-packaged plugins that are included in the main download that can be turned on (or can even default to being on).

This gets my vote as well. Instead, I would prefer the next version of bbPress to have more powerful admin features (see Kevin John’s above examples for specifics).

[John James Jacoby]

Pete and I talked about this in #bbpress last night a little bit. Using WP post types lets us inherit all this neat stuff, but much of it isn’t really /needed/…

Like Forum/Topic/Reply revisions, comments, thumbnails, excerpts, etc… Sure there’s lots of neat ways those things could be used, but they don’t help keep things trim and tidy.

Would love to get some good feedback on this!

[kevinjohngallagher]

I was thinking about this on the way home. I think Forums as a Category is a great example. It was a plugin by _ck_ which was (for me) essential in 0.9; but it’s essentially a (hope i got the american term right) “band-aid”. Basically, if you worked within it’s boundaries, and accepted it’s issue – it did exactly what it said on the tin.

The thing is, it was then rolled into the 1.0core without any form of thought. Now we’re “stuck” with something that could have been a great feature with 2 days of dev time.

Forum as a category should have been in the forum table, as a 1-to-1 relationship. Every forum is either yes/no. Its no more meta than the name.

To the next level, the bbpress definition of a category is any forum that is both read only and has child forums. Thats daft. Don’t get me wrong, it was a needed/ideal/susynct work around for 0.9; but no scoping/checking/planning done before rolling it into the core. I remember during one of the BigBrother last evictions I told one of our staff to make a particular forum read only for a minute (which triggered all the category restrictions no showing of posts etc).

No harm done, i thought, until people couldn’t navigate or read their own posts as categories are given different theming. circa 1000 screaming teeny-boppers and lonely housewives on a shout-box!!

Its little things like that, where as a plugin, heck even a “core plugin” we can fix it quickly. As soon as it enters the core…

[Milan Dinić]

we took 2 feautres which worked brialliantly as plugins and added them to the core; without any real need for that to happen.

Subscribe to Topic wasn’t working without edits after 1.0 was released and _ck_ first announced that she won’t update any of her plugin until end of 2009 and later completely got out of bbPress world so we already needed a new plugin.

[Matt Mullenweg]

johnhiler, plugins is core, additional functionality, and performance are orthogonal topics, in that one does not necessarily mean another and I think it’s dangerous to conflate them.

There was a bug with spam being sent out, but it was alpha software, and the bug was fixed as soon as someone left a patch for it.

If anything it should be easier to get a patch into core rather than a plugin because core has a dedicated Trac instance and multiple commiters, something most plugins do not. (Assuming they’re not abandoned.) Core is more likely to be translated than plugins.

Finally, it takes the emphasis off of a single person (most plugins have one author) and puts it onto the core development community, which bbPress has never had but needs to grow if it’s going to survive.

As for bundling multiple plugins with core — ultimately it’s a cop-out. If something is good enough to be included with the core download, put it in core! At that point you don’t gain anything from keeping it separate except the increased user cognitive load of having to activate 20 plugins to get, in their view, basic functionality and the instability of new plugins being unable to depend on functionality being there to extend it.

[Matt Mullenweg]

Милан Динић, good point, when something is in core it is always QA’d along with the release.

[hpguru]

bbPress plugin for WordPress with reply in WordPress theme reply form with Akismet maybe a good idea.

[johnhiler]

“As for bundling multiple plugins with core — ultimately it’s a cop-out. If something is good enough to be included with the core download, put it in core!”

I’m a big fan of a plugin-centric approach to platform development. I would take the bbPress platform and add a ton more hooks and filters to it. Then I would document the heck out of it, and refactor as much of the core into external plugins as possible. That way, plugin developers would have a lean and mean core to program to.

It sounds like you prefer a core-centric approach. I have concerns that both WordPress and bbPress are increasingly becoming too heavyweight to support shared hosting (or to scale for larger sites, without expensive hardware). But perhaps I am underestimating the power of the dropping cost of hardware and of aggressive output caching.

I understand your general framework to approaching core features, and understand that it’s been successful for you with WordPress. It’s kind of similar to how Microsoft approaches integrating application features into its own core Operating System. Both platforms have been successful, so I can’t knock the approach.

I guess we’ll just agree to disagree on this one. I’m just a big believer in a plugin-centric model. I think WordPress has succeeded in spite of its aggressive core-centric model, not because of it. But I understand your philosophy, and respect your right to enforce it on future versions of bbPress.

Best,

John

[John James Jacoby]

johnhiler, if you like plugin-centric development, you should love the bbPress plugin so far (hopefully) Hopefully it’s able to walk the line and offer the best to both.

What is a plugin and what is core is always one of those topics that tends to change and drift with the times. 6 years ago having properly formatted links to someones blogroll was considered important enough for WordPress core, but chances are people are using that functionality less and less as time goes on and people are able to connect to people more quickly and organically.

kevinjohn, we haven’t tackled it in the plugin version yet, but the difference between a ‘category’ and a ‘forum’ will be fairly distinct once we get it going. My experience working with the Categories Hierarchy project back in my phpBB days taught me the importance of handling the way those types of data behave.

[johnhiler]

“johnhiler, if you like plugin-centric development, you should love the bbPress plugin so far (hopefully) Hopefully it’s able to walk the line and offer the best to both.”

@John James Jacoby – I’d love to hear more! What do you mean?

[Matt Mullenweg]

Shared-hosts are the bread and butter of WordPress usage. The good news is servers are way more powerful than when I wrote the first bbPress, and we can take advantage of that to provide a richer experience.

I like the idea of plugin-centric development from a theoretical point of view, and obviously plugins have been at the core of WordPress’ success, but I think it can be taken too far and take away from the user experience.

It’s about taking responsibility. Even though you could break down almost every feature of WordPress into a plugin and distribute everything bundled, and even activate a bunch of them by default I think you lose a “buck stops here” for other developers to target. The uncertainty of testing the interactions of N factorial plugins is daunting and gets untenable quickly.

Better to draw a line in the sand and promise the user “these things will always work together.”

[johnhiler]

“Shared-hosts are the bread and butter of WordPress usage. The good news is servers are way more powerful than when I wrote the first bbPress, and we can take advantage of that to provide a richer experience.”

This is definitely true. It’s kind of the Microsoft approach: grow the OS core, and lean on the hardware handle the growing codebase. It works for smaller sites that don’t hit scaling limits and for larger sites that can afford bigger hardware.

“The uncertainty of testing the interactions of N factorial plugins is daunting and gets untenable quickly.”

Plugin interaction is definitely a concern. But in practice, I have rarely if ever had plugins conflict with each other.

“Better to draw a line in the sand and promise the user ‘these things will always work together.'”

I think the “promise” model depends on having a large and growing team of developers actively managing the core. That hasn’t been the case in the past, so moving stuff into the core has actually slowed down development of the platform quite a bit. Perhaps things will be different in the future…

In any case, even with developers available to help build up the core – I’d still prefer to have a model that embraces plugin developers, and then has specific plugins blessed as official branches. This is where more social forms of source control like GitHub may be better than Subversion; plugins wouldn’t be dependent on just one developer, since anyone can seamlessly create and post a new branch. It’s much more like the pastebin stuff that’s constantly going on here in the bbPress forums.

Thanks for the reply!

John

[John James Jacoby]

johnhiler, part of us using WordPress’s built in API and architecture means we’re actually leaving turned off a lot of functionality that could easily be turned on, filtered, changed, or added to with actions.

Without it being too over the top, we’re trying to plan ahead and put actions and filters where I think I would use them myself. Since most of what we do for clients is develop custom plugins to change the way WordPress functions, we should be able to apply that experience to bbPress.

One of the things we’ve struggled on with BuddyPress, is how to make plugins, for plugins. Since plugins don’t have an internal dependency like there is on CSS or JS, we’ve had to filter and action our way into a workable solution.

So while bbPress itself is a plugin, the plan is for other plugins to be able to sneak in and change bbPress behavior before it loads, or be able to ‘plug in’ the same as always. So bbPress will be its own core, but also modular and pluggable.

All this, while striving to be as light as possible. Our work is cut out for us.

[citizenkeith]

All this, while striving to be as light as possible

I liked reading that!

You guys are starting to win over this bbPress 0.9 user. See what communication can do for a community?

[Matt Mullenweg]

johnhiler, the assumptions are indeed an active core. In the WordPress world, people who were active in the plugin arena also become active in core. In bbPress, they haven’t. Maybe that will change now.

[Greg]

Regarding Matt’s “”As for bundling multiple plugins with core — ultimately it’s a cop-out. If something is good enough to be included with the core download, put it in core!””

I agree with everything johnhiler said on this, plus I would add that the advantage of core plugins is that their coupling with the real core will be more well defined and probably minimized. Making something a plugin puts a clear boundary around the set of features that it adds. It also guarantees that the real core can work without this functionality.

Without this to enforce discipline on the design, things are far more likely to become highly coupled spaghetti.

A related issue is core bloat. Something like Windows or WordPress adds features in every release and seldom removes them. The result is that the code base is monotonically increasing in size and complexity. It will ultimately collapse under its own weight. This means that significant rewrites become necessary from time to time.

The Unix “small and decoupled is beautiful” approach is maintainable for much longer for this reason.

Higher coupling does have its advantages (performance, UX), but they are usually short term gains, winning the battle but losing the war.

[Matt Mullenweg]

Greg, I think we agree, just have different ideas about where that line is drawn. I’ve laid out the core philosophy as a framework for discussions above. I have never advocated making every plugin a core feature, and conversely I doubt you’re suggesting making every line of code in bbPress a plugin.

Balancing between the two is how development happens, and is best navigated in the context of a specific anchor (feature) rather than in abstract.

[Greg]

Matt, you are partially correct. A lot of this is about where the line is drawn. But I guess I also added another line. This has been the topic of discussion in WP before, but I think the concept of a *core plugin* is important.

A core plugin is released along with the real core and is held to the same release criteria (testing) as the real core.

Maybe this is semantics and you would just call a core plugin part of core. If so, that’s great, but I would still suggest that we talk about three things…

1. the real core

2. core plugins

3. general plugins

Referring back to your original framework, I think two of the criteria for core apply to the real core:

– essential for robustness

– something we want to promote

If it is something the majority (80%+) will appreciate then it could be released in the real core OR as a core plugin (e.g. akismet).

The benefit of a “real core + core plugins” approach is that it eliminates the conflict when something has both majority appeal AND connects to a service (again, akismet example).

It also eliminates a lot of the angst people have about additional bloat in the real core, or about the quality concerns for important plugins.

Bottom line: you can have your cake and it it too. A core plugin does not add bloat, AND it is released with all the QA of a feature in the real core.

[Matt Mullenweg]

I think you have a misconception of what a core plugin is — I originally proposed it so I’m happy to clarify.

To think of it in term of arbitrary percentages, if something is useful to above 80% of the userbase, it should not be a plugin, or a core plugin, it should be in core.

The core plugin concept was created to address the problem best illustrated by PodPress, where you had a strategically extension of something already in core (podcasting support) that was effectively abandoned and keeping a non-trivial number of users stuck on an old version. The community could take it over we could try to structure its maintenance much in the same way WP itself is structured, with responsibility spread between multiple contributors.

The percentage to trigger that is probably something like 20%. (For 20% of a userbase to use a plugin is actually pretty huge.)

I think taking essential 80%+ functionality out of core and into plugins for the sake of some imaginary notion of bloat or “correctness” actually just sacrifices user experience for modularity, it creates a new kind of bloat in that people have to navigate a confusing array of add-ons with complex interactions before they have their basic needs satisfied.

[Greg]

Matt, we’re at cross purposes. Your previous definition of “core plugin” aside, I still don’t quite understand why it wouldn’t be useful to have a place in the taxonomy for something that…

1. is a plugin

2. is released with core (same release criteria etc.)

Like akismet today. I think there are a ton of advantages, but I’ve mentioned them above and I won’t belabor them. I didn’t suggest that it was necessarily 80% functionality, so maybe it does fit your definition of core plugin to some extent.

I guess “bloat” is a bit pejorative and wasn’t my intention to poke at WordPress. But any large piece of software needs to have a strategy to deal with the inevitable growth of the code base as it evolves.

[XU3E]

Honestly, I really like idea give bbPress more functionality to core. Mainly unread post like phpBB has (All post mark as read and etc.) and more specific permission for some user rules and category. I dont know how many people wants this. We should vote, need polls,… but… Oh yes bbPress doesnt have any polls, we need plugin for this. Is there any plugin workign for my release? Damn…

Of course, for someone Its not important but forum without that its just guestbook with searchbar and topics. Really messy and pure.. Bleh!

Maybe the best solutions could be official bb-plugins supported by developers for every release (but its really hard task for developers). But eveneryone will be happy. Light-weight core and pack of plugins ready to go…

Everytime when i am downloading new plugin i prey: Will that plugin works with my new release? And what the next new release? Its terrible for every user. Sometimes i try fix some bugs but i am not php guru, and its real pain for me…

And for the people that love really light-weight solution. They can still use _ck_ 0.9 fork or another old realease of bbpress. Its up to them but official bbPress need to be pushed.

I love the way bbPress is made. I love functionality, simple look similiar to WordPress (i really love wordpress). But bbPress has so many holes at funcionality. Light weight forum like punBB? No… perhaps more sophisticated solutions with witdgets, gridtables, better sorting by speciphic parameters, quoting, better slug manipulation (like WP has), category manipulation, permissions and mainly integration with WP.

But everything should be fast as could be. Just look at MyBB. Or Perhpaps phpBB. Yaeh, its really fast… its just about optimizing. Why i dont switch to them back? They didnt have support for buddypress or wordpress… I mean native support – everything under one roof.

Conclusion…

bbPress should be disscussion board – right now i am really disapointed. So we can google for forums or helpdesks and find inspirations. If i am wrong, just kick me to my ***