[HCoop-Discuss] Financial situation

[Aaron Hsu]

On Sat, 28 Apr 2007 17:14:05 -0500, Justin S. Leitgeb <leitgebj at hcoop.net>  
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 <arcfide at sacrificumdeo.net>
http://www.aaronhsu.com | XMPP/Gtalk: arcfide at xmpp.us
(703) 597-7656 | "No one could make a greater mistake than he who did  
nothing because he could do only a little." - Edmund Burke