Sonny Cloward has some positive preliminary things to say about using Salesforce.com’s free 10-user nonprofit as a web-based database system for small nonprofits:

In short, I have recommended that CERF deploy Salesforce as its data management system. The rational for my recommendation is that Salesforce meets our basic and priority requirements:

Basic Contact/Relationship Management

Relationships: Between orgs/businesses and staff, individuals and family/friends, individuals and employer

Loan Processing: with Payment schedule

Donation Processing: with Pledge, Matching Gift and complicated GIK donations

Gift-in-Kind Brokering: creating a reciprocal connection between GIK donor and GIK beneficiary

Query and Reports: Intuitive report writer

Integration with other applications: Outlook (can access directly from Outlook), Excel, QuickBooks, any application.

I have no illusions that there are some kluggy things about the application when customizing it for nonprofit processes; it definitely would not work for all organizations. Additionally, edge CRM functions like email blasts, online donation processing, event management and e-commerce functions are not part of it’s functionality (unlike Kintera). However with an open API, integration of third party applications are possible to gain that functionality. I’m looking at Democracy in Action, which also has an open API, as a possible low cost edge CRM provider (In Jon Stahl’s words: “Pieces loosely joined.”)

I spent some time last week thinking about database tools that grassroots environmental organizations use to manage their relationships with members, supporters, etc. After looking at a bunch of the commercial and non-commercial tools available, I remain profoundly unsatisfied with the current state of the landscape. Here’s what I think an ideal database for the groups I work with would be like:

1. An ideal database will have strong workflows around the membership renewal cycle. A lot of small groups I work with are membership based groups, and many of their fundraising relationships are powered by direct mail. It’s possible to argue that this is a “failed model” but the reality is that many groups need to be able to take care of their “legacy” donors even as they cultivate new kinds of relationships. A solid database must therefore be able to track the details of an ongoing direct mail renewal cycle. Many commercial database programs are pretty good at this, and many of the non-commercial solutions have a surprisingly long way to go here.

2. An ideal database will be able to track more than just members and their money. Members are important, but it’s not the only kind of relationship that an effective organization needs to track in a database, and development staff aren’t the only peole who need to use the database as an everyday part of their work. Unfortunately, too many database products are too “development-centric.” Not only in their features, but also in their pricing. Many commercial packges impose stiff cost penalties for additional user liceneses, and even some of the non-commercial packages like ebase require steep Filemaker licensing costs to scale beyond a single user.

3. An ideal database will be fast enough to keep open all the time for every user. If people are going to use a database as an everyday tool to record information about all of their key relationships, an ideal database must be fast to open and fast to use. If it has a web interface, that interface must be extremely well engineered to minimize roundtrips to the server.

4. An ideal database will expose different user interfaces to different types of users. Too many databases assume that only one type of (expert) user will use them. An ideal database will be usable by many different people in an organization, with many different roles and needs. Program staff won’t have access to detailed development reports, but will have an incredibly easy screen that they can use to take notes on a phone call or meeting with a key activist. Unskilled users will find it easy to perform basic tasks, and the full power/complexity of the program will be hidden from their day-to-day view.

5. An ideal database will be usable by people in remote offices. Distributed networks and decentralized organizations are the wave of the future. Too many database applications are built with the client-server desktop software paradigm, and assume that all users are in the same office. That’s not reality any more.

6. An ideal database will be open-source software. ’nuff said.

7. An ideal database will have a strong, well-supported community of developers and consultants. Most open-source products aimed specifically at the nonprofit sector have had a hard time pulling together the resources and focus to support a strong developer/consultant community. It takes substantial resources, and a very different kind of talent than the kind of talent it takes to write great code.

8. An ideal database will not be a “hosted application.” A bold statement, perhaps. But I really think the ASP business model makes it hard to focus on supporting a developer/consultant community. It also makes it hard to focus on making the code easy to install and run for anyone other than the developers. Which slows down the adoption, which diminshes the community, etc.

9. An ideal database will integrate with other tools via open standards and a well-documented API. Integrating a database with a group’s website, online advocacy tools, email broadcasting tools, event registration tools, etc. is important. The current “best of breed” tools tend to solve this problem by bundling all these functions under one system, which of course makes them expensive and bloated. Not to mention how hard it is for one shop to truly excel at all of these functions. “Small pieces loosely joined” ideas suggest that it’s better to focus making tools that play nicely with other tools via well documented, web-accessible APIs.
    
   UPDATE: A few more great ideas culled from the comments below  
   

10. An ideal database will have excellent documentation and user support resources. A corrollary to point #7 above, it’s important to also note that an ideal database must have excellent documention, an active peer-to-peer user support community, and a visible process for engaging the community in identifying both “best practices” and future needs of the tool.

11. An ideal database allows you to put your information to use. There must be a return on time spent doing data entry. An ideal database will have rich built-in reporting capabilities, along with the ability to customize, configure, and build new reports, and easy-to-use and sensible export functions to get your data out into other applications in the forms you need.

12. An ideal database makes it easy to communicate. It should allow you to efficiently generate consistent outbound communications in multiple media. This probably means a first-rate mail-merge system (whether built-in or a good, foolproof interface to an external tool) and a way to effectively send email (again, either built-in or external).

