= Payment Plan Proposals =

Different ideas have been proposed about the best way to adjust member fees.  This page will contain a summary of the plans that have been proposed.  When adding or editing a plan here, remember that HCoop will have to 1) cover an increase in operating costs during our migration to a new infrastructure (although nearly all of the hardware that we need has been donated at this point) 2) figure out how to adjust costs on a longer-term basis once membership increases.

With that, the proposals (in alphabetical order, please update if you change the names of the plans :) ):

== Flat-Rate ==

=== Description ===

Each member pays the same amount every month.  Feature sets and bandwidth allowances are basically what we can support given our software tools and what our colocation plan gives us.  Member sites may be re-evaluated at any time if their bandwidth or disk usage increases dramatically, and the cooperative at that time could decide to either charge the member more for their higher utilization or subsidize the site with existing member dues and resources.

This plan recognizes that some members may leave because of a temporary increase in the flat-rate price during our migration to a new infrastructure.  For this reason, the plan can be modified for a short time to allow donations by some members to subsidize the dues of those who can't afford a higher flat-rate until the membership increases to allow the cooperative to once again be affordable for all of our members.

In this plan, the membership rate would settle (post server-migration) to something that included a budget for concrete operating costs as well as a fund for repairs and upgrades.

Although this plan would be rather expensive for a few months compared to commercial offerings, our quality of services should be higher because of the better-quality hardware and bandwidth that we will have access to.  Additionally, we already offer a broader feature set than most commercial offerings and will continue this in our new infrastructure.  Finally, it is felt that after prices settle, we could reduce our monthly costs to something that most members could accept, in the range of $5 - $8 per month, US.  The exact rate that we settle on would be TBD at a later date and able to be revised later to reflect changing operating costs and estimated future expenditures.

=== Pros and Cons ===

 * Pro: all users have the full set of features that they may need to develop dynamic web sites from the beginning of their hosting services.
 * Pro: allows the cooperative to either subsidize sites that benefit the internet community or which may draw desirable traffic to the cooperative.
 * Pro: Avoids hierarchy and therefore elitist differentiation of user services.
 * Pro: As our systems scale, we will have to worry less and less about what are already trivial differences between user system utilization.  In our new infrastructure, it will only really be noticeable when one site is experiencing thousands of hits per hour more than the others on a sustained basis.  This means that a flat-rate program would add simplicity and elegance to our offering.
 * Con: Essentially regressive.  Members with the least usage and potentially the least ability to pay subsidize members with above average, even grossly excessive usage.  You could also argue that this point is not really a substantial critique of the flat-rate program, because a) the flat-rate program allows for re-evaluation of certain sites that may have "grossly excessive" usage (probably in the sustained, hundreds of hits per hour range) and b) only a very small percentage, if any, of our sites would ever fall into this range.  So, it should be thought of not as lower usage members "subsidizing" the higher usage ones, but as a system where all members pool their resources for the best outcome for everyone.  Remember that as we improve services, low utilization and high utilization members receive benefits in terms of increased reliability and responsiveness of systems.
 * Con: Lowest usage members may leave for services that provide better value.     This may not be a very strong "con", though, because we will offer several services that benefit low and high usage members.  For example, a) our colocation at Peer 1, which is a top-tier provider on redundant internet connections, b) our user expertise and strong support community and c) the fact that we offer more flexibility than any commercial offering that I know of, along with the ability to host multiple domains on one account (this may be exclusive to high "usage" members) and d) The fact that we are working on providing truly redundant services, backups, and security, there are really few, if any, commercial offerings that would offer the same value that the cooperative will offer in the new infrastructure.  So, even for those who have low usage, I think that it would be hard to find a better "value" elsewhere in terms of commercial offerings.
 * Con: Some members simply cannot afford "flat rate" dues.  This may be ameliorated by the fact that dues should drop to a low amount with increased members on the new infrastructure.  It seems that $5 - $8 per member/month should be attainable in the near future.  See and/or modify Brainstorming/Hybrid Plans for other ideas on how to get around this.

== Tiered Pricing ==

=== Description ===
Akin to standard professional hosting services, multiple hosting "plans" are offered for a flat rate.

Since we are a cooperative, these rates would be determined by the distribution of actual usage levels and tweaked as necessary.  Rates could be set to enable some retained earnings for future investments or maintenance.

A simple compromise alterative is to simply offer an opt-in plan for the lowest-usage members at a flat rate.  This was discussed in NathanKennedy 's email on this subject on hcoop-discuss.

