How CMS architecture affects dev communities

I'm probably going to make some provocative statements

At least I hope so!

Stand back, he's got code!

What about the Communities?

Any general conclusions about how code affects communities?

Who's a developer?

How CMS Architectures Affect Developer Communities

Have you...

• modified a template in a CMS?

• modified code in your copy of a CMS?

• written a module?

• contributed code to an open source CMS?

• been lead dev for a CMS?

A case study of WordPress, Drupal, Tiki Wiki and XOOPS

They're not facts, they're opinions and observations

I'm not talking about popularity, or which is best

And just because I say something about one system, that doesn't meant I'm saying the opposite about the others....

When one twin is being good, it doesn't mean the other is not good too.

"Core"

"Plugin"

XOOPS

// this is basically the URL

Forum modules, to be precise

"Module"

part of functions.php...

bbpress.php

Drupal

Tiki Wiki

part of menu.inc

"Core"

"Core"

"Module"

part of forum.module

'page_callback'], .....

forum.pages.inc

part of theme.inc

"Core"

Conclusions?

• Looks and feels a lot like standard PHP

• It's a single codebase, following normal patterns

• All features are available as part of the single download, but configurable on and off, so the code is sort of modular, but the structure of the project is not

back in forum.module

"Module"

(templates)

forums.tpl.php

Tiki Wiki Community

• Unified. Everyone is working on the same codebase.

• Very open, they build their CMS in "the Wiki way"

• Smaller community of developers than some CMSs but larger than others (XOOPS)

• Successful project with a long history, and still releasing, currently about 6 months between releases

forum-list.tpl.php

Conclusions?

Conclusions?

Conclusions?

• Clearly PHP, but has some characteristics of a framework

• Modules are more separate from the core, interact in specific ways

• Some convention-over-configuration, simple ORM

• Extremely abstract, strict standards in place for how modules interact with the rest of the system

• Modules provide very specific artifacts which the core system decides what to do with

• Almost like another language, not PHP

• Emphasizes conventions, less abstract than Drupal

• Tries to follow a simple linear flow, for the most part

• Plugins are a whole universe of code, and a lot of logic is pushed straight into the template layer

The XOOPS Community

• Clear distinction between core developers and module developers

• More module developers than core developers, so the pace of development on the core has been slow

• Modules have tended to become "big" and take on a life of their own

• Many cliques and divisions within the community, the project has been forked often, and so there has been no consistent release schedule

The WordPress Community

• Automattic runs the show, reminiscent of Mambo back in the day

• But, over half of developers with commit access to the core, are not Automattic staff

• Nonetheless, the Plugins are where the heart of the community is. There are plugins galore, and themes galore, which are kind of like modules/plugins in other CMS's because of the amount of logic in the template layer.

• Like Mambo, there is a hybrid open source/commercial ecosystem around the plugins

• 4+ years between major releases

The Drupal Community

• Modular, but everyone relies on the core a lot, and in the same way

• Lots of people commit to the core

• The uniqueness of the codebase tends to create a strong bond among the developers (which also leads to not-invented-here syndrome)

• Modules tend to be small, and extend the common capabilities of Drupal, rather than creating large independent sets of functionality

• Popular modules get absorbed into the core from time to time

• 2+ years between major releases

Theory 4:

Money Talks

Theory 1:

Cathedral and the Bazaar

Theory 2:

Interactions with code are the ties that bind

Theory 3:

A healthy balance between parts of the code makes for a healthy community

Does the architecture make one of the projects behave more like a Cathedral?

The more a group relies on the same code, the stronger they become.

The communities of all four projects are shaped by where and how people are able to interact with the code.

WordPress is somewhat of a hybrid architecturally, tending towards the complexity of Drupal, with the simplicity of engagement of XOOPS

Tiki Wiki and Drupal have opposite architectures. But both have strong communities.

All three projects make a "plausible promise," the key design foundation for bazaar projects.

Julian Egelstaff

When people have more access to, or more reliance on, the core code, the community is stronger.

Predictably, the community is more engaged with modules/plugins, than the core.

But XOOPS has had a hard time, "releasing early and often, delegating everything they can, and being open to the point of promiscuity."

The main difference is that the modular aspect of Drupal makes it more approachable, and flexible. So its community is larger.

But that doesn't lead to the same challenges XOOPS faced, because the strong leadership of Automattic, and the commercial interests of many in the community, create a strong disincentive to fork.

Maybe this has been a challenge because of the imbalance between the core devs and the module devs, which arises from the architecture.

It doesn't seem to matter if you have a lot of core developers, but it does matter that your community uses the architectural features of the core code as a foundational part of their systems.

In both cases, the community members all rely on the same codebase as each other, to a very high degree. This creates more standardization and transferability of knowledge within the community.

julian@polygon.red

@jegelstaff

The more opportunities people have to bypass the core, the more chance that they will not engage strongly with the community.

The "big" module architecture of XOOPS creates less common ground for the members of the community, which makes it more likely the community will fragment.

Even when there is looser dependence on the core system, as long as there is enough dependence, and the system itself has strong backing, the community can thrive.

There have also been leadership problems and too many forks. But would a different architecture have created a stronger community that could deal with those problems more effectively?