bbPress.org

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.

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).

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!

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.

“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

“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?

“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

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?

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, 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, 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.