I think there may be some implicit assumptions in what Priss is describing that I'm saying don't hold true for small workgroups.

The main question we're trying to answer is:
How is the nature of trust different for small groups (5-30) versus large groups (100s), versus gigantic groups? (10s of thousands)

The answer to this question is the key that will unlock the mystery of how to get small groups to use collaboration software (beyond email).

Assumptions for Beta/1.0 Ecosystem:
1. There is no IT department setting up a sharing service for the 'company'. (Calendars without IT is and has always been a main tenet of our product plan.)
2. In many cases, there isn't even really a 'company' or 'company policies'
3. You may not even be given a 'company' email address
4. Everyone knows each other in the collaboration group. In other words, there is intrinsic, unstructured trust. It would feel rude to give different people in the organization different grades of access privileges to shared workgroup information.
5. There is a real need for more than 1 person to collaborate heavily on a single item. The Stamping Storyboards sketch this out in great detail: 2-3 people collaborate heavily to send out a meeting invitation / agenda proposal.

Business Question. Would an organization like LPFI normally have such resplendent IT resources if it weren't affiliated with other geeky organizations?

In the end, it's not just a matter of small workgroups require less security than large workgroups. It's really that small workgroups won't work / can't work in security frameworks designed for large workgroups.

Here is a pre-internet analogue to our URL ticket situation:
A small business (a partnership that has anywhere between 2-10 temporary to semi-permanent employees at various times) has 2 phone lines. 1 is public-facing, for the business. The other is a private line for family, close friends and employees that are closer to the permanent end of the spectrum.

Both are phone numbers. The private line does not have a white list or a password. Both 'could' be passed out to the public in a way that renders the private line useless.

However, the private line, for the most part, remains private. Why? Because the group is so small that:

1. The members of the group have personal relationships with each other. Therefore, members have a vested interest in not screwing up those trust relationships by carelessly giving away information that was entrusted to them in confidence.

2. The shar-ER pretty much knows everyone they've given the private line number to and knows enough about them that when there is a leak, they could probably figure out who leaked the number. (e.g. Why are all of Kelly's friends calling for her on the private line?) The fact that this is possible gives sharees extra incentive to not violate / compromise their trust relationships with other members of the group.

As for when will the security framework change?
My personal take on that issue is: The security framework should change when:
1. We can make it more secure without making it more onerous for small workgroup users.
2. We are ready to target medium to large size workgroups that have different group dynamics and different trust relationships.

Mimi

On Jul 18, 2006, at 11:14 AM, Brian Moseley wrote:

On 7/17/06, Priscilla Chung <[EMAIL PROTECTED]> wrote:

We've agreed that the target user for Scooby 0.3 is an employee at
OSAF who is to update their PTO on the office calendar.

i agree with everything in this section. this is how i expect basic
shared calendaring to work in an office setting.

Planning for the Target Users at 1.0

Now let's think of it in terms of a visiting 'Casual Collaborator'
target user, someone who is outside of the organization and would
communicate very infrequently.

this is where you get into areas where creative solutions are needed,
but i can't really provide anything beyond the basic office shared
calendaring, which is all i've thought about in detail. all i can say
is that while i see the need for some level of anonymous interaction
with shared calendars, i'm worried about being too relaxed with
privacy issues.

One final thought. If we are consciously making the decision to trade
low security for higher adoption for now–when does enforcing more
security become a higher priority?

yeah, when? :)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to