[TOS] community based projects panel

[Mel Chua]

List seems complete to me.

> Many community based projects are open source projects, and many open
> source projects can also be viewed as community projects because they
> have deep impact on communities (Sahana is a good example, and is used
> in my very own community of NYC).

Sounds like you're making a distinction between local 
(geographically-based) communities and (possibly globally distributed) 
communities of practice (CoP)here -- maybe an opportunity to clarify the 
distinction, and the relationships between these two types of entities?

1. Local communities tend to serve immediate local needs.

They usually consist of local people who belong to different, sometimes 
globally-distributed, communities of practice; for instance, a library's 
board may include an english professor from the nearby college (who 
belongs to a statewite network of english faculty), a wikipedian (who 
belongs to the global wikipedia community), and a mechanical engineer 
(who belongs to a society of mechanical engineers). You could see any of 
these people tapping their broader CoP to help out that library.

They may have a need to use software to serve their needs -- means 
rather than ends. This means there's an opportunity to use, create (or 
better yet, modify) open source tools to serve these needs. This in turn 
means they'll get _tremendous_ leverage from having a few people in the 
local community be "ambassadors" to the "upstream" global CoP they're 
working with, because the local community's focus is *not* the 
software... but that global CoP's focus *is*. In our example, the 
library's core competency is being a great library for the town, *not* 
creating software to manage books; however, the Evergreen open source 
project's main competency *is* creating library book management 
software. These two groups can accomplish much more by working together 
(through an enthusiastic ambassador or two from the local library) than 
they could alone.

2. Communities of practice may be global (or they may not be), but in 
the open source context -- they tend to be centered around a mission 
that can be applied in many different contexts.

For example: "keep the web open and free for everyone" (Mozilla) 
"Rapidly advancing Free and Open Source Software" (Fedora) or "Make it 
possible for people who can't use a keyboard to do text input") (Dasher).

These CoPs, in the open source world, tend to be composed of multiple 
people -- each from a local context. I may work on software for a 
library in Ohio, you may work on software for a library in Tennessee, 
we've probably got lots of needs in common and might as well build 
something together that will work for both of us. (And in fact, that's 
how a lot of open source projects get their communities started -- the 
"wait, I have that problem too!" effect.)

I dunno if it helps for faculty members new to FOSS to think of FOSS 
communities as *way* less formal, make-a-product driven, versions of ACM 
SIGs, but that may not be too far off.

</more-of-an-elaboration-than-you-probably-wanted>

;-)

--Mel