Close this window
Our organization uses BlackBaud's "The Raiser's Edge" for membership and donation tracking. I'm the IT guy and not actively involved in using RE, but the best of my knowledge we don't use it to track volunteers and their hours or other things beyond the core of membership and donations. We have less than 5,000 active members.
Recently, some staff have become infected with the "open source disease" where they are crusading that we should be moving everything to open source software. I'm a big fan of open source and push it whenever I can, but I also recognize that you have to use it only where appropriate and you really can't expect that your small non-profit is going to be actually changing the code.
Since RE and its expensive licensing has become a bit of a target here I'm trying to get out front of this a little bit. Are there open source alternatives to RE that are actually viable for a non-profit? Are CRM products like SugarCRM viable alternatives?
On the open-source front, be sure to explore CiviCRM. I've implemented it for a number of organizations and they are all happy. (with the obvious caveat that needs vary).
In the broader category of "less-expensive than RE" you'll find a number of great products as well as great information throughout Techsoup on CRM solutions for nonprofits.
I would probably suggest against using SugarCRM because of the dramatic customizations you would need to make for it to be nonprofit-specific.
Best of luck,
Strategic CRM Solutions for NonProfits at PickettCRM
When migrating from RE to a new database, you have to take into consideration both the complexity of the data migration (not a simple task with RE!!!) and the user's expectations for features and accountability.
An "out of the box" CRM might not be the right choice for your user's, depending on how they are using RE today.... I will need more information to advice (for example: which version of RE are you using? do you currently have maintenance agreement? etc....)
Tal FrankfurtCloud for Goodwww.cloud4good.comTal@cloud4good.com@Cloud4Good
Thanks to Tal & Brian for those thoughts! It's really ironic for me to be arguing in favor of closed source apps, but I really want folks to understand that there is nothing inherently superior about open source or inherently evil about closed source. I figure that I have to decide on software based upon its suitability to the task, flexibility and it's overall costs. Open source gets an edge because of the quick community response that is generally there when a problem is discovered, but I never figure that I'm going to be the one to patch software so I treat both open and closed source the same from that standpoint.
Since I figure that this will probably not go away as a discussion topic, the point of my post was to start finding suitable alternatives to show to our Development staff so that they could see that RE might not be the only viable solution and that panic is not necessary.Of course the cost of conversion from RE has to be calculated in to things, but the prejudice towards moving to open source models is probably not going to go away. So the things I'm wondering about are whether tools like SugarCRM or SaleForce.com which seem to be business/sales oriented can actually be used effectively for non-profit member/donor management.
I don't consider Salesforce.com as an open source application, however, the Non Profit Starter Pack (Salesforce.com's solution for NPOs) is (kind of) an open source project with a very active nonprofit community. With that being said, you should consider Convio's Common Ground which is built on the Force.com platform and has many enhances that might be more relevant for organizations migrating from RE.
I would be happy to schedule some time to talk over the phone about this, you can contact me directly at Tal (at) cloud4good.com or 901-213-6188.
My Bad! I noticed SalesForce.com on your web site so I threw it into my comments without checking into whether it was open source!
I know you know this stuff, but for the sake of the discussion that you're engaged in I'll state my opinion:
Licensing fees aside all software costs money, open-source or not, because of the support needed to:
1) Discover user needs
2) Set-up and customize the application
3) Migrate data and train users
4) Make ongoing customizations and support the team
The support needed to customize an open-source business CRM application, like SugarCRM, for nonprofit use could surpass the licensing fees of simply going with a nonprofit specific product. Salesforce.com is not open-source but it is a business CRM that nonprofits use. Salesforce.com makes it easier with their nonprofit overlay plus it has an app-exchange with hundreds of pre-built products that might fit a future need of your organization. As you can see there is a valid argument in both directions for some business CRM applications.
The best thing you can do at this point is to go through a Discovery process to thoroughly document and prioritize the needs of your users including connecting these needs to specific strategic objectives of the organization. In this way the discussion centers around finding the right product to move the organization forward.
Sorry for the late reply to your message.
Just to be upfront with you, I represent a company with a competing product to RE.
As previously mentioned in other posts, there are a number of alternatives to RE; however, the ones that are not non-profit specific may present challenges to your users (and consequently you) since they lack functionality specifically used to track complex donations like gift annuities, trusts, etc.
To see a fairly comprehensive listing of alternatives, check out:
Amanda, thank you for sharing, this looks like a very good recource!
I would like to make one comment. This table does not defrenciate between online and cloud based databases. There is a huge difference between the online Blackbaud NetCommunity database and the cloud based Common Ground.
Some years ago a consultant sold us on DonorPerfect because they used it at the previous nonprofit where he did some consulting and the other organization was pleased with it. Well, I'm not so impressed, but I don't really have anything to compare it to. Before DP we were just entering donations directly into QuickBooks which doesn't allow tracking, trends, donation reports, etc.
One thing I learned is to do some research and see what kind of support you can find from other users. The user forums for DP are helpful, but I can no longer access them since our maintenance agreement ended. (We learned pretty much everything we had to in order to use the program for our purposes, so we saw no need to continue the maintenance agreement.) So find out before you buy if there is a good user forum or Yahoo group or something that you can join and access even if you're no longer paying a yearly maintenance fee.
And of course consider the data conversion fee which for us was very expensive.
The term Open Source does not mean “Free”. The term means that the program logic is not hidden; the logic (coding) is available for study, modification, and additional uses.
Closed Source does not mean 'Costs money', it means that the program logic (coding and other) are intentionally not available for your use (typically and almost always the 'data' storage part is the key in this).
The implications of this for people in your position is that whatever functionality that a 'Closed Source' system may provide; that functionality is determined solely by the owners of the software.
Conversely with Open Source the limits to a Software Program's functionality are determined by human abilities; to do something constructive with the technologies involved (example. data is always usable as it is always stored in a standard format).
The delimiting qualities in the implementation of the two; as in this case, is the decision to offload the technical parts to a problem solving entity as the solution ....
Or, I would suggest looking into local computer users groups. Ask around. Speak to people. Social sites. The various means at you disposal to locate individuals in your geographic area, who I am sure are quite capable of being useful to you in answering this type of question in detail.
You are likely to find that there is an Army of capable (mostly younger) people who's grasp of the technologies upon which both 'classifications' of software are build will be more than sufficient to answer your questions. They write code, design, discuss, and implement technology. They do that largely because they know what it is.
One small clue. In many of these implementations we are talking about what was once called 'web delivered'. Simply software who's logic is executed and the results delivered via. a web server or services. Most CRM's (and the limitless variations) are web delivered. Thus we are talking scripting languages vs. 'programming' languages to modify functionality.
The term 'web delivered' was unable to defend itself one day (a true story)..., it was chased and captured, and spray painted 'Cloud' along with a couple of other standardly used IT terms. So that if you didn't ever know 'web delivered' you could end up asking for “Cloud”. Be careful.
We could have a discussion on what these packages are 'made of' and why it is important to know.
Re-reading your post I am noticing the reference to QuickBooks. QuickBooks has an API (introduced late 90's) that turned QB into an more flexable extensible proprietary software (sales then went through the roof). The API provided access to the propritary data formats (otherwise inaccessable). Allowing for 'normal' access for external processes, reports and so on....Trends, are just numeric sums from entries grouped by date from records entered over time. QB can currently do that by the way.
Check out Orange Leap . We are an open source software company for nonprofits providing both an on premise and on demand version.
For what it's worth, one of my larger non-profit clients made the move from DonorPerfect to RE about a year ago, after an ambitious study of proprietary and open alternatives.
So far, they have been very satisfied with the results, using it for volunteer information as well as for donors. Despite the substantial fees, they seem to feel that it's worth it.
From my perspective, as systems administrator, I've found both programs to be quite stable. RE was a bit more complicated to set up, especially on networks with restricted user logins, but support has been very good. RE also makes any desired number of data backups, so non-experts don't have to deal with issues relating to the SQL engine.
The CiviCRM package has an available manual...
Of course the Drupal or Joomla manual would be worthwhile having with that.
A SQL Reference is pretty standard to have around (used to be anyway).
And of course familiarity with the OS's security model is pretty much requisite when adjectives like 'implementation' are being thrown around.
The Web. A single standard robust interface (web browser). And a variety of development tools and standard API's (ASP, .NET, PHP, Perl, C#, and server extensions ie., C and C++, of course HTML, Java Script, AJAX, and on and on.) for creating application logic...
Simple to deploy, and made even simpler with 'platforms' like Drupal, OFB (Apache), Joomla, and many others.
...all build on a standard set of technologies and approaches, but all of them require a set of core competencies in web and networking with some light programming and perhaps some SQL thrown in, to take advantage of them.
One post mentioned CiviCRM, a large package written in PHP, ideal for an Intranet, extranet; No management could look at a stock install of CiviCRM, view the menued items (it's a lot like Alpha5, or even Access with most of the finished app front end requiring only entering configuration settings), and not be impressed. Scalability ?... how does an rdbms scale? how does a web server scale?
We can throw a lot of technical terms at reasons for not looking into such Software, but when it comes down to it, what has been expressed is a lack of familiarity, and a tendency to rely entirely on commercial vendors to address even those needs.
I do not know for sure but I believe that 'PicketCRM' has indicated a familiarity with CiviCRM specifically. And this;
None of the above would sell me completely; but without the above I would be less inclined to spend the time investigating the details relevant to my implementation using the package.
There have been a couple of recent web postings on this topic: