My professional life has two parts to it; the first part is as a software developer, and the second part is as a missionary. Sometimes I get to combine the two things and write open source software that powers the work of mission; but other times I’m literally getting out there spending time with people who are interested in Jesus.
In other words, I’m an evangelist, and that’s a term that has a lot of meaning in the tech community as well. Bruce Perens and Eric Raymond were amongst the first to be called “open source evangelists”, and these days all the big companies and projects in both open and closed source technologies employ brand and product evangelists.
An evangelist is literally someone who spreads good news. I honestly don’t know how much reflection that tech evangelists regularly do about their own praxis, but I do know that the question of how to best spread good news amongst different groups of people has exercised Christian missionaries for many of the past centuries. When I was training to become a missionary, I spent a lot of time studying missiology, which is the academic discipline of reflection on mission. For instance, David Bosch’s comprehensive history, Transforming Mission, evaluates the motivations for, reflections on, and approaches to evangelism from day one up until the present, and you know what—you don’t have to subscribe to the tenets of Christian mission to benefit from them.
When I moved from full-time programming into full-time mission, I was surprised by how many of the concepts that the open source movement has pioneered can be directly applicable to mission. (For instance, the idea that worse is better is being played out in the house church movement at the moment.) And while, sure, missionaries are not doing as well as we could be right now at spread the good news that we have, I’m sure that there are plenty of things which apply the other way around too. This is the first article of a series of three which will look at areas where I think the technology sphere might have something to learn from the developments in missiology over the past two thousand years.
In particular, I want to look at a change in the understanding of evangelism which has happened in the missiology world in the past fifty years or so. For much of the 19th and 20th centuries, the traditional mode of evangelism was propositional and objective: the missionary’s religion was presented as a matter of absolute universal truth, something to be presented through logical coherent arguments (the discipline of apologetics) and then the listener was challenged for a response. One popular approach was even called the “Four Spiritual Laws”—the underlying mindset being that these propositions that, let’s face it, some evangelist came up with and turned into an evangelistic package, were as universal and incontrovertible as the law of gravity.
This worked well for—or at least, whether or not it worked well, it was an inevitable product of the kind of modernist worldview prevalent in the Western countries sending missionaries at the time.
And, switching disciplines, it’s been a very common way for people to talk about their software products. We roll out benchmarks, feature lists, and the like, to show that our preferred software project is better than the competition, from which it logically follows that you must adopt our technology because it is the superior product. Computers are the most objective things there are, and the people who work with them tend to appreciate that objectivity.
But recently there’s been a trend within mission practice away from that objective style of evangelism towards a newer, more subjective understanding; partly this has been due to the cultural shift from modernity to postmodernity, but more to the point, it’s because the older method had some serious flaws.
For one thing, there’s now more of a realisation that evangelism needs to be highly contextual. Let’s take my context, of Japan. Japanese people don’t really have a cultural concept of “sin”. But the Four Spiritual Laws and other strategies are framed in terms of sin. In order to make that work in Japan you have to essentially first convert people to your mindset in order to convince them that they have a problem they didn’t previously realise that they had. I mentioned that evangelism literally meant spreading good news, but this method relies on telling people bad news—they have a problem. You will occasionally hear evangelists in Japan saying that you have to persuade people of the bad news before you can tell them the good news.
The newer approach starts with a deeper understanding of the culture and the people, in order to discover the “felt needs”—the problems that they’re already aware of. Vince Donovan, in his wonderful Christianity Rediscovered, writes about a Masai man who had committed a sin against his community and had been ostracised. He did not need a lecture about sin; he knew about sin. What he needed was forgiveness and reconciliation with his community. Donovan began to share the stories of reconciliation through faith with this man and his community.
In this new approach, the story—the testimony—is paramount. It is no longer about logical propositions, but about the experiences of the individual, shared problems which have been overcome. The testimony essentially has three parts: this was the problem; then I did this; now the problem is solved. With an emphasis on story, there is a need for evangelists to have a collection of good stories to tell—points of contact between their life and the lives of their listeners. As they build a witness of stories, so they have the ability to share those stories with others.
How does this apply to open source? I’ve mentioned that when sharing the merits of an open source project, there’s often an emphasis on objective facts, rather than stories. But felt needs evangelism starts with the question “Why does this do that my target audience needs? What problem do they have that I have already overcome?”
To pick a random example, I just had a look at the MongoDB web site. I don’t mean to pick on MongoDB—they’re better than many others—but I have to pick on someone to illustrate this. Before the fold on the MongoDB web site, I’m assaulted with figures about the size of the community, the number of downloads, commits, and so on. Further down the page, I’m told that MongoDB “makes it easy for you to store data of any structure and dynamically modify the schema”, that it is scalable, has robust tools, and so on. Down at the bottom of the page there are some case studies, which is a great start, but even they are pretty vague—“we couldn’t do what we wanted”, more or less; “MongoDB let us do what we were doing faster and more flexibly.”
Nowhere, really, does it answer the question “What is this thing and why should I care about it?”
Here’s a story.
I took over maintaining a legacy application. It had five hundred database tables in MySQL, and really, it was only dealing with four core concepts. A couple of external consultancy firms had looked at the application with a view to redeveloping it and, I kid you not, they both refused to take it on. It was just too scary. Each table had its own model in the web framework, and it was a nightmare to understand how the application worked, let alone develop new features for it.
It took my team weeks to work out what all these tables meant, and even whether or not they were still actually in use. Eventually we realised that most of the tables in the database were there to work around the fact that those four core concepts were actually documents, with all kinds of different properties optionally attached to them. What we really needed was a way to store, retrieve and index these documents as documents, not as hundreds of different relations. That’s exactly what a NoSQL database gives you.
After we moved the application to MongoDB, we had four concepts, four database tables, and four framework models. We could throw out so much code, it was easier to start the application layer again from scratch because a huge amount of the old code was just joining associations together. What’s left is actual business logic, rather than database scaffolding. Now we have an application that our developers can actually develop with confidence, rather than fear and dread. Oh, and it’s also much faster too.
Problem, solution, result. Hopefully it’s a problem that other people can relate to as well—I think we all know the many-headed hydra Database From Hell. And notice that explaining the problem and the solution means that you don’t actually have to separately explain what MongoDB is and why it’s relevant, because that’s already taken care of. Not only that, it puts that explanation into an example and a context that makes it easier to grasp.
Now here’s an interesting thing. There’s currently a reaction against felt-needs evangelism going on in the faith community. Some of the reasons for this are not appropriate for Open Source, but certainly one is: there is a recognition that sometimes the solution is costly, and the evangelist who focuses purely on the felt needs but does not express the challenge and costly nature of the solution does not present their good news fairly. In the case of open source, it may be that migrating to a new project will provide the user with a speed increase, but the cost of migration may outweigh the benefits. In my example, tearing down the project and starting again with a clean implementation was obviously the right thing to do, but that’s not always the case. In another case, I realised that many of the queries we wanted to do with our database, but couldn’t easily do, would be much easier with a graph database; but the effort involved in transitioning from an RDBMS to a graph database would be much more than the gain provided by having those queries available.
One more thing: I remember one of my teachers telling me that, to be a good evangelist, you need to be a good atheist. Often the people you send out to evangelise your faith (or your project) are the people who are right at the center of things, but these kinds of people aren’t necessarily used to thinking about things from the perspective of, as it were, non-users; they’re not the best at understanding the needs and the problems. The best stories come from from your new converts—people who used to think about a problem in one way, and now think about it differently.
What’s the takeaway from all this for technology evangelists?
Next I’ll be writing about what it means to develop community, both in mission and in open source projects.Subject tags: theologytechnologyevangelismopen source