welcome: please sign in

Please enter your password of your account at the remote wiki below.
/!\ You should trust both wikis because the password could be read by the particular administrators.

Clear message
Edit

PaymentPlanProposals

1. 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 :) ):

1.1. Flat-Rate

1.1.1. 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.

1.1.2. Pros and Cons

1.2. Tiered Pricing

1.2.1. 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.

1.2.2. Pros and Cons

1.3. Shares

1.3.1. 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.

1.3.2. Pros and Cons

1.4. 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?