=== Pros and Cons ===
 * Pro: Predictable dues for members who cannot afford large payments and have minimal requirements.
 * Pro: More "fair", in that members contribution is tied to their usage of HCoop resources.
 * Con: It's not necessary at the moment because all of our hosted sites are very far from being "high volume" and adds unnecessary complexity and the need for stricter monitoring/policing of users.
 * Con: It could deter users from joining when they want to start collaborative community sites (arguably exactly the kind a coop should support more than commercial offerings) because their rates would rise to something more than they could individually afford.  The flat-rate plan might be more flexible in this case because it allows those in the coop to collectively decide what to do in the case that a real high-volume site wants to use our services.
 * Con: A "tiered" system sounds hierarchical and therefore elitist, and the idea resonates too much with commercial offerings that those drawn to a cooperative may have ideological problems with.
 * Con: It is "akin to standard professional hosting services", which is an already-full market niche that we shouldn't be trying to directly compete with (if we want to focus on competition at all, rather than internal cooperation, and cooperation with other similar organizations, to improve services).
 * Con: Once we start dividing up our packages, will we have to start marketing our "different" packages (with really only superficial changes) to users?  It seems that this may draw us into reproducing parts of our capitalistic culture that we wish to avoid.

== Shares ==

=== Description ===

AdamChlipala suggests:

We implement a "sliding scale" scheme based on giving each member the option to pay as if he were multiple members. That means that the cost for a single pseudo-member (and a single real member who elects not to use this feature) is decreased.

It is my expectation that, in the short term, some of us will pledge rather large numbers of shares to help drive the minimum cost per member low enough to avoid losing current members and attract new members with limited budgets. However, in the long term, I hope that this feature can be tied informally to resource usage, where members "police" themselves and decide when it is fair to pay as multiple members. There would remain the option for those with plenty of disposable income to pledge greater amounts out of interest in the co-op, to decrease rates and make membership more attractive to the public.

=== Pros and Cons ===
 * Pro: Payment of higher amounts is voluntary.
 * Pro: Compared to other schemes of temporary subsidization of people with low budgets, this scheme automatically lowers everyone's dues as new people join.
 * Pro: We avoid the administrative overhead of monitoring which low-dues-paying members are using more resources than we had agreed that they are allowed.
 * Pro: May be a good way to supplement the short-term access to resources that we need for our move because of insufficient foresight to plan for upgrades.
 * Con: Payment of higher amounts is voluntary, creates the idea that HCoop is a charity and turns dues into donations.
 * Con: More generous members subsidize less generous members, without respect to actual utilization.  Willingness to pay may not correspond meaningfully to ability to pay.
 * Con: Members must "police" themselves to pay based on their own usage, which may deter some from setting up collaborative web sites that commonly use more resources unless they have deep pockets.
 * Con: It is essentially more individualistic than cooperative, since members are paying for their own usage rather than thinking about the collective that they belong to.
 * Con: The notion of "shares" is inherently tied to the evolution of capitalism and reflects the structure of modern institutions (i.e., for-profit corporations) that some members may wish to distance themselves from.

== Brainstorming/Hybrid Plans ==

1. '''Temporary "shares" with long-term modified flat-rate structure''': The "shares" idea is cool and should get us through the short term until membership numbers increase.  In addition, it may be helpful for "fund" drives in the future.  But some have raised criticisms (see "cons" above) about this in the long term, and we can always accomodate users who want to donate more through individual donations.  For this reason, we would use the "shares" program in the transitional period, and switch to a "modified flat-rate" program when our membership increases to sustainable levels.  

This long-term schema would be ''primarily'' based on a flat-rate plan for most members.  Because it is unlikely that more than a few members would have "extraordinarily high" usage (remember that with the new infrastructure this would mean that they're serving out thousands of requests per day on a sustained basis), we would offer a very reasonable base package for all members that includes a budget for repairs and upgrades.  The part of the "tiered" program that we would adopt would be that all sites are able to be reviewed by any member at any time (we all have access to traffic/disk usage graphs and statistics), and the Cooperative will collaboratively decide if and when we need to ask for more resources from users hosting an extremely high-volume site.
 
This also allows us the flexibility of not setting an arbitrary boundary on certain resources and setting prices based on these boundaries, as these available resources are always going to change depending on the site in question and our network organization.  Finally, this plan allows us the freedom to choose which sites we subsidize/support more than others based on our members' collective decisions (very likely taking into consideration the content and purpose of the site in question).  Because of this, it should encourage collaboration among members instead of policing (either self-policing or policing of other members), and increase the communal nature of HCoop as a whole.

2. '''Unnamed plan 1''': If we did need to offer a plan for a very low-volume site on an extremely tight budget ($3 - $5 per month), maybe we could just limit the user to the ability to host one zone on our servers per user account.  This could be compromising between the "tiered" plan by allowing space for very low-budget users, while continuing to have the normal plan that supports multiple zones.  These sites would also be able to be reviewed periodically for "extroardinarily high" usage which we could then charge them for if absolutely necessary, again, unless the coop wished to subsidize services.  Perhaps we could call this an "introductory" hosting plan?
  * If by "Zone" you mean domain name, I think this is a bad idea.  You were against tiered plans in the first place because you thought they were "uncooperative" and placed arbitrary limitations on particular members.  Unlike bandwidth and disk space, DNS hosting essentially costs us nothing and uses almost no resources especially on low-bandwidth sites.  Let's cap resources that are limited, not those that are unlimited.  --NathanKennedy