[CCWG-ACCT] Budgetary veto/control solves the wrong problem and avoids solving the right one

[Greg Shatan]

Chris,

You have clearly misunderstood my email rather phenomenally, which has you
charging about and making extreme statements that have no basis in reality.


There was no expression of a "philosophy." My statements were general in
nature, factually accurate, and were not made about ICANN in particular.  I
was merely making the point that "non-profit" has a more narrow meaning
than people often assume.  There is a common misconception that
"non-profit" literally means that the entity should strive to avoid any
kind of profit or surplus and that it is violating its status if its
revenues exceed its expenses.  This is just not true. Non-profit does not
mean that the corporation should "not" have a "profit."  Non-profits can
have a surplus of revenues over expenses, while still being entirely
"non-profit."  A "for-profit" distributes its surplus (net profits) to
owners/shareholders.  A non-profit does not.  That's all I was saying -- no
more and no less.

I have no idea where you see a "philosophy" that leads to an "open season
for such as the application fees for new gTLDs and for the auctions."  I
made no statement, express or implied, that a "not-for-profit is
unconstrained as to its financial practices."  These are gross
mischaracterizations, with no basis in my email  For the record, that's not
my view at all.

I said absolutely nothing that would advocate or form a basis for absolving
ICANN of its obligations to act in the public interest, to act prudently in
its financial practices, to use its surplus (as with all of its revenues)
consistently with its  mission, or to do each and every other thing that a
"non-profit" corporation must do. This is your invention.

Your statement "With one mail to the List you have done more damage to
ICANN than anything else I can recall" would be extraordinarily offensive
if it were not so completely absurd.  I have deleted my more colorful
thoughts about that statement and your email in general, which took great
restraint.

I trust that I have now set your wildly racing heart at ease.

GS




On Tue, Jul 28, 2015 at 1:36 PM, CW Mail <mail at christopherwilkinson.eu>
wrote:

