[CS-FSLUG] Church Management Software

[Tim Young]

Sorry I keep drifting in and out of this conversation. I occasionally 
skim an email or two in this thread.

Amazingly enough, you are all right about the various technologies 
(flat-file, database, web-based, etc.). Let me give you the brief 
history of this topic when it comes to missions donor databases, which I 
am in the middle of making one of...

A mission organization usually starts with something like 
quicken/quickbooks for their finances (flat-file). After a year or 
three, they find that they would like to keep more data, and that the 
structure they have is not scalable, so they move to something else. For 
quite a while they switched to a product called KMS, which was, at the 
time everyone was switching to it, based on "Paradox." Paradox was a 
database engine, but not a SQL database. Anyway, the main problem with 
KMS was that it did not do enough reporting, and because it was not SQL, 
they could not generate good enough reports with Crystal Reports (Nor 
was there or could there be much of a web interface). So people started 
migrating to SQL databases. Then, they have larger and larger systems 
based on "audience."

In actuality, most of the transition from one system to another was done 
because of two factors. Audience and amount of data.

While the primary audience is the one person, a flat-file system is the 
quickest and cheapest way to go.
When you start getting into a multi-user scenario, the flat-file system 
starts to break down somewhat. But it is the scope of reporting that 
usually causes grief soonest. A truly flat-file system is difficult to 
generate custom reports from. A good Linux admin can do wonders with 
Grep and WC, but we do not want to make pastors learn that detail of 
stuff to get at their data.
When you start getting into web-based systems (if people wanted to log 
into their church to see what they have given for the year, and to give 
gift online for their AWANA program) things get even more complex. To 
keep data integrity, (as well as the fact that most of these systems 
have a local and web interface) a database is usually required.

At LightSys, we are building using Centrallix (centrallix.sf.net), which 
is a web front-end to a database (there is a LOT more to it than that, 
but greater detail is not needed for this email). We realize that our 
donor management system is overly complex for an organization which is 
just starting out. But it will scale up for a great number of years, 
where most of the other systems get replaced after just a few years.

I think the first thing you need to do is to decide the size of church 
you are trying to target, and if you are looking at a single-user or 
multiuser system. Then, decide about security (flat-file systems do not 
have too much of that. Are you keeping credit cards info? How much 
giving information needs to be secure?)

Then, who will be programming this? Robert (who I went to school with) 
could put together a flat-file system very quickly. Micah Yoder (Who I 
have attended ICCM with) is a pretty high-powered web programmer who 
does a lot with SQL back-ends. But who else will be putting man-hours 
into this, and what are their skill-sets?

The fact of the matter is that the technology you choose will not make 
or break the system. It will dictate who gets to use it, but regardless 
of which route you go, some will use it and some will not. Earlier I 
mentioned the missions package KMA. KMA has recently gone opensource, 
and one could consider them "competitors" for our Kardia (kardia.sf.net) 
system. I do not look at it that way. What I have seen is that missions 
need choices. Every mission does their data a different way, and so 
there needs to be a wide variety in different types of tool. I would 
imagine the same goes for church software. Don't expect that every 
church, from the megachurch to the 15-person congregation will use your 
software. But, what you would be doing is making an option where there 
was none before.

Technology, like theology, can become a stumbling-block if we cannot 
agree. Sometimes the decision will need to be made on criteria other 
than pure technological merit, simply because we are not comparing 
apples to apples.

My original point was lost somewhere in the rambling above. I basically 
wanted to say that either flat-file or database would work. For me, it 
would be more a matter of who you have who will be working on the 
project. If you put most of your IO in one area, you can port it from 
flat-file to database fairly easily later on if needed.

Hope my rambling was somewhat helpful,

- Tim Young