The technical infrastructure includes issues related to hardware and software.
Uses in communities of practice
Technical infrastructure issues may be invisible to a community until they create barriers that prevent or constrain participation. This category includes several different issues related to a community platform’s technical capacity. See “Cross-platform issues” for a discussion of technical issues around software, platform or data incompatibilities that also affect a community’s activities. Because they are a shared resource, the technical robustness of community platforms affects everyone. However, different members of a community will place different demands on those common resources, so attention is required for the community as a whole to live within its means.
- Together/apart, Synch/Asynch:
- The community platform’s software, hardware or operating system may constraint a community's choices in various ways. They all vary to meet requirements of cost, community size, the level of activity, and kind of activity.
- Hardware and related infrastructure requirements affect affordability, accessibility (e.g., some tools only run on one operating system), scalability (e.g., how large or complex a community’s site may become) and reliability. A system that feels slow can discourage its use.
- The volume of data (or bandwidth) that a tool or platform uses in order to support meaningful participation can constrain one individual’s participation (i.e., slow, dial-up connection) or a server’s performance, which affects everyone.
- Applications like Groove can require a lot of bandwidth, as can video or audio connections through an Instant Messenger. Some web-based platforms, for example, can switch be tween a graphics-intensive mode and a text-only mode that changes bandwidth requirements. Email is generally the lowest-bandwidth kind of community tool.
- Use of and adherence to open standards such as XML or SQL or “web services” is usually desirable.
- When community applications are built on top of widely-accepted standards, they are usually less expensive to own and operate and less expensive to modify.
- System extendibility or customizability depends on system design, underlying characteristics such as programming language. Features in this category range from changing background colors to changing system behavior or adding functionality. A host of issues need to be considered here, ranging from source code ownership (is it open source?) to source language and technical skills required for modification.
- Many communities modify or enhance their environment, either for functional reasons or to express their personality. And changes to a community’s infrastructure can stimulate new activity or interactions. A system may seem satisfactory at first but be a limiting factor later on (or conversely, it may not fit at first but be adapted incrementally to the community’s need).
- Customization resources can range from a series of check-boxes to extensive documentation to all the way to large communities of practice that discuss and support system modification. These resources determine how malleable a system can be and how costly it may be to change it.
- Controlling the way a system is modified, who can modify it, and how much modifications cost, of course, is an important community issue. It is usually desirable to delegate the ability to change system parameters to the lowest possible level but that always carries a cost in terms of technical complexity and user knowledge.