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.
1. **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.
1. **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.
1. **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.
1. **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.
1. **An ideal database will be open-source software.** ’nuff said.
1. **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.
1. **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.
1. **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
1. **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.
1. **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.
1. **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?