[CS-FSLUG] Church Management Software

[EnzoAeneas]

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

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)
I absolutely agree that security updates is outside of our scope for
the most part and that it is imperative that we make a commitment to
this once we get started.

kevin

On Wed, Mar 26, 2008 at 12:21 PM, Stephen J. McCracken
<smccracken at hcjb.org.ec> wrote:
> > 2. How simple can we make it? How close to the reach of non-techs do we
>  >> dare to place it? Can we at the same time keep it useful to serious techs?
>  >
>  > Making this an appliance might be overly expensive for the options. The
>  > typical church of this size could probably dig out a donated machine in the
>  > Pentium 3 or better range to act as a simple LAMP server with scripts to
>  > assist in its maintenance. Maintenance would include backup to a USB HD. The
>  > same box could have a single place to store files with the assumption that
>  > connecting to the network means access to the files (read: no permissions).
>  > I also think it should be designed using much available software. Ubuntu
>  > Desktop with as close to a default LAMP install as possible for example.
>  > This way, if some tech came in, they could easily understand what is going
>  > on and make modifications if needed (such as exposing Apache to the
>  > network).
>
>  IF an appliance-like solution is acceptable, I would suggest that the
>  proposed software would be a module/plugin to something already out
>  there and maintained--something like SME Server.  Then you offload the
>  burden of security updates and such to a larger/better maintainable
>  project/group.  You might also think about a project to go into Ubuntu
>  CE or the ichthux-ubuntu, if it is still alive.
>
>  It needs to be understood for the maintenance side of things that it
>  will serve nobody and hurt many if the initial coding enthusiasm dies
>  out in the maintenance cycle and the project dies after a year.  The
>  church you tried to sell on the software (it's open source!) that left
>  them hanging will give them a bad taste of open source.
>
>  Offload as much maintenance and security updating as possible.  To do
>  that would put it in as a plugin/module to something like SME Server or
>  as a sub-project of ubuntu-ce or the like. The SME Server I think
>  already had USB drive backup built in.  Offload the server upkeep tasks
>  to another project and concentrate on the program itself.
>
>  My 0.0128 euros
>
>  sjm
>
>
>
>  _______________________________________________
>  ChristianSource FSLUG mailing list
>  Christiansource at ofb.biz
>  http://cs.uninetsolutions.com
>