Liturgy is the work of the people. The development of new worship resources for the church, therefore, should be and 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, anytime.
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 unites the local congregation and the larger body of Christ. As such, the development of new worship resources needs to have clear commitment to core principles and practices that represent the best of particular traditions and the larger Christian tradition at the same time.
Liturgical resources that will be "official" or even "recommended" must be tested and refined by the communities who develop them for their use, recognizable by Christians across the diversity of the church. Repeated testing of new resources in development by the communities with and for whom they are developed can provide the feedback necessary to "perfect" particular resources. If they are solidly grounded in an ecumenical "core," they will also be recognizable by all Christians.
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 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 and other open source software projects, there 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 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 compatible with the kernel.
In the Open Source Liturgy Project, Core Developers (likewise, a very small group) have created the "basic rule sets" that describe what different kinds of texts (Holy Communion, Baptism, Marriage, and Death/Resurrection) need to do, and also check the work of Developers to ensure that what they produce is compatible with the basic rule sets or "cores." The basic rule sets were themselves tested ecumenically and with United Methodist scholars to ensure they included what both United Methodists and Christians from across the ecumenical spectrum considered to be most important to say. These cores describe ritual actions, the order of actions, and in some cases, specific texts or formulas that should be included for a proposed text to be considered "compatible" with the core.
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 Core Developers have affirmed compatibility, the Developers may release it for testing and comments.
In the Open Source Liturgy Project, the same pattern is being followed. Developers are being recruited for their specialized talents in writing in the vernacular of the cultures, denominations, or groups where they worship. Developers are trained in using the cores to write new ritual, and then gather writers communities to begin to write and distribute new resources they are developing within their larger community context.
Testers -- In Linux, anyone who wants can be a tester or user of beta releases. When a particular piece of software has been sufficiently tested by enough people, developers can rework their software to eliminate the known bugs and improve or add features testers have asked for. After another check with Core Developers for compatibility with the kernel, the reworked version is 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 -- including but not limited to United Methodist distribution.
Our work has been diverse and ecumenical from the beginning, and will continue to be. To date, we have trained and developed partnerships with Korean, Vietnamese, Spanish-speaking, Portuguese-speaking, Native American, African-American, Appalachian, Small-church, Afro-Carribbean, megachurch, homeless ministries, prison ministry and campus ministry constituencies in the United Methodist Church, as well as denominational worship leaders from The United Church of Canada, The United Church of Christ, The Presbyterian Church in Canada, The Episcopal Church, The Presbyterian Church USA and The African Methodist Episcopal Church; and we anticipate adding more constituencies and more denominations over time.
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.
Core Developers Consultation, Year 1: March 30-31, 2008
Core developers are diverse scholars, pastors and leaders with an expertise in liturgy. They met to develop proposed cores for rituals for baptism, Holy Communion, marriage and death/resurrection. These were shared with members of the Consultation on Common Texts and the United Methodist participants in the North American Academy of Liturgy for review, feedback and revision in beta and two release candidate formats. Final code freeze for all was October 15, 2008. You can find and use the cores here:
Final forms of the cores are stable. They will not be changed substantially for at least six years after introduction.
Developers Consulation, Year 1: November 13-15, 2008
Gathered developers for a writers' conference to begin developing ritual resources compatible with the established cores that speak from their communities of faith. Beta Releases: Beginning to roll out summer 2009.
Developers Conference, Year 2: April 30-May 1, 2009
A gathering of more writers and developers across a broader spectrum of the United Methodist Church and other denominations.
The 2010 Developer Meeting will continue to expand the project to more communities and denominations.
How to Get Involved
Interested in using and testing these resources? Here's how . . .
1. Join the Open Source Liturgy Project Wiki by registering at http://wikigbod.org/wiki. Registration will give you access to view and comment on all materials in the Beta and Release Candidate sections of the wiki, where developers post their work and core developers post their comments.
2. Download and use these resources, either from the OSLP wiki or from the Discipleship Ministries worship website as these materials become available.
3. Submit your comments in response to three simple questions about the resource: What works? What doesn't work? What could make this better for your context? You can post your responses either in the comments section of the wiki, or by emailing [email protected] and putting "OSLP Tester Review" in the subject line. We are asking congregations who test these resources to use them at least three times before submitting their final comments.
Interested in becoming a writer or developer in this project? Contact [email protected].