Head over to http://church.io to see the new site...

We've moved off of Posterous, so your email-based subscription will no longer work.

I wrote in Church Software Continuum that I think software tools for engagement are missing. You could argue that it's more a matter of confusing and/or ambiguous terminology. Regardless, I think current tools do a poor job of helping shepherds to connect with visitors and members.

I don't want to build another rigid Church Management System. Instead, I want to build a Church Engagement System that deals more with people and connections than anything else. The differences may be subtle, but the result could be profound.

Over the next few posts, I'll be giving a broad overview of what I think will make this system different from what's already out there. First, rigidity vs flexibility...

Church management deals with data points that tend to be rigid. I envision a system that deals with engagement being more flexible:

Let me explain a few of these ideas...

Approximate Dates

The ability to enter an approximate date or timeframe in addition to known, exact dates. 

• Jane White volunteered for college ministry in August 2011.
• John Smith hasn't been seen at church in about three weeks.

The idea is to encourage data entry that may help ministry, no matter how incomplete/imprecise it may be.

Tags

This may not need much explanation, since many web apps organize things with tags and their use is more and more commonplace.

Tags can be used to organize people by:

• class and small group
• age group
• interest
• geographic region/campus
• more?

Tags are generally more flexible because they can be created on the fly and aren't restricted to a hierarchy. Given good tools for querying and manging tags, I think their use can aid ad-hoc grouping and discovery.

A more specialized type of tag is a "flag", which we'll discuss next...

Engagement Stream

I want to take the Facebook-style activity stream and turn it on its head -- The Engagement Stream will list connections that need to be made and ministry needs sorted by time, from the present at the top into the future as you scroll down the page.

How do people make their way onto this list? That's where "flags" come into play -- people get flagged by leaders and staff and volunteers in various ways, which causes those people to be added to the engagement stream. Think of it as a sort of to-do list for ministry.

Some flags may be very manual, such as "contact-needed" and "hospital-visit", while others can be automatically created by the system, such as "three-week-visitor-followup" and "new-small-group-leader" based on other interactions with the app.

Some flags represent high priority needs, causing those connections to bubble to the top of the list.

I think flagging and the Engagement Stream will be an intuitive way for leaders to recognize and make connections, since the idea of streaming activity is already well known thanks to Facebook and Twitter.

Lots of Users and Lay Leaders

My vision doesn't stop with office staff and ministers; it extends out to all kinds of leaders, Sunday School teachers, small group leaders, and more. This tool will be as powerful (or more powerful) for lay leaders who are engaging with their own sphere of influence.

Since this tool's main focus is on action (the present) -- not data (the past) -- we can extend the tool out to lots of people with more openness than a traditional ChMS.

...

This is just some my ideas. I won't pretend this alone is a game changer; execution and user experience will be just as (or more) important.

Thanks for reading, as always. If you have feedback or ideas, please post a comment here, catch me on Twitter (@seven1m), or let's discuss in the IRC room (#church.io on Freenode).

...and, we're back.

I feel bad that I started this blog, got people excited, then fizzled out for nearly two months. I'm sorry; I got a new day time job, and it took me a while to settle into a groove.

That, and I had some decisions to make with regards to my other software project. OneBody is my five-year-old Ruby on Rails app and commercial SaaS that attempted to solve all the wrong problems. Well, not really all wrong, but probably mostly wrong (more about that in a bit).

I built OneBody as a social network, perceived by many as a church-flavored Facebook competitor. Then, in ignorance, I started to morph OneBody into a sort of Church Management System. And by the time I had written thousands upon thousands of lines of code, I realized (a little too late) I was writing software no one needed and no one knew exactly how to use.

I'm not beating myself up too much here -- I wouldn't trade the experience for anything. I've learned about how to (and how not to) manage an open source project and how to run a business.

But the biggest lessons I'm still trying to put into words, and that's probably where Church.IO comes into play the most.

Lessons

You see, in this blog, I speak as an addict. I am indeed one of the engineers/product designers of whom I have spoken most in my previous two posts. My hints at Software Predetermination are based completely in my own experience.

Perhaps it isn't fair to project my experience onto other projects I know little about. Kingsley Allen commented on my last post, saying:

You describe a from-scratch ChMS creation process that I hope does not happen often in the real world today. A contemporary, mature software creation process is not bottom-up. You start with the problem you are trying to solve, design the solution to the problem and the experience (UX), and the rest falls into place to support it. The database is not the starting point, it is shaped by the solution.

Fair enough. I hope that's right.

Still yet, I want to explore the limitations imposed by building software on top of a relational database and what kind of (different) types of software one can build on a NoSQL or Document Database. What sorts of issues, if any, does such a foundation eliminate, and what problems does it create?

And, with that, I need to come full circle, back to my project OneBody. For all intents and purposes, I have shut the project down in order to focus on the sorts of software I've talked about in this blog. Sort of...

A Niche

