When discussing the tools used by open source communities, a conversation inevitably arises about mailing lists and forums. The received wisdom suggests that the more technical members of the community (often, the developers) prefer mailing lists, while the less technical members (often, the users) prefer forums.
I see this distinction as much like the distinction between the command line and the GUI; Some users know exactly what they want to do, how to do it, and don’t want an interface getting in the way. Others need to explore, find out what options are available to them, and decide what to do. In The Art of Community, Jono Bacon notes that forums have a much lower barrier to entry than a mailing list. As a result forums may have a larger proportion of users with less experience of the etiquette of online discussions, which may in itself put more experienced or more technical community members off.
While its important to do your best to give your community members an environment they’re comfortable with, segregating your users and your developers in this way can be detrimental. Users may be excluded from discussions relating to the ongoing development of the software, and feel disenfranchised. Developers may miss out on valuable feedback from users, and find it difficult to get developments tested in real-world situations.
Moodle’s community works a little differently to this often-assumed model. The majority of Moodle discussions take place on the community forums on moodle.org, involving the core developers, third-party developers, Moodle system administrators and teachers. Discussions are categorised into a whole collection of discussion boards, but nothing’s hidden – a teacher is quite welcome to browse and post in the General Development forum, just as a core developer is welcome to ask questions on the teaching forums. The quarterly general developer meetings are open to all, regardless of technical knowledge.
Beyond the virtual, this homogeneity happens in real life too. From local user groups to national conferences, developers and users come together to share experiences and ideas.
Does the Moodle community have special characteristics that promote this merging of often separate parts of the community? There are a few things that stand out to me:
- Moodle is a self-hosting project. That is to say, moodle.org runs on an instance of Moodle, so the community use the tools that Moodle comes with. While Moodle has a forum module, it doesn’t have a mailing list module, so the default position is to have everyone use the forums.
- A lot of institutions that use Moodle employ staff to administer and/or develop it. This means that users have some exposure to the more technical members of the community within their own institution, putting a human face on them and giving users a better idea of what to expect from such members in the wider community.
- Moodle is written in PHP, which makes the barrier for entry as a developer fairly low. I’ve known of teachers who’ve taught themselves a bit of PHP getting involved with Moodle development, and countless novice programmers who start their programming journey hacking Moodle for their institution. These developers tend to be welcomed with a reasonable amount of patience.
There are, of course, situations where this merging isn’t as relevant. Some discussions will only be relevant to the more technically minded members, some only to the more pedagogical members, and so on. The forum model allows this to work since you don’t need to see the contents of a discussion thread you’re not interested in. The Moodle core committers also have a chat room for synchronous technical discussions and regular meetings, which would be of limited interest to end users.
This example shows that the received wisdom of a divide between how users and developers communicate can be overcome. By enabling all members of your community to engage as equals, you ensure that everyone feels involved and enfranchised, which in turn helps foster adoption of your software.