On Sat, 28 Apr 2007 17:14:05 -0500, Justin S. Leitgeb <[EMAIL PROTECTED]> wrote:
> Adam Chlipala wrote: >> Justin S. Leitgeb wrote: >> >>> Thank you for suggesting this, Aaron. I think that the 10% figure that >>> you cited is a very reasonable way to get HCoop to start saving money. >>> >>> >> >> I've been in favor of this all along for the "Some Day" category, but it >> just hasn't been clear yet that we have good enough estimates of costs. >> >> I want to pose one distinction that matters if members are paying >> unequal costs, say, for different disk usage amounts. Do we add a >> percentage to the co-op's total costs and then divide that up (not >> including member resource usage costs), or do we add a mark-up onto each >> member's monthly bill (including costs peculiar to each member)? >> >> > I can see pros and cons to both. I would just ask, first, though if you > are planning on implementing a program whereby members can purchase > arbitrary amounts of disk space effective immediately? If so, I would > say that we should add a mark-up that is higher for members using lots > of resources. Then we could add 10% for a "Maintenance/Upgrade Fee" > based on what each member is paying to their monthly cost. If we are > going to implement the ability to purchase arbitrary amounts of > resources later I would suggest that we just divide current costs by the > number of members, take 10% of that, and charge it to each member > effective immediately. We can always revise things later when we add > new membership options, and this would allow us to start saving > immediately. Would it not be simpler and more manageable if we just had a mandatory pledge bump for anyone who uses excessive resources? This way we can avoid the whole issue of buying more resources and whatnot, and the problems of administrating those changes. Instead, we can just bump pledge proportional to the amount of resources someone is using if and only if they are documented as affecting other users in an adverse manner. > 4) I think that we should keep in mind that although the Peer 1 > configuration is going to be a much more reliable internet connection, > in effect we are multiplying the number of single points of failure in > our infrastructure by quite a bit (e.g., we have one fileserver, one web > server, one switch at the moment). I think that although capacity will > be fine at Peer 1 will be fine for a while, we should start aiming for > redundancy immediately (e.g., how soon can we save up for a second file > server to cluster with deleuze so that one can go down for a bit for > upgrades or repairs?) This is something I have been noticing as well. Why did it take so long to upgrade these systems? It very very much appears that there are some serious bugs in the administration scalability of our current systems. If we continue on the same pace that we have been, future upgrades only look to be major pains. I think some efforts should go into streamlining the upgrade process to ensure that expansions and maintainence can occur without downtime and with minimal efforts. This would reduce overall costs in terms of manpower and actual monetary costs. I offer my services, but unfortunately, most of my experience with such management is in the OpenBSD side. However, I do have some experience with redundancy and load balancing, and I am a stickler for making things easy and never repeating the same task over again. However, you all seem like a capable bunch, and since the amount of time that I can contribute is relatively limited, I don't want to overcommit myself to a project that you all can probably handle by yourselves without additional help. I also have my own ideas about how things "should be done" which would probably mean I might not adjust so well to your current setup. That being said, I'm just throwing out my own ideas of what I see as a weakness at the moment. Redundancy and easy expansion are two things that I think should receive a high priority AFTER the new servers are up and running, and the old ones are taken offline. > Based on the notes above, I don't think we'll have enough money to > really be "comfortable" for quite some time. Would something like > $10,000 be a good initial goal to keep on reserve? At any rate, I think > that although the exact amount that we should keep on reserve will > always be up to individual opinions and a multitude of other factors, it > is clear enough that we need to have something on hand that we shouldn't > delay our decision to start saving *something* any longer. So I would > stick with the 10% of flat costs if we aren't ready to charge varying > amounts for resource usage, or 10% of what each member is paying, > including charges for high disk space usage if we are really ready to > offer that option immediately. I think we could start with a baseline of 10% and then the board can examine their next target upgrade and expansion, set a date for it's migration, and calculate projected costs. Doing so should give them a figure of how much they need to earn. The percentage fee can then be adjusted based on these findings, but only if the percantage change would be an increase in the percentage, as I don't think anything less than 10% is going to be a good idea. A set replacement plan could then be put in effect, saying that say, a certain amount of money capable of replacing X amount of the hardware in the current setup, should always be kept around. This would be added to the percentage for the next upgrade to allow the coop to begin building up the maintainence nest egg. When the maintainence reserve increases, then, if the current Fee will not cover it by the half time to the next upgrade, the board can incrase the fee so that this target is met. In summary: Base 10% Maintenance and Expansion Fee Board sets target date for next upgrade and adds to the base any percentage more needed to acquire sufficient funds by that target date. Board calculates the anticipated desired maintainence reserve. If this reserve will not be met within half the time of the target upgrade date, not counting the money intended for the upgrade, then the board increases the percentage so that the coop will have obtained this reserve within the half time of the next upgrade. Once this reserve is met, the percentage should be lowered, and should not be increased again for the reasons of maintenance fee unless an emergency occurs which requires the draining of the maintenance reserve. -- Aaron Hsu <[EMAIL PROTECTED]> http://www.aaronhsu.com | XMPP/Gtalk: [EMAIL PROTECTED] (703) 597-7656 | "No one could make a greater mistake than he who did nothing because he could do only a little." - Edmund Burke _______________________________________________ HCoop-Discuss mailing list [email protected] http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-discuss
