[software] OffstageArts and CiviCRM

[Bob]

Hello all,

I would like to introduce myself.  I am Robert Fischer, the author of
OffstageArts, one of the systems now listed at:

http://groups.fsf.org/index.php/Donor_Transaction_and_Contact_System

I wanted to share with everyone the progress I've been able to make this
weekend:

OffstageArts on Multiple JVMs
=============================

I tested OffstageArts on a variety of free and non-free Java VMs.  The
on-line demo (which is the same as the real program) now launches
successfully on MacOS 10.4 and 10.5, Windows XP, Ubuntu 8.04 and Fedora
Core 8 (and probably many others as well).  It works with Java version
1.5 or 1.6.  If you are interested in trying out the on-line demo,
please see:
	http://offstagearts.org/?q=tryit

It's worthy to note that this demo is connecting to a database over the
Internet, that is being served up via a 384Kbps cable modem uplink.

NOTE: more work is still needed on making the demo work well for
first-time users.  The biggest problem is that users click on options
that throw exceptions because they're not currently being used by
organizational clients.  If that happens, you can just close the
exception box and go on, OffstageArts generally recovers perfectly from
this kind of exception.

OffstageArts Web Site
=====================

http://www.offstagearts.org

I was able to pull together a number of materials I had and finally set
up the OffstageArts web site.  The site as it stands does a decent job
of explaining the problems that OffstageArts solves for its non-profit
clients.  I believe this information will be useful as we move forward
in thinking through specifications.

OffstageArts and CiviCRM: First Impressions
===========================================

Looking at the site:
http://groups.fsf.org/index.php/Donor_Transaction_and_Contact_System

It seems to me that CiviCRM and OffstageArts are the two systems with a
feature set and maturity that make them most likely appropriate for
non-profit organizations today.  Some of the other systems seemed to
have a lot of features that are not really useful for most non-profits,
such as inventory control.

I therefore looked at CiviCRM to see what it does and how it does it.  I
was able to run the on-line demo provided by CiviCRM.  In many ways,
CiviCRM and OffstageArts are similar; however, differences are always in
the details.  Here are my first impressions.  NOTE: these impressions
are based on a deep knowledge of OffstageArts and a shallow knowledge of
CiviCRM.  Please do not take this as an unbiased assessment of these two
products.  But I do hope it is useful as a way to jump off with some
talking points.

Sincerely,
-- Bob Fischer


OffstageArts and CiviCRM
========================

First of all, the similarities.  Both represent data in similar ways ---
as a main record with an associated set of tabs.  They've both solved
many of the common problems to be solved in a CRM system, and in similar
ways.  I had a number of Aha! moments of "oh, they thought through it
the same way I did!"

Now, the differences:

1. One of my goals when starting OffstageArts (OA) was to "think
different" and develop Internet-computing model alternatives to the
now-ubiquitous web app.  OA was my proof that real systems could be
built with these new techniques.  For this reason, OffstageArts and
CiviCRM (CC) have very different architectures:

CiviCRM (CC) is a web app, OffstageArts (OA) is a zero-install desktop
app.  CC is a three-tier application, OA is two-tier.  Both can pretty
much "run anywhere" on today's Internet/browser/plug-in infrastructure.
However, the basic difference in architecture leads to a number of
differences, both good and bad.

 a) CC requires only a web browser to run, OA requires the Java plug-in.
All computer these days ship with a browser, not all with Java.  That's
a hurdle for some users.  Maybe a small hurdle, but it's a hurdle none
the less.

 b) OA does not frame its user interface inside a web browser.  It has
complete control of the user experience and does not have to worry about
browser compatibility issues.  On the other hand, it has to worry about
Java compatibility issues (which are probably simpler than browser
compatibility).

 c) OA requires the client to run trusted code and accept a certificate,
CC does not.  Trusted code is required for some functions of OA,
especially those that write to the disk.  With work, these could
probably be worked around or put to a minimum.  On the other hand, OA's
ability to write to the client disk makes it easier to export reports
and interact with other desktop applications in an integrated manner.

 d) OA is much simpler to install, configure and manage.  Client
