[Fundraising] Just some thoughts about justifying expenses

[Gary Lang]

This is a pretty thoughtful piece. I really have to chew on it a bit.

That said, off the top of my head:

1) Not too persuasive, though if I heard that ACE was foundering and
needed money for something I'd give money to whatever body sponsors it
the most. I myself have paid Riverace for their pre-packed/supported
versions of ACE.

2) Interesting; this is the one (I think) that Frank feels will persuade
donors to work with us. I very much like your commodification comment. I
think a related one is that if the software is being put forth by and is
sponsored by a company who is perceived to have unlimited resources to
develop it, donations may actually be hurt. So I can see a scenario in
which MapGuide slows down funding participation by others just by us
being involved.

3) The ROI calculation is always useful.

Given 2) and 3) one might well agree with your conclusion.

Gary

-----Original Message-----
From: Michael P. Gerlek [mailto:mpg at lizardtech.com] 
Sent: Friday, April 28, 2006 9:52 PM
To: fundraising at fundraising.osgeo.org
Subject: [Fundraising] Just some thoughts about justifying expenses

Frank asked me "Do you have any suggestions on how to make a sponsorship
program maximally attractive to companies such as yours?"  (my company,
LizardTech, represents the market segment of "small GIS software
companies without vast amounts of cash")

So: let me offer some thoughts on how to get money for an Open Source
project.


A good way to do this is to keep in mind that generally such
expenditures are not under the control of mere engineers, and so it
needs to be done in a way that non-engineers can relate to.  I can think
of three such approaches.


[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 :-)


[2] Justify the cost in terms of software licensing.  Every year at
budget time, we have to figure out how much we need to spend on Tools
and proprietary Libraries and such, and we then allocate dollars
accordingly.  Now, major software these days is paid for in terms of the
license cost and the support cost (all businesses usually buy the
support packages; indeed, purchase of support is sometimes even
*required* by the vendor, oddly enough).  Case in point, yesterday I was
quoted $1000 for a license for some documentation software, plus
$1500-$3000 for the support deal.

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.

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.  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.]


[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".


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.


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.

Anyway, just some thoughts on a Friday afternoon -- hope some of that
made sense to some of you....

-mpg