Open Development Models and Bible Translation
I have been reading Eric S. Raymond’s paper The Cathedral and the Bazaar. His particular interest is in how Linux was a different type of software development. I found a lot of interesting parallels with the Bible translation movement.
In the opening chapter he writes:
“Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.Linus Torvalds’s style of development—release early and often, delegate everything you can, be open to the point of promiscuity—came as a surprise. No quiet, reverent cathedral-building here—rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles.”
As someone involved in Bible translation, I most often see The Cathedral model of translating in operation. That is, a small group of highly trained individuals working in relative isolation on a complex multi-stage project. Ironically, the wizards and mages are working for the benefit of the populace.
Considering the current emphasis in missiological work on “local ownership,” should Bible translation projects look more like a cathedral or a bazaar? Most cathedrals I am familiar with are beautiful, cold and empty. But a bazaar is noisy, messy, chaotic and full of people. And people, by the way, are what Bible translations are all about. They are the ones who will use the Bible. They are the experts on the language.
How to make a Bible translation project “open”
What I’ve listed below are some ideas based on some of Raymond’s numbered ideas in his paper applied to Bible translation. I didn’t address all Raymond’s numbers that’s why there are missing numbers.
1. The project should begin by addressing needs of the actual intended end-users.
What do the churches or individuals need right now? Do the churches need liturgical readings? Are evangelists in need of tracts in a local language?
2. Modify the Scripture already in use.
If there is an existing church, they are probably using some translation of the Bible. If it is a neighboring language can it be adapted? If it is an antiquated translation can it be revised?
6. Treat local speakers of the language as experts and co-developers of the Bible translation.
7. Don’t wait until it’s perfect to get it into the hands of people who can help you make it better.
How many stages is your translation required to pass through before any actual speaker of the language can get their hands on a copy? If your organization is set up like mine there is a daunting list of requirements before anything can be provisionally printed and distributed. The result: few translations ever reach the users and by that time no one wants to make major changes. Ouch!
10. If you treat the people who evaluate your translation as your most valuable resource they will become your most valuable resource.
Community testing is the ugly secret of Bible translation. Nobody does it. Translators hate testing their translations. Because they don’t get feedback, the translation suffers.
13. When everyone involved thinks your translation is accurate and natural then it’s acceptable and you’re ready to do a major printing.
18. If your Bible translation is going to be interesting to people you must make an interesting translation.
I’m not talking about being eccentric just to get attention. But your translation must be interesting in itself: the story is fascinating (For example, Genesis or Revelations). Or, it is a novelty: “Amazing, this sounds like our language!” Or, maybe you need to consider packaging: color cover, audio versions, Scripture on bumper stickers).
Final comments
This is not meant to be a definitive text on “open development” of a Bible translation. Nor is it even necessarily an endorsement that this is what everybody should be doing. But as I’m thinking out loud and interacting with Raymond’s ideas maybe it will inspire you with some ideas for advancing the great work of Bible translation in our generation. I welcome your comments. If you’re a Bible translator, where are you working right now: In the cathedral or in the bazaar?
Good points, Lingamish! As a translator, I hope our team is working more in the bazaar but I have to accept that in some ways we are more cathedral-like. Yes, it is really hard to get translators to test their translations. But we are reasonably open with letting people get their hands on drafts.
But, since Raymond took his metaphor of Unix from the church, I would like to reapply it to the church. Are our churches, and I don’t primarily mean the buildings, more like the cathedral or the bazaar? I think they should be more like the latter. Now there is a place for large and beautiful structures, even physical buildings, but only if the need for them comes from below, from the people, not because some central authority imposes them. But the real life in the church is where things are untidy and keep changing to meet users’ needs, as in a bazaar.
Thank you David for this great, open, reflective reflection. As I follow and embrace the principles of the “open source” community, I have often wondered why the Christian community is disengaged — or at the very least — quiet bystanders during this seismic socio-cultural shift. The Acts 2 community was a dynamic, communal place where everything was held in common for the benefit of the whole group.
It seems to me that the Christian community ought to leading the open source community, rather than followers long after the principles and ideals have been established and ratified.
Yet, having said that, we must come to terms with the great potential dangers inherent in the open source movement — most notably quality control. When it comes to the Bible, this is especially worrisome. I am reminded of Redd Foxx who said; “Be careful of health food cookbooks. You might die from a misprint.” Concern and caution are rooted in a fear that spiritual death may result from shoddy work.
Yet, Wikipedia continues to demonstrate the power of community. I have a friend who submits bogus articles, or inserts himself into important articles (like a text version of Forrest Gump) and then watches to see how long it takes for them to be corrected. Sometimes it is a matter of minutes.
Buried in all of this discussion about biblical translation are our theological presuppositions concerning the nature of man (we are sinners) and a fundamental distrust of the motives and intentions of people. The “Cathedral” mages have degrees and books we can scrutinize to see if we ‘agree with their theology’ as a means of granting us comfort that their work is trustworthy. The bazaar may have contributions of some with ‘unwashed hands.’ Yet, the process seems to yield an excellent product (at least in the linux world).
The big question, in my mind, is “Does the prinicple of open source development translate … to translation?” Will the principles hold up in a real world application of Biblical translation?
I suppose it will be pioneers such as yourself who will answer these questions … if you are willing to take the initial risk and put the project out on the web in a search for willing collaborators.
May God guide you into insight and understanding as you reflect and grow and serve.
In Christian Brotherhood,
Jonathan Mills
Pastor of Discipleship
Kanata Baptist church (Kanata, Canada)
http://www.kbc.on.ca
Thanks, Jonathan for the cool comments. Open development continues to inspire the way we work in Africa. And we are also learning cutting-edge ways of working from Africans themselves.