tailoring usability to our purposes and audience

some of our target users are not technically oriented, and will be thwarted by an obscure or complicated interface.

this emphasizes the need for developing services clearly directed at the identified purposes, and user interfaces that are simple without overshooting to simplistic.

scaling coordination

this service could be very useful and grow in sudden leaps. scalability would need to be anticipated in a fundamental ways.

by explicitly identifying protocols and policies distinctly from the implementation, the services could be provided by anyone that conforms to the expressed policies and protocols.

consider the system as being constituted by:

• the reliable establishment of known parties - local members, posting members, and activity communities (grouping members at various scopes)
• the policies for conducting, tallying, and distributing the proceeds to fund ongoing maintenance and growth, as well as for member privileges and constraints
• the services that are based on that foundation.

this formulation provides a trajectory for extensive scaling. (it also motivates a design particularly amenable to portability and interoperation across diverse implementations.)

we will develop the protocols and policies, ironed out in a prototypical service. when the service formulation stabilizes and our instance of it grows to the point of abundance, we will offer the opportunity for others to participate in our ecosystem. others will have the opportunity to provide their own instance of the services, using our code and/or code they develop themselves, and grow their own community sectors. the scale of the service offering would then be limited only by demand and the extent to which the communications for identification and notifications can be federated.

this decouples the costs of presenting content for each local group from the costs for providing for coordination between and across groups. further, central sites can act as umbrellas for activities spanning large regions and including many groups, without, themselves, absorbing the costs of coordinating those groups. it would only be the communications necessary to conduct the coordination - federated authentication and authorization, communication of relevant audience, and communication of burden incurred - which would involve costs proportional to the sizes of the regions, and those costs would, conversely, be independent of stored content. those distilled costs could be tracked by dedicated system components, providing the glue for coordination.

this concentrates the focus on ironing out policies and protocols to support an authenticatable, sustainable, scalable infrastructure, to form the basis for opening the door to federated service providers.

scaling revenues

the growth in cost of actually providing the services could outpace the revenues if the fees are set too low. conversely, setting the fees too high would chill the coordination benefits, working against the central value proposition.

by decoupling the content and communications infrastructures, as described in `scaling services`_, the costs for maintaining content sites is just that for content management, while the costs for distributing notifications those for the content management services necessary for each group. similarly, sites which con up to large groups are primarily just those

the revenue structure will probably require experimentation up front, and may require progressive adjustment as time goes by. premature commitments to a particular fee structure must be avoided, to prevent locking in to an unsustainable revenue model.

privacy

maintaining membership will entail various privacy concerns. some of those concerns can be very demanding. we need to approach all those issues deliberately and with open eyes, picking and choosing the obligations we take on and those that we can defer to other agencies (eg, online payments).

scaling abuse prevention

the high-interest audience and low cost of entry for notifications will eventually attract attempts at off-topic notifications. some provision will be necessary for effective self selection and/or screening of those producing notifications.

this is addressed by a number of measures.

two kinds of parties will have access to local distributions: local members and those paying for wider-region distributions.

postings by local members to their local group can be regulated by ensuring that the members are known to the other local members, and offering mechanisms for regulation of postings by unruly members. this can be achieved by enabling local groups to have the say about accepting new members, and enabling them to elect for moderation to postings by local members, en-masse or per-member. this all suggests having distinguished local members responsible for administering the group, including the ability to endow any and all the other members with authority to do that administration.

for wider-region postings, the fact of any fee at all will prevent the vast majority of trivial spam. the fee will provide a disincentive for spurious messages, properly increasing in proportion to the scope of the distribution.

for those willing to take on the overhead of an account by which they can pay the wide-distribution fees, the clear identification necessary for a paying account provides a basis for answerability. based on that identification, a web of trust can be used to qualify posters for moderated or unmoderated posting privileges.

new posters are subject to moderation until they prove themselves, or can appeal to members with unmoderated posting privileges for endorsement to get unmoderated privileges, themselves. if they abuse those privileges, they and their endorser become subject to moderation, and possible range restrictions.

payment of moderators, to tend those rare cases where moderation is necessary, would be one of the system's overhead costs. members and employees would be eligible to moderate, and paid some modest amount (with the option to take payment in the form of posting discounts) per moderation. moderators that let inappropriate postings through, as signaled by feedback from the membership readership, would lose moderator privileges.

proportioning content management investment

the content management needs of a grass-roots community may be modest, but providing adequate and easily usable facilities can be a morass. on the one hand, using systems that are near but not quite tailored for the purpose can lead to baroque and awkward systems, neutralizing the usefulness of the services. on the other hand, custom tailoring the facilities using a content management framework can be exceedingly extensive work.

we will need to do a few things to mitigate this risk:

• come up with realistic requirements clearly distinguishing what is necessary for the near term from what will be necessary in the long run.
• separately assess and identify the platforms that would be most practical to implement the near and long-term requirements, if they're different.
• allow for shifting implementation from one platform to the other eventually. this is instead of trying to make the sufficient long-term platform upfront.

all this is aimed at focusing energy on picking the best tradeoffs for the near term, while keeping in sight the transition to the long-term solution, and avoiding getting caught in the quagmire of developing a perfect content management system up-front.

managing project scope - trying to fly before we can walk

the prospective services could be very useful, and it is particularly tempting with things that would be personally useful to go overboard. in fact, the breadth of the functionality - including notification to coordination to content management to membership and identity management - could make it hard to arrive at clear, sufficient limits on the depth covered in any aspect. this is a "wealth of riches" kind of risk, in that there is so much worth doing well that it could be hard to see how to get enough going to make it useful at all.

i believe the key to this risk is seeing it as a bootstrapping problem - and, in fact, opportunity. if the services truly would be so useful (if well realized), and the business model is open enough that others could participate in revenues proportional to contribution, then we should aim at implementing enough to convey the value and make it useful and usable for our trial audience and for developers of the system. in this way we can create a platform for attracting and coordinating the efforts of a community of developers interested in helping to grow the functionality as well as the use.

this approach suggests carefully ironing out the core functionality, including extensibility (in scale and function), and continuing a policy of transparent and detailed documentation of the project, to enable more developers and users to progressively join and grow the effort (as suggested by the Zope Fishbowl process).