CiviCRM is currently used by thousands of organizations around the world, and an increasing percentage of the product and associated services come directly from the community. At the same time, as with any open source project, there are core 'keeping the lights on' activities that are critical to ensure the ongoing growth and health of the project.
We need to ensure that the release cycle is steady and solid, that our servers and infrastructure are looked after, that people with good ideas can find each other, and we need to do all those things that everyone agrees are great ideas anybut no-one can quite get around to finding the time to do!
Think about Wikipedia... it's an amazing resource because of all of the contributions made by various wikipedians, but without a server infrastructure to run everything on, there would be no Wikipedia. Without a well oiled machine at the heart of CiviCRM, we wouldn't be able to put people's contributions to best use.
The funding for these core activities has been primarily covered by a small number of sponsors until now. However long term sustainability requires that we expand our financial base, and one of the approaches we're considering is incorporating a direct ask for financial support into CiviCRM's user interface. The new 'Support CiviCRM' fund-raising widget would be displayed on 'back-end' pages periodically, and might look like this:
The widget would link to a new contribution page which recommends a $25 / month (or more) recurring contribution to the 'Core Activities Fund' - includes an overview of what the fund is used for. We might also include a progress bar and some other useful info-graphics. The widget would also be displayed during upgrades, and incorporated into the 'Register Your Site" flow.
We haven't fleshed out technical implementation details yet, we're pretty sure we want the content of the 'ask' (both the message and the layout) to be driven from a central server. This should allow us to experiment with messaging, frequency, etc. over time. Another idea we are thinking through is linking this widget to the site registration, which would allow us to tailor our ask depending on past giving history. For example we could not ask if someone has donated in the last x months or has a regular donation set up. Or we could adjust the ask amount dependent on past giving history.
Although we think it's reasonable to ask users to support the project periodically, there are likely to be situations where displaying the widget might be inappropriate. We are considering options for dismissing or opting out, including a simple 'checkbox' on the widget. Thoughts on this would be welcome.
Given the goal of converting a larger percentage of the community into supporters, what do folks think about this approach? Suggestions from fundraising experts in the community for making this compelling and avoiding pitfalls are particularly welcome.
Comments
Hi,
Could we try something more subtle as as start? In the same way there is a new blog widget, adding a MiH widget, highlightning the new ones, and introduce the "perf/maintenance" one? Something that is more informative and less begging?
I like the widget idea showing how far we are in the fundraising for each MiH.
It might be a cultural thing, but the "I beg money hard and loud" messages tend to don't rub me nor my users the right way (openx for instance). I'd rather see civi as a talented musician busking than a noisy meth head agressing ;)
I think it's worth a try. Some programs such as piwik (analytics) do this.
A few thoughts:
* would it be displayed only to users with "administer civicrm" permissions?
* if it's always there by default, I suspect people will want to dismiss the widget, which makes it harder to have specific fundraising campaigns afterwards. Showing it in the install/upgrade forms would be good, but very limited visibility.
* having a widget that changes with time (without an upgrade), or pops up irregularly, may give a weird impression to users that we are messing with their installation. I don't really like the intrusive / irregular side of it. Not a strong opinion, only a first reaction.
* having it in the online book would be nice, even if probably less visibility; also allows wikipedia-like campaigning. Forum is also a good candidate, probably the best?
In short, I guess I would rather have something minimal that may be dismissed, but have more campaigning wikipedia-like on forum/book sites.
I think asking for money to end users is a weak proposition. Asking nicely for a contribution is ok, but not if it is too pushy. I think it's much more logical to ask the integrators and implementors to put up 50 EUR/USD for each installation, and to ask customers to actively support the project. To me, that's the community spirit.
I don't think it is a bad idea - as long as there is a way to disable it. Otherwise it would get very annoying. I'm also a fan of xavier's idea about the MiH widget, which could go on the dashboard.
I think CiviCRM's best bet is to expand its market. There are tens of thousands of smaller organizations (hundreds of thousands) in churches alone that could be using CiviCRM, but there are a few dilemmas right now:
1. The CiviCRM site is both aimed at the end user and the developer, they probably need to be split (think mozilla.com/org), it feels too overwhelming for the technically uninitiated.
2. There needs to be an easy way to get installs done posted prominently on the site (done by CiviCRM or by a trusted third party that perhaps gives a commission on each install performed).
3. There needs to be an easy way to get hosted instances posted prominently on the site (again, done by CiviCRM or by a trusted third party).
Dave
I think the one issue is that there are two distinct audiences we are reaching -- integrators/developers and end user organizations. I think integrators/developers always could use a reminder to be sure they are contributing back both financially and through code contributions. But end user organizations, not always. For those who are direct implementers themselves, sure -- they should see it. But if an org hired an implementer, they might be surprised to get a message/popup like that. It may be confusing and make them feel like they got the "free version, with advertising" edition rather than the full product.
I think a good implementer will be clear about what they're selling the client, and make ongoing sustainability a part of the project discussion (and no, I haven't always done a good job with that myself). I just think that we want to make sure the presentation of the pitch is tasteful, and in no way undermines the fact that they do in fact have the full product, and are not under obligation to contribute. In other words -- I wouldn't want it to undermine the open-source-ness of CiviCRM.
So having the ability to turn that message off may be part of that. The implementer can then use discretion and judgement when deciding who should receive the pitch. Another example where this is important -- I have one client that has made significant financial contributions to support feature expansion. That is expected to continue -- but definitely won't be happening through a link in their site to a Civi contribution page (where the contribution would be "recognized" and trigger the suggested donation message to turn off). I would definitely not want them to receive the popup -- they already support the project in significant ways, and I would not want them to be asked through that method.
I think the idea has merit -- and there are a lot of integrators/orgs that need to step up and support the project more. But I want to make sure we don't distort who we are, or the product itself, in any way.
I agree that the idea has merit, and I think it can be tastefully done.
I also like Xavier's proposal for a MIH dashboard widget. I think keeping up with the latest proposed new features is always in good taste.
I don't think it's an either/or question - we can do both.
I'm with Paul Delbar on this, I'm not sure the right approach is to ask end users for funding. This may well confuse them if they employed the services of an implmentor to get them up and running.
I think an implementor "partner" program might be a better approach where implementors are required to fill in details on the sites they install so that they can be encouraged to give back. Its difficult to do it without taking into account the size of install - for instance displaying the same message to a 5 person organisation with a below 6 figure turnover and to an organisation with 7 figure + turnover isn't clever fundraising either.
I'd like to see some stratergy around this, is it just funding? it is an ecosystem we're trying to build? Whats the longer term stratergy?
Hey there,
Re:Brian's comment about two distinct audiences and Parvez's about a wider strategy, have a look at this wiki page: http://wiki.civicrm.org/confluence/display/CRM/Financial+contributions. Basically we are exploring targeting end user organisations amongst three other streams - service providers, MIH and major sponsors. We are also looking at financial contributions as one part of a much wider picture of an engaging the community in other ways.
Parvez said - "I'm not sure the right approach is to ask end users for funding. This may well confuse them if they employed the services of an implmentor to get them up and running." If we get it right, I am hopeful that we will be able to replace the word 'confuse' with 'enlighten' in your sentence above :) i.e. they'll better understand the relationship between themselves, their implementor and civicrm. OK they paid an implementor, but they didn't 'pay' for civicrm, and they could consider supporting the project financially.
I agree that we definitley want to avoid people feeling like they got a "free version, with advertising". We want them to feel like they are part of a community, that they can contribute finanicially if they want to, and how they would benefit from this contribution. Part of that comes down to how we write and deliver the pitch. I think that NPR set a good example of the kind of tone we might want to go for. We might just ask them a question like. To get them hooked, we could ask them "Have you ever wondered where CiviCRM comes from?" We can also include in the pitch alternative ways to contribute.
As some people have touched on, I think it is important to explore fully how this links with hosting providers and service providers. For example, service providers could add a $25 per month on to their hosting plan and contribute this to directly to CiviCRM. They'd then turn off the widget for their clients since they are all already donating that amount and shout about what a responsible service provider they are
Agree that it is important to have it turn-off-able. And since it is open source, anyone could turn it off with a few lines of code in any case.
Co-ordinating this with a bigger fundraising drive that happens on *.civicrm.org site is a very cool idea as well, mlufty :) If we get it right I am hopeful that a lot of our target audience with identify with a fundraising drive and want to contribute, rather than be turned off by it.
PS. Though I agree that we shouldn't 'shout' and 'beg' I do think that we need to do a better job of explaining CiviCRM's particular flavour of open source to our users. If we were a more techie project like Drupal then we wouldn't need to do this as much, as the audience is more familiar with open source and gets it, but we shoudn't expect the same of our users.
Very interesting topic, and great comments above. I tend to agree that the 'blasting' approach is not the right one as most end-users will not care, and that the reminder on the dashboard might also seem kindda strange to some people. As an integrator, I certainly would like to support CiviCRM with monthly donations BUT disable these reminders for all my customers.
Another avenue for fund raising could be to make registration more prominent in the setup process (ie. checkbox on the 'Organization Address and Contact Info' setup screen), and then make this call for funding part of the newsletter. This way you only reach people that do read your newsletter, and hence sufficiently care about CiviCRM.