A month or so ago at Gizmodo, a tech/nerd site (you BET I’m a reader!), one of the editors ranted against beta culture: the tendency of manufacturers of software/hardware to put out unfinished products which will then be “fixed” by software updates and such.
I’m tired of this. This sense of permanent discomfort with the technology around me. The bugs. The compromises. The firmware upgrades. The “This will work in the next version.” The “It’s in our roadmap.” The “Buy now and upgrade later.” The patches. The new low development standards that make technology fail because it wasn’t tested enough before reaching our hands.
Read on for how beta-culture is frustrating but can be an integral part of developing new ministries and tinkering with established ones in the Church.
For the record, I’m with anti-beta-culturalists (?). When I buy a quality product, I want it to work out of the box: no software updates or “new features” which should have been there in the first place. Sigh. I’m sure you have your own consumer horror stories of new products not working like they should. It *does* seem to be more pervasive now…
I think one commenter nailed it though, that the problem is that beta-culture is in the operating model:
Beta is just a way to shift R&D and testing expense to the consumer. Free feedback from users to increase profit margins. I wont buy a first model year car and wont adopt early technology for that very reason. Pay me to be your guinea pig or forget it.
Yes, it is frustrating that now we are the guinea-pigs for new products. But this is not all sunshine and puppy-dogs for companies. The problem with shifting beta-culture to the consumer is when consumers go too far with your beta product. Take for instance the case of Daniel-K, a consumer who was frustrated when a sound card’s drivers wouldn’t work under Microsoft Vista. He took matters into his own hands and fixed it, releasing the drivers on his website, and was sued, forced to take them down by the sound card company, Creative Labs. The resulting backlash from consumers and tech support caused Creative to drop the suit and release the drivers themselves as an update. The lesson is that if you encourage beta-culture, you may not like where it takes you.
So beta-culture is dangerous for companies and frustrating for newbie customers. What possible good can come from it? And what on earth can the Church learn from it?
Let’s move seamlessly from technology to church ministries. In some ways, we want the same thing for the church as we do for our tech products. We want our church “products” (ie. ministries and missions) to be complete and well-thought-through, glamorous and squeaky-clean. We don’t want to be a part of some half-thought-out ministry idea, do we?
We don’t have to! One of the things we looked at in our “What the Church can Learn from Wikipedia ” series is that seeing programs as processes (in process…essentially beta-culture) instead of products that need to be well-finished can yield higher participation and ownership from the community.
From the last part of the series :
In the church, we strive to be more like Encyclopedia Brittanica than Wikipedia. We bring forth ministry ideas when they are more like “products” we are pushing on people. We just show the storefront of the Church to people without the behind-the-scenes wrangling that takes place. We like products and people to believe in products and contribute to making products better.
And a quote from the first entry:
What if your church structure looked like Wikipedia and allowed for “rough” forms of ministry to try out? Untried, unfinished, possibly disastrous forms of ministry. Doesn’t that scare you? It should…can you imagine our reputation if we let un-thought-thru forms of ministry run amok? (*cough* like sponsoring Halo game nights, anyone?) But if Wikipedia taught champions of Nupedia that dedicated amateurs could be better than professional products, then can’t our ministry initiatives learn the same thing?
Take a look at those two sections of the series and comment there. The important part is that allowing beta-culture to take root in the Church can lead to innovation and new groups that find themselves newly empowered because they don’t have to be as polished as the Disciple bible study.
Again, the parallels between technology and ministry are inspiring:
- Look at the legions of people who work under Linux because they are part of a beta product. Where’s the Microsoft lovers? Table for two in the back room?
- How many people have edited a Wikipedia page? And how many people have written into Encyclopedia Brittanica telling them of an error? Yeah.
One of the commentors on the Gizmodo website nailed it for the church:
The flip side of the beta culture is playing it safe and putting out products that work flawlessly but are obsolete must more quickly.
If we want relevant ministries, perhaps forming a beta-culture in your Church is a good way to get fresh ideas flowing and stale ministries thrown out.
There are problems with Church[beta], of course.
- For one, people will disaffiliate for the smallest reason. A friend chose a Wii over a Xbox 360 over the Red Ring of Death. So any church program that is not flawless people may choose to disaffiliate with because “it’s just not run well.” That’s a risk….but on the bright side, it helps weed out the champions from the critics.
- For another, that sort of anarchic breeding may foster resentment between the church hierarchy and the laity that are inspired…again, from Daniel-K, the church may not always be happy with whatever ministries crop up. So a helpful process for working out tensions between the hierarchy and the popcorn ministries needs to be in place to facilitate the beta-culture process.
Your turn. What do you think?
- Is beta-culture a good way to frame church ministry development?
- Or is it just anarchy and shoddy versions of established ministries that nonetheless gets people involved?
Discuss.
As you allude, there are some real customer benefits to the beta culture, if managed properly. A feedback loop can help an organization build something that better meets that consumer’s needs. One of the tenets of open source software development is “release early, release often.” That’s not normally done out of a lazy avoidance of testing, but rather to get feedback from users on whether the developers are going in the right direction. If an active community exists around the software, this can be very beneficial. This approach has also been used successfully in publishing (see http://pragprog.com/).