[CS-FSLUG] Church Management Software

[EnzoAeneas]

On Wed, Mar 26, 2008 at 1:58 PM, Josiah Ritchie <josiah at ritchietribe.net> wrote:
> On Wed, Mar 26, 2008 at 1:50 PM, EnzoAeneas <enzoaeneas at gmail.com> wrote:
>  > The software shouldn't be dependent on a dedicated server being
>  >  available or even a server at all; that being said, it should be able
>  >  to take advantage of the increased capabilities of a dedicated server.
>  >
>  >  This would give us two primary flavors:
>  >
>  >  1. desktop: able to update peer2peer, to web, file share
>  >  2. server: interacts with desktop client or provides web-interface;
>  >  best for larger# of users
>
>  I think this introduces a complexity to the end user that we should
>  try to avoid. Additionally, having a desktop version will lead to end
>  users installing it on desktop machines. I don't think it is in the
>  "kingdom's" best interest for this to ever happen for security and
>  stability purposes. It is a common mistake we should try to direct
>  away from.
>
Unfortunately, many churches do not have the budget or resources to
properly separate their computing functions or even setup a network.
Most do not have a simple webpage.
 A desktop version would be simply a more tightly controlled version
of the server.
We would keep most if not all of the power of the server
implementation without scaring those without members who are as
interested in the technical aspects as we are.

while I do agree with you that having church business on desktop
machines isn't the best idea, most churches do exactly that and
without thinking about security. It's the convenience that the tool
yields to their other activities that is important, not the
implications of how they use it and that is unfortunate.

>
>  >  Data should be able to flow from one flavor to the other in a
>  >  reasonable manner (we would have to determine the what that means)
>  >
>  >  For distribution there are more options
>  >  1. rpm/.deb/ubuntu .deb packages for Linux complete with initial set scripts
>  >  2. .exe / .msi installers for windows
>  >  3. Virtual machine image or pre-packaged Virtual machine
>  >  implementation (only runs our
>  >     software)
>
>  This represents more complexity still. As soon as the end user see
>  deb, msi, or virtual machine, they are sure to get confused.
>
I think that we should maintain some appeal to those who do know what
they are doing. I believe someone said something similar to this
earlier. The multiple options would allow it to integrate into many
different setups without the sacrificing the functionality. not to say
that all of this is necessary or should even be available at release
1, but the availability of options and flexibility of implementation
and usage is another reason why open source/free software is
attractive to many. That being said, we do need to minimize confusion,
so we can simply present our one or two options as "the option". The
advanced stuff will still be accessible, but won't be presented
upfront.

 I  know I sound like I am getting way ahead here and I am, but having
such things in mind helps greatly when planning something of this
scope.

Anybody agree? disagree? Let's get more voices in this discussion!

Kevin