1 |
If the objective is to compare the cost of the Foundation to an umbrella; |
2 |
I'm all for it! |
3 |
|
4 |
My primary critique of the blog post is in the financials and income |
5 |
forecasting. I have two major objections. |
6 |
|
7 |
(1) The foundation makes more than simply individual donations. The |
8 |
methodology where we ignore a large portion of revenue seems rather |
9 |
arbitrary to me. I might work on a more numerical model. Really what I |
10 |
think we want is some moving average of past years (by revenue source) and |
11 |
we say things like "well we make an average of Y$ from source Z, and we |
12 |
made this over a period of A years, so we can forecast some of this revenue |
13 |
into future years." It would be a discounted model, but I don't think it's |
14 |
valuable to discount these extra sources of revenue to 0. Or to put this |
15 |
another way; why don't we discount individual paypal donations to 0 also? |
16 |
The answer appears to be because we have a historical model that says we |
17 |
are likely to get some recurring donation revenue...which then leads me to |
18 |
ask why we are not applying this same heuristic to other revenue sources |
19 |
for the Foundation? So in short, I don't agree with only using paypal |
20 |
donations and we should forecast other revenue sources. |
21 |
|
22 |
(2) A follow on from (1) is that the actual income of the foundation |
23 |
matters for efficiency calculations. If we spend 5k on ongoing costs (CPA, |
24 |
taxes, etc.) and we make $7200 (according to the blog revenue model), we |
25 |
are very inefficient on a percentage basis. Efficiency is a function of |
26 |
expenses and revenue. Expenses are actually somewhat fixed; so a revenue |
27 |
forecast that provides more revenue will also reflect a higher efficiency |
28 |
for the company. I believe the model in the blog post basically makes the |
29 |
existing cost structure worse than it is (and it does this by under |
30 |
forecasting future revenue.) The revenue forecast also impacts alternative |
31 |
structures. If we join SFC and we pay 10% of revenue as fees...obviously |
32 |
the fees are directly tied to revenue, so under-forecasting revenue will |
33 |
make SFC look more attractive on an absolute cost basis (the percentage |
34 |
cost is of course fixed at 10%). If our revenue is 7200$, then the SFC is a |
35 |
steal on an absolute basis. If our revenue is 20,000$, the SFC is less than |
36 |
half the cost of the existing structure. If our revenue is 60,000$, then |
37 |
SFC costs more than the existing structure. |
38 |
|
39 |
The question of financial efficiency is basically a function of size then. |
40 |
If Gentoo was bigger, the nonprofit would make fiscal sense (we could be |
41 |
more efficient than SFC.) If Gentoo remains its current size, then the SFC |
42 |
seems ideal and we can use a slimmer operational structure and likely still |
43 |
support Gentoo. To me this decision is about what we want from this kind of |
44 |
body. This sort of decision is part of what will be discussed in my |
45 |
President's letter to members later this week, so it's not a question I |
46 |
really pose here; but I want folks to think about: |
47 |
- How an organization, like the foundation at its current size could |
48 |
support Gentoo. |
49 |
- How an organization, at double the current size, could support Gentoo. |
50 |
|
51 |
Then thinking about which one to pursue. I think many people view the |
52 |
foundation as perhaps a necessary evil, or as an opponent. I would instead |
53 |
like folks to consider what the Foundation could do as an ally to the |
54 |
community. |
55 |
|
56 |
-A |
57 |
|
58 |
|
59 |
|
60 |
On Wed, Aug 26, 2020 at 11:23 AM Andreas K. Hüttel <dilfridge@g.o> |
61 |
wrote: |
62 |
|
63 |
> |
64 |
> https://blogs.gentoo.org/mgorny/2020/08/25/is-an-umbrella-organization-a-good-choice-for-gentoo/ |
65 |
> |
66 |
> While I'm not the author, I think it's an excellent writeup. |
67 |
> |
68 |
> -- |
69 |
> Andreas K. Hüttel |
70 |
> dilfridge@g.o |
71 |
> Gentoo Linux developer |
72 |
> (council, qa, toolchain, base-system, perl, libreoffice) |