Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
How CMS architecture affects dev communities
Transcript of How CMS architecture affects dev communities
A case study of WordPress, Drupal, Tiki Wiki and XOOPS
Who's a developer?
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?
I'm probably going to make some provocative statements
At least I hope so!
They're not facts, they're opinions and observations
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.
Stand back, he's got code!
Forum modules, to be precise
I'm not talking about popularity, or which is best
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
part of functions.php...
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
part of menu.inc
// this is basically the URL
part of forum.module
part of theme.inc
back in forum.module
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
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
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 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
What about the Communities?
Any general conclusions about how code affects communities?
Cathedral and the Bazaar
Does the architecture make one of the projects behave more like a Cathedral?
All three projects make a "plausible promise," the key design foundation for bazaar projects.
But XOOPS has had a hard time, "releasing early and often, delegating everything they can, and being open to the point of promiscuity."
Maybe this has been a challenge because of the imbalance between the core devs and the module devs, which arises from the architecture.
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?
Interactions with code are the ties that bind
The more a group relies on the same code, the stronger they become.
Tiki Wiki and Drupal have opposite architectures. But both have strong communities.
The main difference is that the modular aspect of Drupal makes it more approachable, and flexible. So its community is larger.
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.
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.
A healthy balance between parts of the code makes for a healthy community
The communities of all four projects are shaped by where and how people are able to interact with the code.
When people have more access to, or more reliance on, the core code, the community is stronger.
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.
The more opportunities people have to bypass the core, the more chance that they will not engage strongly with the community.
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 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
WordPress is somewhat of a hybrid architecturally, tending towards the complexity of Drupal, with the simplicity of engagement of XOOPS
Predictably, the community is more engaged with modules/plugins, than the core.
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.
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.