[Fundraising] Just some thoughts about justifying expenses

[Frank Warmerdam]

Michael P. Gerlek wrote:
> [1] Appeal to the guilty conscience: "you're using all this cool
> software for free, you're not giving anything back in return, you should
> be ashamed, what would your mother think".
> 
> This is approach is least likely to succeed :-)

Michael,

I would agree.  This is a rather desperate and pathetic angle.

> [2] Justify the cost in terms of software licensing. 
...
> So, one could try to get people to view, say, GDAL as a package like any
> other: in this case the "license" cost is perhaps $0, but the nominal
> support cost can be argued to be comparable to other, similar packages
> the company is buying.  It is way easier to "hide" a couple thousand
> inside the HW/SW budget than it is to try and get funding for an
> in-your-accountant's-face "donation".
> 
> Note this tack can be done for OS libraries used inside the company's
> products, as well as for tools used to develop those products -- e.g.
> you might use MapServer in-house to store data and do testing with.


> [3] Most obvious of the three approaches, we can try to justify the cost
> in terms of engineering effort saved.  The development cost saved by
> using OS tools or libraries, as opposed to doing in-house development,
> is substantial.  If this can be turned into a staff-weeks number, great.
> (But don't overcharge, though.  You don't use ALL the options in
> MapServer do you?  Of course not.  Don't be greedy, just compute the $
> saved for the parts you honestly would have had to do yourself.)  Also,
> remember that $ saved is not just in development time alone -- business
> people love to use terms like "opportunity cost".

Michael,

I wonder if expressing the expense in terms of (2), that is sort of a
"maintenance fee" might make it easier to slip into the budget given
friendly management in some part of a company.

I think argument (3) in the form you have expressed is a good explanation
of why companies should use the open source software.  Once that case is
made, perhaps we can try to make the case that if the package the company
depends on is well maintained that will will save a certain number of
additional staff hours that would otherwise be spend fiddling with the
package in isolation trying to deal with bugs in new versions and so forth.

So, to express the sponsorship/maintenance fee in terms of paying for
better up-stream engineering to save inhouse engineering time (and opportunity
cost, support burden, etc) compared to a poorly supported project.

This angle suffers the free rider problem of course.  Companies can ask, why
not just let others cover this cost and we'll handle whatever slips through
on our own if it affects us.

> So, we have a few approaches that can be taken to try and get some money
> set aside for an OS project.  But, at the end of the day, the above
> arguments are about HOW to pitch the expense item itself, and NOT the
> deeper question of WHETHER or not to pay at all.
> 
> The usual OS answers to that deeper question are all about quality
> software, great support network, access to source code, etc, etc, etc.
> Alas, these classical motivators alone are insufficient, as the simple
> response is usually: "yes, those things are great -- I will indeed take
> advantage of them, but since they are already out there free for the
> taking, I see no need to pay you".
> 
> Business people are not accustomed to spending money they don't need to,
> so very often the conversation will stop right there.
> 
> What I'm advocating in this note is a different, and maybe
> complementary, angle to pursue during a funding conversation: rather
> than view funding an OS project as a vague "donation", let us couch the
> dialog in terms of "normal costs of doing business" -- something they
> may be more comfortable with, and something easier to budget for.

Agreed.

> Finally, note that the above is all about small-medium companies.  The
> ESRIs and Googles have whole divisions devoted to giving away money to
> worthy causes, so things can be handled totally differently in those
> cases.

Well this raises the angle you didn't talk about at all.  That is the
potential promotional benefit of sponsorship.  I have seen sponsorship as
leaning on two legs.  One is the promotional benefit of being a sponsor
of OSGeo (hopefully benefiting from the glory if it's various projects),
and second is the benefit of a better supported package and perhaps some
sort of implicit promise of preferential support for the sponsor from the
dev team.

I don't think the biggies give money to *worthy* causes - they give money
to causes when the association can be seen to give them a promotional
benefit offsetting or exceeding the cost.

 > ASIDE: Beware of commodification, however!  Linux, gcc, perl, and
 > Firefox (to name just four) are tools that every engineer in my team
 > uses -- but we don't even think about them anymore, we just take them
 > for granted and it'd be impossible to try and justify spending money on
 > them.

This is an interesting point.  When I was at PCI I swung a support
contract for GCC via Cygnus.  While I pitched it to management as a
safety net since we depended on gcc on several platforms, it was essentially
a good faith effort to support an important project.  I did put through one
support request on an item I found, but more so I could explain to management
that there had been a benefit rather than because it was especially necessary.

 > On the other hand, my team views GDAL in a very different light
 > -- probably because we "know" Frank, the package serves a niche market,
 > etc.  [The "sociological delta" between certain OSGeo projects and the
 > OS ecosystem at large would be worth exploring over a beer sometime.  I
 > think there is a clear mind-share difference, but I'm at a loss to
 > articulate it right now.]

This is an interesting point.  I think part of this comes from the side
of the community.   With GDAL having a much smaller user community and a
more direct feedback loop from you as users there is a much greater
"connection".  For instance, I think it will be much easier to keep a
connection to users of a package who have actually reported a bug and gotten
a fix.  As opposed to something like firefox where I can hardly imagine
my reporting a bug - after all, if I ran into it, surely hundreds have
allready reported it.

Perhaps the lesson here is that fixing bugs for potential sponsors should
be seen as a way of involving them in the community.  I have certainly always
taken this position from a self-interest point of view.  I'm more inclined to
fix something for someone I think of as a potential future client or
influencer than I am for joe-random-undergrad-student.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org