[Fundraising] Just some thoughts about justifying expenses

[paul at warriner.us]

Thanks Michael, it all makes sense to me, from my corporate days. 

If I can, just some Saturday morning thoughts from the local government
sector view.

Mine is a slightly different twist, as local government is much more of a
fixed funded operation, as profits don't drive capital, or at least it is a
little more obscure from a margin or return standpoint. The service level is
more the key at the local governemnt level, either to the public or larger
agency customers.

A local government is to me a unique breed, as they are more tightly coupled
as producers AND consumers of GIS components. In larger groups, the coupling
can be more obscure.

It helps if I look at open source as more of the function box, with the
local government level having the inputs. While business, the public, higher
levels of government, and itself are the outputs.

Most local projects need to fend off the hostile takeovers by higher
agencies, while maintaining the same, or an even better level of service
from a micro point of view. At the local level, both of the big vector
products on the market are used, and they feed the bigger machines at state
and county levels, so what is adding a third tool (all open source products)
going to do for them? Also, are they funding research or a product? If it is
research, will it lead to something that will produce something they can
use? If it is a product, does the foundation have a means of sustaining the
use of the product and support for operational activities? Tough questions
for small agencies to get answered.

I see many larger agency projects slump along, due to the information
generators at the local level being left on the sidelines. Most of the
larger agency projects would have much better success if the local
governments had the tools they need to provide the long term maintenance
needed for these large machines. Some of the larger agencies start off by
helping the smaller agencies with the tools needed, but soon leave them with
high cost products, that soon begin to find their way to the shelf, due to
the high overhead of training and licensing.

If smaller goverments were introduced to the availablity of the tools in a
way, as Michael pointed out, that non-engineers can relate to, combined with
consistency in training and maintenance, it could be a real win for them and
the foundation.

This brings me to a point of rumination, (ok, the whole thing is rumination)
but, anyway is it "the chicken or the egg" syndrome for local goverments to
use open source. Do I have the staff to do the work, or can I find the
people who can do it?

The big question: If they give a foundation money, what is it going to do
for them, or the greater good? The exact form of the question depends on
whether it is a political year? :)


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