[Ldsoss] Scout Tracking

[A. Rick Anderson]

Manfred Riem wrote:
> Hi there,
> 
> I think we all know this. The problem is really how the Church wants us
> to proceed in this. If we want an 'open-source' project to be used within
> the boundaries the Church has to abide by we need to know those boundaries.
If I am mis-understanding the intent of LDSOSS, please feel free to help 
me have a better understanding, but nothing I have read on the Wiki, or 
this particular thread indicated that the "Church" gives two-tinkers 
darn about this particular endeavor.

One poster indicated that the church is actively  discussing the problem 
domain (i.e. tracking advancement in Scouting/Youth programs), but that 
is a very different situation then assuming that whatever a group of 
people involved in this thread decide to implement is either blessed by 
the church, or will be sponsored by the church.  If the church did some 
or all of an OSS project for use on the official Ward Websites, then 
IMHO, my comments about the security elements are even more valid!  It 
won't matter what this group does in terms of security.  The church will 
either re-code it, or remove it to fit their internal policies.

I have been a scout master.  I share the pain of the original poster. 
Any scout master in the world would love to have a secure, online 
solution that only requires a browser to access.  But a global solution 
won't happen on the first iteration unless the church or BSA is willing 
to formally sponsor such an attempt (don't hold your breath).

In the meantime, members of this list could begin developing a solution 
that works for either a single BSA unit in a disconnected mode, then in 
a connected mode, and then works for multiple BSA units in a secure 
manner.

Once you move past your desktop, the assumption of a shared server is 
that the person managing the server is securing the sensitive 
information.  Once again, the security issues can be solved in stages 
and iterations.

Nothing drives out _real_ functional requirements like POC's, and 
iterations.  Nothing kills innovation and brainstorming like a lawyer 
talking about liability and privacy invasion.
> 
> I for one know there are a lot of boundaries based on the various countries
> the Church has a presence in. So to just dismiss it as something we
> shouldn't be discussing is like sticking your head in the sand. The
>  structure of the security is not being discussed here, but the boundaries.
I was responding to the assertion that any solution being developed has 
to support enterprise security at the application level from the first 
iteration and that we would have to get signed, notarized permission 
slip from every parent and child or the men in black would be at our doors.

> 
> BTW Linus didn't create Redhat it is just one instance of a Linux distro. 
You are absolutely right!  Thank you for making that point crystal 
clear.  It was possible that someone would have mis-interpreted my 
reference.  My point was that if Linus had attempted to implement all of 
the features added to the kernel over the last 15 years in the first 
iteration, Linux, as we know and love would have never have happened.

Solve one problem at a time, and iterate.  In fact, iterate fast!  See 
Eric Raymond's original treatise on The Cathedral and the Bazaar at 
http://www.firstmonday.org/issues/issue3_3/raymond/ or 
http://www.linuxtoday.com/news_story.php3?ltsn=1999-08-01-001-10-NW-CY.
...

> -----Original Message-----
> From: ldsoss-bounces at lists.ldsoss.org
> [mailto:ldsoss-bounces at lists.ldsoss.org] On Behalf Of A. Rick Anderson
> Sent: Wednesday, June 07, 2006 10:23 AM
> To: LDS Open Source Software
> Subject: Re: [Ldsoss] Scout Tracking
> 
> There are fundamentally two architectures.
> 
> Standalone and online.  Any discussion we can have about the merits and
> demerits of both have been repeated ad-nausea for every application since
> the birth of the Internet.
> 
> If we try to boil the ocean on the first pass, the project is doomed from
> the beginning.  Can you image what would have happened if Linus Torvalds had
> tried to release Red Hat as a replacement to Minux?
> 
> Get something that works well and that installs well on a local machine. 
>   Refactor it so that the business tier, the presentation tier and the model
> tier are distinct.
> 
> Drop it on a disconnected appserver and add an additional presentation tier
> to prove that the refactoring is sufficient.  It won't be, so count on
> additional refactoring.
> 
> Now you have a functional solution that is worth debating
> security/privacy/convience issues about taking online.
> 
> The worst case scenario is, you have a solution that works for you, and that
> others can install and that will work for them.
> 
> Pushing security concerns into the application logic itself, is IMHO,
> absolutely poor design!!!  Security and security policies are cross-cutting
> concerns that should be done declaratively in a security policy manager, or
> at worst, in the appserver.
> 
> As a ward member, do you really want to have to log in and validate against
> every piece of functionality restricted to members on the church website.
> Ex: Once I log in once, switching to the ward webmaster mode doesn't require
> a new authentication.  Why?  Because the authentication is done at the
> middleware layer, not the individual application layer.


-- 
A. Rick Anderson