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
_______________________________________________
tos mailing list
[email protected]
http://lists.teachingopensource.org/mailman/listinfo/tos