installation involves zero configuration.  Server installation requires
just a stock PostgreSQL server.  All the pain of messing with versions
of Apache, Tomcat, PHP, XML config files, etc. goes away.  In contrast,
a full installation of CiviCRM requires not one but two application
servers --- one for PHP and one for Java.  The on-line demo did not have
any reporting features available because apparently the Java-based
reporting engine can be an additional chore to install.

 e) One server can easily manage multiple versions of OA, since they're
all just databases to it.  Decisions to upgrade from one version to the
next are made by the user, not the server administrator.

 f) CC allows more control over security when used by untrusted
end-users.  As a two-tier application, OA requires that passwords be
managed in a way that (tech-savvy) end-users will always be able to
reverse engineer them.  On the other hand, a database account with
limited privileges can be set up for untrusted users.  Either way, users
of this kind of system are generally computer novices, unable to
reverse-engineer passwords, and fairly trusted besides.

 g) OA provides a user interface through Swing GUI widgets, CC through
web app HTML.  Which one is "better" is a debate that goes back a ways.
However, I believe that GUI widgets allow for a richer and more
responsive end-user experience.  For example: a table with 1000 rows of
data (as in the results of your search) can simply be displayed in a GUI
table that allows the user to scroll through them quickly.  In a web
app, this is typically displayed just 100 (or so) at a time with 10
"next" page links at the bottom.  GUI widget systems make heavier use of
the client's processing power to do useful things for the user.

NOTE: Recently, AJAX systems have brought GUI-like functionality to the
web application world.  This has three problems for a system like CC or
OA:
   a) it seems that AJAX applications are harder/more expensive to write
than traditional web apps or GUI apps.  AJAX is not an integrated
platform like Java or .NET.  Non-profit management software, to be
successful, must be developed in a very limited budget.  These systems
will never have the kind of programmer time that Google or Microsoft or
Apache or even the FSF can apply to their core products.
   b) AJAX apps never seem to run as smoothly as regular desktop GUI
apps.  It is interpreted JavaScript, after all.  And they often have
funny weird glitches...
   c) Significant AJAX infrastructure requires significant download
times, and AJAX apps have no caching mechanism.  OA, for example, is
based on about 1Mb+ of GUI infrastructure libraries.  Download times can
be masked by increasingly complex load-in-the-background schemes --- at
the cost of more programmer time and software complexity.

2. Both systems allow for customizations, which involve the addition of
client-specific fields to the database.  However:

 a) CC provides a point-and-click way to customize the system.
Customizing OA involves modifying the DB schema, writing small Java
programs and uploading them into the database.  Although CC's method can
be considered to be "no programming," in reality only technical people
will be customizing the system; non-profit end users can't do this stuff
either way.  OA's approach is to make customization as simple and quick
as possible for technical consultants, who can then service non-profits
at low cost.

 b) OA allows for more extensive and specific customizations, since it
involves Java code and subclassing.  Currently available customizations
include fields, tabs, screen layouts, even complex fee structures.

 c) OA allows for customized "tabs", which provide many-to-one
relationship views.  For example, a tab would be used to record
donations, since there are many donations per contact.  Although CC does
have many-to-one tabs as part of the system, it does not seem to allow
them to be added via customizations.  (Fields added to tabs seem to be
only regular fields, with one field per customer).

3. One of my clients really likes OA's summary view --- which allows him
to see all aspects of a contact's relationship to the organization
at-a-glance.  I think I saw a screen in CC that does this, but I'm not
100% sure.

4. Both systems have surprisingly similar "advanced query" systems that
allow the user to select out sets of records and can drive some reports.
Both query systems allow querying based on customized fields.  However,
the differences:

 a) The query system in OA is more powerful than that in CC, in a few
details.  To what extent this additional power matters depends on the
client's needs.  However, all of OA's query capabilities were driven by
client need.

 b) OA uses its query system for all reports: selecting or creating a
query is a step in the production of each report wizard.  CC does not
use its advanced queries for all reports.  For example, the type of
querying available for mass mailing is limited when compared to the type
of querying available through CC's advanced query mechanism.

 c) OA reports are generated by combining a query (which selects a set
of records) with a report (which produces the columns for that report).
Separation of the rows from the columns in report generation provides
for great power: queries are generally created by the end user, and
report columns are more frequently defined by the programmer.  CC does
not seem to have this separation of queries from reports.  The result is
that more hacking and customization by consultants is required to make
the reporting work well for an organization.

 d) OA defines a number of pre-set reports (columns) that can be
