That prompted me to run some searches which turned up a couple of CRM reviews including Luxor:

“Hosted CRM Services for Marketing and Sales – Free & Paid” (no date)
http://www.allen.com/cgi-bin/gt/tpl.h,content=98

“CRM Comparison” (November 2008)
http://www.180systems.com/crm-comparison.php

LucaS
P.s. three days ago I seat in front of you in “Orzo Bruno” Pub (Pisa)

We’ve been internally discussing the option of releasing on2biz as open source. Some issues that we’ve not been able to resolve but which we are trying to is the lack of adequate documentation on our part. Having evolved the code over more than 10 years now, it will take us some serious investment in time to create usable documentation without which community participation would be infeasible.

Any ideas welcome

The front end is using jquery and javascript with custom plugins.

We started development on On2Biz in 2006, but have developed several other process specific enterprise solutions on the same framework, which you can read about (horribly brief) at:
http://www.reach1to1.com/solutions/

Would be great to get some feedback from the Perl community!

Don’t you hate that.

I forgot to mention that subsets of the data can be selected for reporting to the screen or printing to sticky labels.

And yes, that includes donations between a pair of dates.

I’m writing a module, CGI::Office::Contacts, which may be relevant. I don’t think of it as CRM actually, since to me that implies sales and prospect tracking, about which there can be a type of ruthlessness which I find repugnant. Nevertheless, I do realize my module could be used in that fashion. Email me directly if you wish. Details follow.

Name: CGI::Office::Contacts.

Author: Ron Savage.

Home page: http://savage.net.au/.

Language: Perl.

Open Source: Yes.

Licence: The Artistic or the GPL Licences.

Release date: Late July 2009.

Overview:

a) Group and private address books.
b) Multiple email addresses per entity (person or organization). Default: 4.
c) Multiple phone numbers per entity. Default: 4.
d) Various other attributes per entity.
e) Multiple sites (physical addresses) per entity.
f) Multiple notes per entity.
g) UTF-8 ready, but needs testing.
h) Perl DBI based.
i) Perl Moose based.
j) Javascript library is YUI (Yahoo User Interface – http://developer.yahoo.com/yui/).

Test environment: Debian, Perl, Postgres, FastCGID.

Status: Code written, and original version being restructured at the moment,
basically to remove the single Apache-dependent handler, and replace it with
multiple controllers in the MVC style. New controllers use CGI::Application
and CGI::Application::Dispatch.

Add-ons: CGI::Office::Contacts::Donations.

Overview:
a) Multiple monetary donations per entity.
b) Foreign currency conversion.

Status: Code written, and being split out of original version at the moment.

http://www.opensource.org/node/163

If your key concern is “that if we open source our software, we would see agencies using our code to create a customized version to lock in clients” then I wonder if the focus of licensing discussions should be around easy data migration. The licence could be based on Affero GPL with an additional stipulation that the source code must retain the ability for the user to export all their data in a reasonable format. (Think http://www.dataportability.org/) I’m not a lawyer so I don’t know how practical that approach would be, but I think it’s a more “open” approach than NOSL3.

To my mind, for a company to take their software product means being willing to “ride the tiger” of community building and contributed innovation. Being willing to accept the risk that someone might fork the project and accept the challenge to do a good enough job of that no one would want to fork the project.

Avoiding data lock-in for users is an interesting problem. Requiring data portability seems like a reasonable approach. “Open Data” as a parallel and complementary concept to “Open Source”. (I know Open Data isn’t quite the right term here, as it means something different, but indulge me.)

With regard to your second point, don’t wait work in isolation till it’s ‘good enough to release’. There’s a good reason for the “release early, release often” mantra. The developer community you want to build will find and help fix the important issues for you. Just be honest with them. What will taint your long term reputation with developers is an unwillingness to work with them.

I hope at least some of this advice counts as “sage” :)

Regarding open source – I’m the ceo and cto, so I guess I qualify as management. I am still very interested in open sourcing our code, but I have two challenges:

1) License choice – We spent a year researching licenses and engaging with the Software Freedom Law Center (softwarefreedom.org). From my perspective, we never found a license that went far enough. We created the DonorWare Foundation (www.donorware.org) as a 501(c)3 to be the sole owner of our company. We are so committed to helping charities and non-profits, we wanted to make sure we were owned by a non-profit. Our goal was to not just open source our software, but to “open source” the company by making our owner a 501(c)3. (As an aside, Kevin Kelly of Wired.com has an interesting article on some related trends: http://www.wired.com/culture/culturereviews/magazine/17-06/nep_newsocialism)

So the question is not one of motivation, it is one of execution. In the marketplace we serve, a larger charity might have an ad agency that might charge a lot of money (six, almost seven figures) to “help” the charity raise its funds. Most of these agencies are looking for ways to lock their clients in to prevent the client from leaving. My concern is that if we open source our software, we would see agencies using our code to create a customized version to lock in clients, and thereby exploit our code for profit, rather than to help non-profits. I know the Affero GPL would force them to give changes back to us, but I’m not sure it goes far enough. I actually want a Non-Profit GPL that says you can use our code for free as a non-profit, or you can use it for free to host our software to help non-profits, but you can’t exploit our code to make money off of charities and non-profits. When I pushed for that with the Software Freedom Law Center, I was told that would make it a non-libre license, and therefore not something they could support. I think the Non-Profit Open Source License ( http://opensource.org/licenses/NOSL3.0.html) would achieve what we want, bit I don’t think it is GPL compatible, and I need to better understand how the open source community would react to something like NOSL3 vs AGPL. All that to say, the idea is not dead, but we put it on the back burner for a bit to think about licensing options.

2) Complexity – our system is non-trivial to package and distribute. We have a lot of configurable features and systems that would be overwhelming for most non-profits. To be honest, it is easier for us to scale up to an organization with millions of donors raising tens of millions of dollars per year, but it is harder for us to scale down to the organization with a few thousand donors and a few users. Until we solve that issue, I am hesitant to open source for fear that the first impression of the early adopters (who would likely represent small organizations) would taint our long term reputation.

I am open to any sage advice.

Mike.

p.s. Looking at the home page I asked myself “what is plusthree?” and I couldn’t see a clear answer. I’d suggest adding some kind of tagline.