I’ve thought on a few occasions that there’s a big crossover between what I used to do in Open Source and what I now do in Church work. As a really good example, I’m currently taking a course in “building transformational communities”; meanwhile, Skud is writing a series of blog posts on the craft of community and putting together a community management wiki. If we can get past the “weird geeks” and “annoying Jesus freaks” stereotypes, I’m positive there’s a lot of good stuff we can be teaching each other.
Another example comes from evangelism. There’s a whole group of people who describe themselves - sometimes their employers describe them - as “open source evangelists”. Jim Grisanzio would be one. Now, we’ve been doing the “evangelism” thing for quite a while, and we happen to have some ideas about what works well and what doesn’t. (Actually these days, we seem to have lost the plot, and maybe we can learn a lot from the open source evangelists.)
I write this because something caught my attention this morning. Like many in the Perl community, I’ve heard many people shouting about Moose for a while now, and my thoughts have been basically “Yeah, interesting, but I prefer Perl.” But that’s mainly because of the tone of Moose advocacy.
This morning I read Yuval’s post on roles, and was really impressed by this style of advocacy. The style is, basically:
- Show a real problem that programmers have right now.
- Show an elegant way of solving it.
- Don’t go on about it.
Because much advocacy (and I’m sure this is true in general but I’ve noticed it particularly with Moose advocacy because that’s what I’ve been coming across on the Perl blogs) assumes that the programmer is really interested in finding the One True Way to program, it often doesn’t connect with what people are really struggling with. Actually I don’t really care about the right way to do it because the way I’m doing it at the moment works fine for me.
Yuval’s approach is the opposite, bottom-up rather than top-down, solving a simple problem rather than giving the big picture.
In the faith world, we call this style “felt-needs evangelism”. For a long time, Christians approached evangelism kind of like the Moose advocates do: you’ve got a big problem (sin/suboptimal code) but you don’t realise it yet, because the categories are so far outside your experience that you’re not tuned into them, so my job is to drum into you the reality of a problem you don’t know you have, so I can then sell you the solution.
The result is that if people get it, they really get it; but most of the time they won’t get it, and they’ll get pissed off with you for trying to, essentially, make you have a problem so that they can fix it for you.
Felt-needs evangelism, on the other hand, starts by finding the problems that people are facing at the moment, and offers solutions to them. It’s more attractive, because it connects immediately. The big all-encompassing fix can come as part of that, but actually people are far more interested in dealing with problems in their lives or getting useful programs written than accepting a whole new way to do things.
There’s currently a reaction against felt-needs evangelism going on in the faith community; some of the reasons for this aren’t appropriate for Open Source, but certainly one is: there’s a recognition that sometimes the solution is costly, and you’re selling someone short if you just tell them about the warm fuzzies but not about the pain they’ll have to go through to implement the solution. A brand new language might solve this particular coding problem that I have, but reimplementing all my code in a new language is going to take time and pain and I have to count the cost - and it might not be worth it.
But especially in (frankly) quite a selfish world, and one which is suspicious of big all-encompassing narratives, felt-needs evangelism can connect a lot better than One True Way evangelism: Yuval’s blog post is more likely to make me look into Moose than anyone else’s.
I wonder what other crossovers there are; I’m sure that areas of community-building, advocacy and the like are very similar between the two disciplines, and that we have a lot to learn from the open source community, and hopefully we have a lot to share with them as well.