[CS-FSLUG] Church Management Software
Tim Young
Tim.Young at LightSys.org
Mon Apr 14 08:41:06 CDT 2008
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
More information about the Christiansource
mailing list