I've realized also that there is a small part of OneBody that I don't want to completely throw away and may actually be useful to thousands of churches across the world -- an online directory. Not a replacement for Facebook, but something to work alongside it and provide an umbrella for any church or close-knit community to search and connect with one another outside of the noisy and busy world of Facebook.

So, I've created Church.IO Profiles in order to preserve that one good part of OneBody. This new project aims to be a very small Rails 3 app that uses Facebook for login and allows fellow church members to see and connect with one another easily.

Profiles may not be necessary at all if Facebook just had better and easier-to-use Groups functionality. Until it does, I hope to fill that niche with a church bent.

Our Dev Community

Further, I feel like the OneBody project had a community of developers who wanted to jump in and make the software better, but couldn't figure out where to start. Profiles is a continuation of this community, with fresh code.

I want to nurture this community. Down the road, I'm hoping this same community, bigger and stronger, can help build the engagement software I really want us to build.

So, that's it for now. My plan is to continue to discuss church software here while promoting community around Church.IO projects, namely Profiles at the moment.

As always, your thoughts are welcome here, and on Twitter @seven1m. I've also created an IRC chat room on Freenode called #church.io (webchat here). I should be there most days if you want to chat.

In speaking with Christian software engineers on Hacker News and last week's blog post about better church software, it’s clear that the term "church software" is nebulous at best.

I need to back up and actually define what I mean by "church software." At this point, the three main categories I'm interested in are: Church Management, Social Networking, and Engagement. (I'm ignoring worship planning, bible study, and several other pieces that I tend to see as separate tools that fall outside this particular continuum.)

Here they are in a crude attempt at juxtaposition:

This use of a Venn diagram isn't perfect, and I've likely forgotten some features. The point isn't necessarily the exact features, but rather the big picture, and how the everything fits together. Also, I understand that most church software doesn't fall in any single category above, but rather starts out in one and then purposely begins to creep into the other realms one feature at at time.

Let’s survey the landscape...

Church Management is served by hundreds of available tools, ranging from free to, well, expensive. Capterra has 184 products listed in this category, at the time of this writing. Yikes!

It seems this is the default category that comes to many people’s minds when I say “church software.”

Social Networking is already dominated by Facebook, Twitter, and regular ol' email. Google+ is becoming another contender. Then there’s The City, The Table, etc., creating private social networking opportunities for churchgoers.

There’s an abundance of social networking options for people, all competing for attention. Churches have some tough decisions to make about how to address this growing, confusing realm and how best to serve their members.

Then we come to Engagement. As it turns out, this is not a popular term for church software to identify with. A Google search for "church engagement" returns no tools or products. I tried lots of other phrases, such as "connect with churchgoers" and "get more church members" and "church growth tools" — each gives me virtually nothing but books and blogs and opinions — few, if any, tools.

Why is that? Well, it appears that engagement is something that gets lumped in with the other two categories of church software.

Sure, that makes sense. I mean, the chief purpose of a church is to draw people to Christ, improve people’s lives, make disciples, and to survive and grow as an organization. It makes sense that church software should aid with all those things as well.

The problem I have with that, however, is the order in which those needs are met. Let me explain...

With a ChMS, engineers start with a relational database with empty columns and rows. Before the engineer can think about tooling the software to address engagement, he must first build up the infrastructure to enter data. But by the time the software is ready to get a single engagement feature, the foundation has already been set. The starting point establishes the tone and the purpose of the software.

I’ll call this sort of thing Software Predetermination and will go into more detail in a future blog post. For now, I’ll just say that most current ChMS is built for management first, engagement second.

As for Social Networking, things are more complicated. This paragraph is the hardest for me to write, because I desperately want products like The Table to succeed where my OSS project didn’t. In all honesty though, I think any tool that requires the bulk of your members to commit to a church-specific social network is up for a major battle in the minds of regular people.

While The Table and The City aren’t necessarily competing with established networks like Facebook and Twitter for dominance, they are competing for cooperative mindshare. And for there to be engagement in such an environment, people have to regularly use these alternate social networks — the engagement piece, if embedded within and dependent on a closed social network, is limited by the adoption of said network.

I’ve concluded, at least within my budget and time constraints, that building a tool that integrates with existing social networks and leverages their social graph is key.

As for engagement being a separate category of church software, it’s one lonely green circle, I admit. But since I want to create a tool that solves the right problem, making engagement separate forces me to:

1. Think of engagement first.
2. Build with the proper foundation.
3. Integrate with existing social networking tools, rather than create another one.

I suppose it’s a matter of principle (mine) that I have deemed three separate categories of church software, because I want it to be that way — not necessarily because it is that way. To me, engaging members, visitors, and reaching out to the community is the reason I want to write church software.

I’m stopping here; these are my thoughts for today. Let me know yours. I hope that by defining the terms and surveying the marketplace, we’ll be starting from the same place in terms of what sort of ideas I intend to share over the next several weeks.

Until next time...