combined with any query.  One of these reports is used to export data to
a spreadsheet: it gives the user flexibility in the rows selected, but
not the columns.  The assumption is the user will delete the columns
he/she doesn't want from the resulting spreadsheet.  CC gives users more
control over the columns in data export --- but requires that they list
the set of columns they want when they export.  This could be tedious.

 e) CC has a generalized feature for data import, OA does not.  OA
import requires writing quick but specialized programs.  OA could be
improved in terms of end-user-capable generalized data imports.  On the
other hand, OA offers more control over how imported records are matched
up against and merged with pre-existing records.

 f) OA integrates a variety of reporting engines, depending on the
report (most of the code bloat is due to these engines).  It can do mail
merge-type reports, CSV reports, XLS reports, HTML reports, PDF reports,
JasperReports, etc.  CC reporting options seem to be more limited to CSV
data export and XML (including HTML)-based reports.


5. Beyond CRM functionality, the two systems have surprisingly
non-overlapping feature sets.  CC is strong in donor/pledge management
bulk emailing, event management and credit card processing --- areas
that OA is currently playing catch-up in.  OA is strong at SnailMail
marketing, and it encompasses arts-organization-specific features that
CC does not do at all: school management and ticket sales.

6. CC seems to implement its own bulk mail service.  Given that
(reputable) ISPs can be very skittish about bulk email, I'm not sure how
well this works in practice.  But with proper throttling on the server
side, it could probably work pretty well, for mailings of up to about
5,000 recipients.  OA's approach is to integrate with existing
commercial bulk-mail back-ends, which provide CAN-SPAM compliance and a
high degree of deliverability.  OA is proposing its own SMTP-based bulk
mailer, similar to CC's, because many organizations can't pay for bulk
mail providers; that would provide OA users with a choice of bulk mail
providers.

7. CC bulk mail operations have the user compose the email through a web
page.  OA does not try to offer email composition tools; instead, it
asks the user to compose an email with an existing email client, then
send it to an IMAP account where it is picked up as a template.  This
saved a lot of coding effort.

6. OA integrates general ledger functionality, which is used for all
financial transactions (school billing, pledge management, etc) and
integrated with an accounting system.  I was not able to determine to
what extent CC keeps accounts, and whether or not it can be integrated
with an accounting system.

7. CC is a more mature product.  It has a significant user base and
community of developers.  OA is just starting out on the process.

8. CC has had many more hours of programmer time put into it, probably
about an order of magnitude.  It has about 10 programmers working on it
so far, vis a vis OA's one.  Given this disparity in investment, it is
likely that OA development can continue to be accomplished in less time
for a similar result.  For example, an OA event management system would
take no more than a couple of (full-time) days to implement.  On the
other hand, the skills required to work on CC are easier to find these
days.  OA is based on newer software engineering technology that, while
impressive, has not yet built widespread mindshare.

9. It's hard to tell, but my guess is that OA setup and customization
can be accomplished in less consultant time than CC.

10. CC provides customer-facing features.  For example, constituents can
donate on-line.  OA has plans for web-based customer-facing features
such as on-line school registration, ticket sales and donations --- but
no implementations as of yet.  Once OA's customer-facing features are
built, then deployment of them will require more complexity again.


CONCLUSIONS:
------------

 1. Either OA or CC would be a viable choice for a number of
non-profits.  CC has more mature donor management and on-line
capabilities; OA has more features needed by arts organizations.

 2. OA is built on a newer application infrastructure that allows
features to be built in a flexible manner in less time.  CC is built on
more mature technologies that are widely understood today.

 3. Both systems offer installation-free use.  Both avoid the need for
an in-house IT infrastructure.  Both require a consultant to do initial
set-up and customization.

 4. OA is a GUI-based two-tier application; CC is a web-based three-tier
application.  The pros and cons of those two approaches are evident
throughout. OA's architecture makes it simpler to install, configure and
manage in many respects.  CC's architecture makes it easier to implement
customer-facing features.