Liturgy is the work of the people. Ritual development, therefore, should reflect the work of the people, all people who want to be part of such projects. And the results of such community efforts should be shareable and usable by anyone, anywhere.
Liturgy is the work of the whole Christian community in all times and places. Christian worship isn’t just whatever Christians feel like making it at any given point. Worship has a unitive function in the life of a congregation and the larger body of Christ. As such, liturgical development needs to proceed with clear commitments to core principles and practices that represent the best of particular traditions and the larger Christian tradition.
Liturgical resources that will be “official” or even “recommended” must be tested, refined and validated by large numbers of Christians across the diversity of the church. Repeated testing by diverse worshiping communities over sufficient time can provide the feedback necessary to “perfect” proposed liturgies for use by a larger body of people—whether a denomination, or a group of people with in a denomination, or even ecumenically.
Involving any and all who are interested in developing ritual texts in ways appropriate to their skill and expertise.
Ensuring that everyone has the permission to use what is produced in whatever format they need to.
Creating a strong ecumenical center that allows for wide horizons for
particular indigenous voicing/expression.
Creating a process for testing, refining and validating proposed liturgical resources that keeps faith with the strong center and allows for the fullest nuance of expression of the particularity.
A Model for Practice: Open Source Software Development
Open source software development, and in particular the development process for the operating system, Linux, presents a model that can work well to fulfill the principles of liturgical development listed above. That model incorporates three distinct groups of people:
Core Developers— In Linux, this is a very small group of people work on the “kernel”—the heart of the operating system that is not changed or changeable during a given distribution project. Core developers work ONLY on the kernel, which they open for others to develop additional software upon. Their role beyond developing the kernel is to review software developed by “Developers” (see below) to ensure what they are doing is actually compatible with the kernel.
In the Open Source Liturgy Project, Core Developers (likewise, a very small group) will create the “basic rule sets” the describe what different kinds of ritual texts need to do, and will also check work of “Developers” to ensure that what they produce on this “platform” is compatible. The basic rule sets describe ritual actions, the order of actions, and in some cases, specific texts or formulas that must be included.
Developers—In Linux, these are the people who actually build what becomes a complete Linux distribution—a fully tested and usable version of the operating system that is eventually released to the public. Developers usually work on project teams, developing specific kinds of software based on the kernel developed by the Core Developers. As described above, when developers have completed a piece of software and wish to release it for testing and debugging by beta testers, they first submit it to the Core Development Team to ensure it is compatible with the kernel. Once the CDT has affirmed compatibility, the Developers may release it for testing and comments.
In the Open Source Liturgy Project, the same pattern will be followed. A group of developers (20-30) will be recruited for their specialized talents and interests in particular kinds of ritual texts. They will be divided into teams working on their specialties, create whatever they wish based on the basic rule sets, and, after verifying compatibility with the Core Developers, release completed texts to the world for testing and comment.
Testers—In Linux, anyone who wants to can be a tester or user of beta releases. When a particular piece of software has been sufficiently tested by enough people, comments and bugs found can be reworked by developers (or developers may review an accept alternative proposals by testers). After another check with Core Developers for compatibility with the kernel, the reworked version can be released for further comment and testing.
In the Open Source Liturgy Project we anticipate three levels of release—Beta, Release Candidate, and, when there are sufficient release candidates that have been developed and rechecked for consistency, full Distributions—beginning with but not limited to a United Methodist distribution.
Throughout the process, until a full distribution version is released, the work released through this project will be protected under Creative Commons licensing allowing for it to be copied and shared widely in any format, but not for commercial use or in any modified form (link to license is here: http://creativecommons.org/licenses/by-nc-nd/3.0/).
Core Developers Consultation, Year 1: March 30-31, 2008
Will bring together the core developers to develop proposed cores for rituals for baptism, Holy Communion, marriage and death/resurrection.
After this work is complete, the proposed cores will be sent to members of the Consultation on Common Texts and the United Methodist participants in the North American Academy of Liturgy for review and feedback. (Complete by June 1, 2008)
The Core Development Team will then revise with feedback received—complete by July 1, 2008. Final forms of the cores should be stable—not to be changed substantially for at least six years after introduction.
Developers Consulation, Year 1: November 2008
Will gather developers for a writers’ conference to begin developing ritual resources compatible with the established cores that speak from their communities of faith
Alpha Releases: By April 2009
Further Core Developers Meetings to establish cores for other kinds of ritual texts, with subsequent developer meetings to launch next phases of work.