Send the link below via email or IM to invite your audienceCopy
Start the presentationStart presenting
- Invited audience will follow you as you navigate and present
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can view together your prezi
- Learn more about this feature in the manual
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
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! Tiki Wiki XOOPS Forum modules, to be precise I'm not talking about popularity, or which is best 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 part of functions.php... 'page_callback'], ..... 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 Drupal part of menu.inc // this is basically the URL part of forum.module forum.pages.inc part of theme.inc back in forum.module forum-list.tpl.php forums.tpl.php Conclusions? 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? Theory 1:
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? Theory 2:
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. Theory 3:
A healthy balance between parts of the code makes for a healthy community The communities of all three 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. Julian Egelstaff
Freeform Solutions email@example.com @jegelstaff