> Greg:
>
> If that is really what you think, then it is high time ICANN was converted
> into a charity.
>
> That philosophy leads to open season for such as the application fees for
> new gTLDs and for the auctions.
>
> No. With one mail to the List you have done more damage to ICANN than
> anything else I can recall.
>
> Please withdraw it.
>
> CW
>
> PS:  The question of reserves and al prudent surplus is entirely distinct
> from your implication that a not-for-profit is unconstrained as to its
> financial practices, the public interest notwithstanding.
>
>
> On 28 Jul 2015, at 19:02, Greg Shatan <gregshatanipc at gmail.com> wrote:
>
> I don't think the budget veto was ever intended to substitute for
> community participation in the budget process, rather it was intended to
> encourage it (in a sort of dark and foreboding way).  There are already a
> number of ways in which the community in general, and SOs and ACs (and
> their component parts) participate in the budget process, and these have
> been improving over time.  I'm not going to catalogue them here, but I
> should think it's readily available on the website or from Xavier Calvez's
> team.  These should continue to be improved.  One continuing shortcoming is
> that we are all still supplicants, beseeching ICANN finance for a little
> more pie.  While this is true in private (and public) entities as well, the
> level of influence of the community is probably lower than it should be.
> As it is now, the community can register all of its needs, concerns,
> demands, objections, etc., and in the end there is nothing to make those
> anything more than "kind requests."
>
> The budget veto is a final backstop in the event of a budget that
> fundamentally is at odds with where it should be.  The budget veto should
> not be viewed primarily as a power, as much as an admonishment, to add
> discipline the budget process.  It should constrain the Board from
> delivering a "veto-able" budget.  The best way to avoid that, of course, is
> communication with and due consideration of the need of the community
> throughout the process.
>
> One other note -- there seems to be a misunderstanding of what a
> "non-profit corporation" (and why it is called "non-profit").  A
> "for-profit" corporation pays out net profits to its owners (shareholders
> or other types of owners).  A non-profit does not have owners or
> shareholders, so it does not pay out profits to anybody.  While an entity
> can be " non-profit," this does not mean it is "non-surplus." "Non-profit"
> does not mean that it is not supposed to run an excess of revenues over
> expenses, or have no more assets than it has liabilities.  So, this idea of
> "balance" is misplaced.  A non-profit, like a for-profit, needs to balance
> its books in an accounting sense, but that does not in any way mean that
> there is a prohibition or even a presumption against having a surplus of
> cash over expenses.  There may be a point when sitting on a pile of cash is
> not consistent with the entity's goals, but that can also be true of a
> for-profit corporation.  It's entirely fair to talk about the numbers, but
> we should be careful not to bring in presumptions that don't exist.
>  [Caveat: I'm not referring to charitable organizations, which are often
> referred to as non-profits as well.]
>
> Greg
>
> On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg at isoc-cr.org>
> wrote:
>
>> Dear George,
>>
>> I agree with you that a cumulated budget veto is a pretty useless
>> accountability tool (independently of how difficult it would be for the
>> sole member to exercise it…)
>>
>> Moreover, I think the community on the one hand should take care that the
>> public interest objectives (policy development and compliance functions)
>> are properly funded. It would be much more effective if those separate hose
>> budgets (policy development and compliance functions) would be developed in
>> a bottom up fashion, based on the needs of the community, and through the
>> communities direct involvement. No need for a veto then since the SOs/ACs
>> would be DIRECTLY responsible for their budgets.
>>
>> On the other hand, it is up to management to guarantee the financial
>> BALANCE  of the day to day operations (yes, balance because ICANN purpose
>> is non for profit), as well as guarantee the demands of the community for
>> proper funding of the public interest functions (independently of the line
>> overseer of the functions, which is another black box altogether).
>>
>> This would be in my view a much more effective system of so called
>> “checks and balances”  than an absolute veto over the cumulated budget,
>> where the community has little knowledge on the different objectives under
>> it was produced, and remains in my eyes will very obscure, independently of
>> the overall sum in relation to the size of the business.
>>
>> Best
>>
>>
>> Carlos Raúl Gutiérrez
>> _____________________
>>
>> email: crg at isoc-cr.org
>> Skype: carlos.raulg
>> +506 8837 7173 (cel)
>> +506 4000 2000 (home)
>> +506 2290 3678 (fax)
>> _____________________
>> Apartado 1571-1000
>> San Jose, COSTA RICA
>>
>>
>>
>>
>>
>>
>>
>> On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky at gmail.com>
>> wrote:
>>
>> All,
>>
>> These are my personal opinions.
>>
>> I suspect that the reaction to this post will be, "we are way past this,
>> we've discussed this, and now just help us work on the implementation
>> details."  If so, I think that's a mistake, because what I'd like to do is
>> question one of the fundamental assumptions behind what this group is
>> doing.
>>
>> When this process started, there was general agreement that it was more
>> important to do this right than to do it quickly  Unfortunately, this
>> feeling appears to have reversed, with the current sense that it is more
>> important to get it done quickly in the name of the transition than to
>> spend the time needed to do it right.  This process is going beyond
>> accountability to a fundamental redesign of ICANN, with IMO inadequate
>> concern for assuring inclusivity of support as well as lack of concern for
>> unanticipated consequences.
>>
>> So here's what I'd like to contribute ...
>>
>> I've been uncomfortable with the notion of budgetary control/veto since
>> the idea was first presented.  I think that I now know why: in my opinion
>> it solves the wrong problem, and it is the wrong solution to the right
>> problem.  Let me explain.
>>
>> In general, budgetary control is exercised by groups who want to control
>> an aggregate budget, whether for reasons of limiting growth or ensuring
>> that aggregate expenses for a budget do not exceed some measure of income.
>> I don't think that's the case here, although I suppose that under
>> exceptional circumstances it might be.
>>
>> The alternative is that the control the group appears to want must be by
>> program or even by line item, even though you're planning to use a very
>> blunt instrument  --  control over approval of the aggregate budget  --  as
>> your tool to accomplish this.  If that's the case, then what you really
>> want is programatic control, not budgetary control.  If the program is
>> accepted, then subject to resource constraints, it's up to the staff to
>> deliver, and any specific line item or similar objection, however
>> expressed, interferes with the execution of the activity.
>>
>> If the disagreement is with the program, with the objectives to be
>> accomplished, and how the objectives are to be accomplished, then that is
>> where the control should be exercised.  Any budgetary control after that is
>> micromanagement.  The response to that is if you don't trust the
>> organization to implement a rather well defined activity, then change the
>> management/staff, don't restrict their resources and let them continue
>> anyway.
>>
>> I suggest pursuing this line of argument further.  In my opinion, our
>> fundamental problem has two components: (1) a persistent inadequate level
>> of trust between groups within the ICANN community, and (2) our
>> inability/unwillingness to create and use structures to deal directly with
>> this situation and improve it.   I see the mechanism as starting with a
>> lack of trust   --  in Board, management, staff, as well as the ACs and the
>> SOs and their constituent parts  -- that generates not only suspicion
>> regarding motives, non-transparent actions, and actions that are not
>> equally favorable to all groups involved, but also the sense that the
>> process is not serving "me" (whoever I am) well and is therefore out of
>> control.
>>
>> In other words, IMO we have a fundamental problem of trust, and we don't
>> have an effective way to talk about it or to otherwise address it, much
>> less solve it.
>>
>> The budget rejection process that is being defined by the group is IMO
>> based more upon defining ultimate ("nuclear" if you like) confrontation
>> mechanisms than upon finding cooperative mechanisms to identify and resolve
>> potential conflicts at an earlier stage.  It does not address the trust
>> issue, and to the extent that my hypothesis is correct, if not addressed
>> the trust issue will continue to bedevil ICANN activities, in other
>> probably equally destructive ways.   Should not this group be equally or
>> more concerned about mechanisms to identify issues and encourage
>> cooperative-based and trust building processes to solve problems as they
>> arise?   It does not appear so to me.
>>
>> In summary, the current approach, gaining more control over budget
>> approval, is based upon a model of checks and balances, and that may be
>> legitimate to some extent.  However, I sense that is not the way in which
>> it is planned to be employed.  If so, it solves the wrong problem, nad it
>> does not address the real problem.   We need a different approach, one of
>> getting to the root of disagreements, real and perceived, that is early and
>> based upon increased cooperation and trust, and we need a way to
>> communicate that encourages this to happen.  This is not an easy problem to
>> solve, but IMO it's the real problem that we have to solve, rather than
>> some well meaning but inaccurate proxy representation of it.
>>
>> Please consider these thoughts in your discussions.
>>
>> George
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>>
>>
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150728/4c222a55/attachment.html>