What do you think? What’s missing from this list?

SugarSales 1.5 is open-source CRM software. Very interesting. (NB: it’ll cost you $149/user/year for access to their support forums, etc.)

If I was thinking about developing nonprofit open-source database solutions, I might nose around here and see if there are any worthwhile ideas/code to borrow.

After a long period of “radio silence” the dev team at Groundspring has released some of their internal planning documents — Ebase Enterprise Specifications and Screen Mock Ups.

I’ll be reading these closely over the next week or so to get a better idea of where they’re heading, and if you have an interest in improving the state of open-source nonprofit database software, I encourage you to do the same. The spec is refreshingly non-technical, and should be readable by anyone with a decent understanding of basic fundraising systems.

They’re also looking for a graphic designer/UI specialist.

The clever folks at Center for American Progress have just launched Claims vs. Facts, a collaborative database that logs the lies of the lying liars on the right, and matches each lie against the documented facts.

What’s really neat about this is that you can submit lies and facts to the database, subject to fact-checking (duh!) by the CAP editorial team.

This is a great example of how the Internet can be used to compile valuable knowledge from many individual authors. Activists groups need to take a lesson from this, and think more about how we can tap the knowledge and expertise in our communities, using the Internet as a “listening tool.”

Nice interview with the CEO of MySQL from eweek.

Recommended Data Modeling Tools? is a recent thread on slashdot that addresses a topic that we have been thinking about a bit of late.

ONE/Northwest database-friend Matthew Scholtz recently spent some time taking a look at Rekall an open-source Access-like database frontend. Here’s what he had to say:

OK, I’ve done a bit of poking around with Rekall…

So far my impressions are that it is: definitely not yet mature, very buggy, has a visually lucid but somewhat awkward UI, and despite all of that is way more promising than I expected. THe world needs what this might eventually turn into.

First, the promising stuff:

When it doesn’t crash (unfortunately not that often) it is really simple to connect to MySQL and create WYSIWYG access-like forms to do simple data entry and display, queries are doable, etc. So far sounds like Access, except with a GPL license.

But the big advantage it has for a collaborative project is that it saves the definitions of all of its components (forms, queries, etc.) as XML files, each one as a separate file! This means it would be possible for several developers to work on different parts of a UI, and then easily reconstitute the parts at the end of the day. Even possible to run a diff on individual files, or to splice in stuff by hand if two people worked on the same component. This is the stuff that’s impossible with FMP/Access, and makes them (IMHO) much less fit for a collaborative environment. (In that way it has more in common with XUL than with Access.)

Plus it runs on Linux!

OK, the problems:

• Have I mentioned that it crashes a lot on WinXP? (OTOH, it’s usually the same error, so maybe they’ll fix it soon.)

• Error msgs tend to be completely inscrutable & unhelpful

• documentation is several versions out of date

• some of the UI is really cumbersome – uses access-like lists of properties for everything, no shortcuts – no quick way to change a label to 12-point font, for example

• the UI seems to lack keyboard shotcuts completely, it’s very mouse-intensive, hence slow

• I get the sense that it’s not really being used in production systems yet, I don’t think we’d want to be the first – I could be wrong about this

• not sure how secure it can be made – since the app is just a bunch of plaintext xml files, not sure what’s to stop someone from altering those on the fly, or if the db password can be easily hidden

• it’s unclear how active the authors will be in keeping development going / fixing bugs

• doesn’t run on Mac – but perhaps you could build it from source for OSX – not sure how possible that would be

So, my initial opinion would be: something to keep an eye on for sure, maybe it’ll be absolutely killer in 6 mos. or a year. But sadly not a good candidate for a current project.

Per today’s press release:

theKompany.com just recently released version 2.1 of Rekall, a personal, programmable DBMS system for Linux and Windows. Rekall is the only viable alternative to MS Access for Linux. With Rekall you will be able to quickly and easily build database applications using Rekall forms and reports. A full complement of widgets means that applications built in Rekall will be able to have the look and feel of any other application. Rekall applications can be extended in their functionality to perform virtually any task via embedded Python as a scripting language.

While the Windows version is GPL-ed yet, due to the fact that it requires a commercial license for the QT toolkit, this is still an exciting step forward for the vision of the open-source desktop.

The community site is at www.rekallrevealed.org.

Nonprofit relationship database provider SocialEcology announced this week that it is closing its doors. “We were unable to finance the growth we experienced in the last two years,” said founder Michael Gilbert. ” I’m just glad there are some good providers still out there.”

Michael and his team have a smart vision of how relationship management processes should work — it’s too bad they were unable to build a successful business around these ideas.

My hope is that SocialEcology will consider “open-sourcing” its codebase and supporting documentation so that others can learn from their accumulated wisdom.

Michael Gilbert just wrote a very nice article entitled Frictionless Fundraising that provides a nice overview of how we should be thinking about the fundraising process from a communications context.

It’s filled with pungent, wise insights. My favorite bit: “Modern fundraising is obsessed with the Ask. Prospecting exists only to supply more people to hit up for money. Cultivation is a detour and stewardship an afterthought.”