Qualities of an ideal database solution for grassroots nonprofits

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?

10 thoughts on “Qualities of an ideal database solution for grassroots nonprofits”

  1. Databases are extremely difficult (costly and/or complicated) to tailor to grassroots organizations, but these points go a long way to help them go through the self-analysis cycle to identify what they need. Bravo. I would also underscore and extend point four to say that an ideal database would not only have supreme ease-of use (thoughtful UI, etc) but also thorough documentation and self-help how-to resources so that novice-to-expert users can get the information they need to make the most of the database.

  2. It’s a pretty good list, actually excellent although I wonder if we are moving to the point where nonprofits need to be thinking of having data warehouses. Data warehouse may be to big for the nonprofit world but I’m beginning to think a relational database alone can’t handle all the things we need to be able to do with information. I think to accomplish all of the outlined goals it might be better to have a relational database to handle data entry and then do the linking thing to create reports charts etc from a read only version that is set up on a object model to facilitate read only queries and summary queries. Maybe this is one database with several different forms but I think you might need two to optimize the queries depending on the size of the database. For example I often run summary queries pulling information from five tables in an MS Access database with 20,000 records in the resulting query. it was taking so long to run these queries that I finally set up a make table query and then ran my query from the table rather than the query to improve the return time of the query. I’m obviously spit balling but I’d love to hear other peoples thoughts on the relational vs dimensional and or if we need to move toward data warehousing and mining

  3. Good list Jon. I would add that an ideal database needs the ability to flexibly track interactions with constituents. Nearly all nonprofits have needs to understand that people are involved in agency projects/programs, and some measure of how they are involved. So for example, while many agencies hold events, agencies differ widely on what amount of the registration, confirmation, attendance and follow up interactions require tracking. Similarly, many agencies track services provided to clients (case management), application/approval processes, donor development processes, all of which have different levels of states through which a person progresses, and these are defined in various ways by different organizations. An interaction tool that allows for the flexible tracking of less complex examples of these processes would be a boon for nonprofits, who are otherwise stuck with buying bloated, one-feature strong dbs or tracking this in decentralized lists/spreadsheets. An example of such flexible interactions is being developed/refined by the Fund for the City of New York, in there Metrix DB (metrix.fcny.org).

  4. Eric-

    I totally agree with you — my point #2 about “tracking more than money” was at attempt to get at this thought. Metrix is a very promising product whose major “missing ingredient” at this point is sufficiently strong donor/member management workflow, although the team has recently contracted with some pretty smart folks to work on that problem.

  5. Jon this is a great list. I can say that because it fits well with my own thinking 😉 Currently ebasePro should get a B+ or low A on your list. As time goes on I hope it hits all 9. The one very hard thing I would add as 10 is “An ideal database will provide an interface which allows users successfully do basic tasks with little or no training”.

  6. Cliff, I think ebasePro does pretty well by this list. I think it’s biggest weaknesses are:

    1) the “FileMaker Tax” which makes ebase pretty expensive for multi-user environments
    2) the difficulty of enabling remote user access (except via remote control/Terminal Services)
    3) lack of a real API layer (getting data in and out via email is not really good enough long term)
    4) the relatively scarcity of FileMaker consultants (the non-open source nature of the underlying FileMaker platform may well deter potential some open-source contributors)

    Your suggestion around ease of use is a great one. I will add it ASAP.

  7. Actually, not enough said about the software being open source. Do you mean front to back open source, or just one layer; code is open source but the runtime may not be? Also what about cross platform?
    What kind of license? All important issues. Thinking out loid the Zope platform would be a good place to start, fits most of the criteria.

  8. More on the open source issue:

    Take for instance Java. You could have an open source Java
    product, but Java itself is not open source. You could run
    the Java product as a web application on a Tomcat server
    which is open source, but due to performance issues (remember
    you mentioned speed as an issue) you may want to go with a
    proprietary product (JServ) to speed things up.

    You can have an application where you can read the source and
    modify it (so it is open source), but the licensing would not
    allow you to share those changes with the rest of the world.
    Personally I look for technology that is not dependent on one
    company, that doesn’t nickel and dime you for added libraries
    or features, that is easy enough to maintain, has
    documentation, and if it is open source, is not controlled by
    petty tyrants. I also choose software that is multi
    platform, which is usually a side effect of it being open source.

    Beware the dual requirement of speed vs remote/web access, it
    is hard to make both camps happy.

  9. A couple of small comments:

    I would add a requirement around reporting/output. Something like: an ideal database allows you to put your information to use (there must be a return on time spent doing data entry). There are rich built-in reporting capabilities, ability to customize, configure, or build new reports, and easy-to-use and sensible export functions to get your data out into other applications in the forms you need. Also: it should allow you to efficiently and consistently make the communications happen that you need. This probably means a first-rate mail-merge system (whether built-in or a good, foolproof interface to an external tool) and some way to effectively send email (again, either built-in or external).

Comments are closed.