Comments on: Qualities of an ideal database solution for grassrots nonprofits http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/ Politics, the environment, technology, activism. And stuff. Tue, 09 Mar 2010 13:40:40 -0800 http://wordpress.org/?v=2.9.2 hourly 1 By: Matthew Scholtz http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-385 Matthew Scholtz Thu, 14 Oct 2004 18:41:13 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-385 <p>A couple of small comments:</p> <p>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).</p> 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).

]]> By: aaron vanderlip http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-383 aaron vanderlip Thu, 07 Oct 2004 23:18:14 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-383 <p>More on the open source issue:</p> <p>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.</p> <p>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.</p> <p>Beware the dual requirement of speed vs remote/web access, it is hard to make both camps happy.</p> 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.

]]> By: aaron vanderlip http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-382 aaron vanderlip Thu, 07 Oct 2004 22:21:00 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-382 <p>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.</p> 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.

]]> By: Jon Stahl http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-381 Jon Stahl Thu, 07 Oct 2004 17:47:45 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-381 <p>Cliff, I think ebasePro does pretty well by this list. I think it's biggest weaknesses are:</p> <p>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)</p> <p>Your suggestion around ease of use is a great one. I will add it ASAP.</p> 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.

]]> By: Clif Graves http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-380 Clif Graves Thu, 07 Oct 2004 17:37:13 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-380 <p>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".</p> 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”.

]]> By: Jon Stahl http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-379 Jon Stahl Thu, 07 Oct 2004 15:22:11 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-379 <p>Eric-</p> <p>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.</p> 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.

]]> By: Eric Leland http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-378 Eric Leland Thu, 07 Oct 2004 14:00:48 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-378 <p>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).</p> 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).

]]> By: Lisa Smith http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-377 Lisa Smith Thu, 07 Oct 2004 13:33:38 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-377 <p>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</p> 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

]]> By: Vermont Nonprofit CommunIT http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-376 Vermont Nonprofit CommunIT Tue, 05 Oct 2004 13:21:22 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-376 <p><strong>Jon Stahl does it again...this time with nonprofit databases</strong> During a move no less. Qualities of an ideal database solution for grassroots nonprofits: -An ideal database will have strong workflows around the membership renewal cycle. -An ideal database will be able to track more than just members and their money...</p> Jon Stahl does it again…this time with nonprofit databases
During a move no less. Qualities of an ideal database solution for grassroots nonprofits: -An ideal database will have strong workflows around the membership renewal cycle. -An ideal database will be able to track more than just members and their money…

]]> By: Dean Ericksen http://jstahl.org/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/comment-page-1/#comment-375 Dean Ericksen Tue, 05 Oct 2004 04:28:19 +0000 http://blogs.onenw.org/jon/index.php/archives/2004/10/04/qualities-of-an-ideal-nonprofit-database-solution/#comment-375 <p>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.</p> 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.

]]>