Customer Relationship Management (CRM) systems in Perl

/ TimBunce

I’m looking for a CRM system implemented in Perl. As it turns out, so are the Perl Foundation.

So I thought I’d summarize my interpretation of the comments on that thread, as much for my own benefit as yours, and see if this post flushes out any further information.

We’ll start with the smaller/personal projects and work up from there…

John Cappiello

John mentioned that he was working on something. I sent John an email to ask for an update and he said it had “morphed away from a CRM into something not really overlapping much at all”.

Gábor Szabó

Gábor Szabó mentioned in the thred that he has “a simple CRM I use in-house that I plan to release as open source one day. It is written in Perl. While it is very minimalistic if you are interested I can show it and we can discuss what additional features TPF might need.”

Affinity

Affinity was mentioned in the thread, but I can’t find any references to it being open source.

CustomX

The web pages are in German, so here’s a translation to English of their web site, which gets visually mangled in the process, and a much more readable translation of their 2006 whitepaper.

It’s available under the Perl Artistic License. The base language is German. I don’t know what level of internationalization/locaization they support.

They currently use mod_perl v1 and say it’s “not tested” for v2, which seems to suggest a lack of maintenance. Databases supported include Postgres, Oracle, MySQL, and Informix. It’s extensible via plugins.

I couldn’t find any indication of a development community.

Wice CRM Groupware

Another German CRM system, so here’s a translation of their home page. It’s in use by a range of companies, and they even have a glossy magazine (though it looks like a once-off produced in 2005).

“Wice is a LAMP system with Linux as operating system, Apache as web and application server, MySQL as the database and the system is developed as an Apache module in mode_perl.”

“We have Wice a plugin architecture, which we almost arbitrary adjustments, enhancements and interfaces can be realized […] There are also numerous standard plugins, such as a web, an integrated CMS, or a Customer Self Service Center.”

The source code is not ‘free’, however. You get the source code only when you licence the software.

Donor.com

“Our software has been serving non-profits for 30+ years. We have spent the past 5 years wrapping all of our C-based business logic with Perl to expose everything as Web Services (50 modules and 300+ methods so far). Our presentation layers are the WebGUI CMS (also Perl) and a cross-client GUI (Win/OSX/Linux) written in wxPerl. Our systems integrate everything from CRM, inventory management, event tracking, credit card processing, bulk email, direct mail, magazine subscriptions, sponsorships, etc. Almost everything in our system is configurable. We have not yet open-sourced all of our code, but we did just transition our ownership to a new 501(c)3, the DonorWare Foundation, to help facilitate that in the future.”

Jim Brandt replied to comment in the thread saying “I got another response from the folks who run donor.com. Turns out they are heavy perl users, so we’re looking at their system right now to see if it will meet our needs. I’ll post with more details once we know.” No news yet.

Josh Berkus expressed some pros and cons of using donor.com.

Other Perl CRM Systems?

What have I missed? Are there any other open source CRM systems out there implemented in Perl?

For comparison, here are some details (mostly skimmed from Wikipedia) of open source CRM systems not implemented in perl…

CiviCRM

Designed to meet the needs of advocacy, non-profit and non-governmental groups. Implemented in PHP. The license for the current version is the GNU AGPL 3.

CiviCRM may be deployed either standalone or alongside Drupal and Joomla! content management systems. Both the Drupal and Joomla! professional associations use CiviCRM. The standalone version is intended to work alongside other CMSs.

CiviCRM is used by many large NGOs including Amnesty International, Creative Commons and the Wikimedia Foundation for their fundraising.

They’re currently considering a new architecture:

In short, we propose using PHP Doctrine for the ORM layer […] we propose using thin controllers which speak XML and JSON. All UI is subsequently pushed directly to HTML, JS and jQuery. The controllers and the UI are connected through authenticating RESTful interface.

Link to the CiviCRM project page at Ohloh.net.

vtiger CRM

An open source fork of SugerCRM. Implemented in PHP, initially released in 2003. Seems to be supported by AdventNet, who make a non-open source Java based CRM called Zoho. Licences: vtiger Public License 1.1 and SugarCRM Public License 1.1.2.

Hosted at sourceforge. Link to vtiger project page at Ohloh.net.

epesi BIM

Implemented in PHP. Links to the developers wiki, forums, and Ohloh.net project page.

A search on Ohloh.net for tag:crm yields 649 projects with the CRM tag!

It turns out that Ohloh is a great way to look for projects. The Analysis Summary on each project page gives a useful overview of some key metrics: “Large, active development team”, “Few source code comments” etc.

Sorting the list in various ways and taking the projects (other than those above) that appear on the first page of each, gives this list, in no particular order:

OpenERP

“Python. Formerly known as TinyERP. OpenERP is an Open Source enterprise management software. It covers and integrates most enterprise needs and processes: accounting, hr, sales, crm, purchase, stock, production, services management, project management, marketing campaign, management by affairs, …

Once in production, it automates and help you to control all activities: sales triggers manufacturing orders, accounting entries are updated by stock operations, incoming mails are tracked in the system, the integrated document management system helps your team to collaborate, …”

Open For Business Project (Apache OFBiz)

Java. “The Open For Business Project is a set of tools and enterprise applications including ERP, CRM, e-commerce, SCM, MRP, and CMMS/EAM. It uses a service oriented and events driven architecture and tools to automate all aspects of application development and maintenance.”

Omni ERP

Python. “Omni ERP is an innovative business application platform; it is completely based in open source technologies and brings a whole new level of modularity and flexibility to the business solutions environment.
It uses a new approach combining new software engineering techniques like plugin based architecture, inversion of control and aspect oriented programming with a refreshing new RIA UI to bring a new level of experience to the SME market”

ADempiere

Java. “ADempiere Business Suite ERP/CRM/MFG/SCM/POS done the Bazaar way in an open and unabated fashion. Focus is on the Community that includes Subject Matter Specialists, Implementors and End-Users. We are a community fork of Compiere”

ERP5

Python. “ERP5 is a full featured high end Open Source / Libre Software solution published under GPL license and used for mission critial ERP / CRM / MRP / SCM / PDM applications by industrial organisations and government agencies.

It is distributed to linux community via packages for numerous distributions (Mandriva, Debian, Ubuntu,…) and a dedicated Live CD.”

JFire

Java. “JFire is an ERP, CRM, eBusiness, and SCM/SRM solution for business enterprises. It uses JavaEE, JDO, and Eclipse RCP, and is designed to be highly customizable. It is a complete and extensible solution that fulfills business needs like user management, online trade with business partners, points of sale, various distribution channels forming a distribution network, store management, etc.”

CK-ERP

PHP. “CK-ERP is an open source accounting / MRP / ERP / CRM system that runs on top of multiple middlewares. It provides accounting and back office functionalities to SMEs and utilizes the underlying middleware to administer accounts/groups.

It comprises 22 modules – Administration, Multilingual Facility, Contact Management, Customer Relationship, Customer Self Service, Vendor Relationship, Material Requirement Planning, Warehouse, Inventory, Service, Accounting Ledger, Bank Reconciliation, Accounts Payable, Accounts Receivable, Purchase Order, Sales Order, Quotation, POS for Cashier, POS for Manager, Human Resources, Staff Self Service and Payroll.

Operating platform can either be LAMP or LAPP. Backend database engine can be anyone of MySQL, PostgreSQL and SQLite”. Oddly, their home page says “minimal documentation will be made available to users of CK-ERP” and their roadmap is old.

Blue ERP

PHP. “Blue ERP is an open source, web based ERP application. Its goal is to provide a flexible and user friendly interface that can work out of the box and be modified to suit specific needs easily.

The main goals of the projects are:* provide a feature full ERP application
* be open in licence and in spirit – in blue ERP everything is open, especially the development
* be user friendly by providing adequate documentation and assistance to users to encourage widespread adoption”

OTRS::ITSM

After all the PHP systems, it’s nice to find one implemented in Perl! Though the description suggests it’s geared towards the needs of an IT Service organization.

“ITIL compliant Open Source IT Service Management Solution (ITSM). Requires the OTRS (Open Ticket Request System) framework.

Besides all OTRS features, new ones include Incident, Problem and Configuration Management, integrated Configuration Management Data Base; process spanning Communication management: within the IT Service organization, towards Customers/Users/Management and Suppliers/Providers; powerfull statistical features for (Trend-)Analysis, key figured Reporting, ITSM-Planning/-Controlling; flexible configuration, customizing and expandability regarding your individual requirements.”

[That’s quite enough “CRM” systems! Ed.]

24 thoughts on “Customer Relationship Management (CRM) systems in Perl”

  1. any specific reasons why it has to be in perl? can you talk to the CRM / DB layer via well defined interfaces and an API. We have a core group of users who are focussing on and working on improving the API

    with regard to the “new architecture” thats just a proposal from one commercial company at this stage. We have not yet given this any serious thought or consideration. However we do like to evolve and improve on a continual basis :)

    lobo

    • Hi lobo (CiviCRM). Perl is a preference simply because that’s the core skill set of the developers and the preferred language of the company. Using an API is great, so long as the API offers what’s needed. As soon as it doesn’t (which is almost inevitable) then we’d need to extend the system and that would naturally be easier if it’s implemented in a language we know well.

  2. At my work (http://plusthree.com) we have a CRM as part of our online fundraising tool (integrated with the open source Perl Krang CMS). We don’t yet support offline transactions, but that’s on the schedule. I’ve also talked with Jim Brandt that if the current path with donor.com doesn’t work out we’d be willing to help them out.

    • Thanks Michael. Is it Open Source?

      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.

  3. Feel free to send any questions about the donor.com solution to me – lots of Perl in use: wxPerl cross-platform client for Windows, Mac and Linux, around 500 API methods exposed via Perl-optimized libraries, (we also have clients accessing our APIs via PHP and Python), we just added an iPhone interface for managing your donors and case loads, and we are a PCI Level 1 Service Provider to keep all your credit card and EFT data secure. Sorry if that all sounds too “salesy” – just wanted to say hello and make myself available to any questions you might have.

    • Hi Mike. Two quick questions… a) Can you give us a URL to the docs, including the API docs? b) Has the management made a firm commitment to open source the software?

      • Hi Tim – thanks for the questions. Send me an email to mike AT donor DOT com and I’ll email you back with a login to our online manuals and API reference docs.

        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.

        • Thank you for the detailed reply Mike.

          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” :)

  4. Hi Tim

    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.

  5. Hi Tim

    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.

  6. We have developed a sales workflow solution in Perl called On2Biz. The back end is completely in Perl. The architecture is explained here:
    http://www.reach1to1.com/about-us/the-wolfkrow-framwork/

    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!

      • Hi Tim

        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

        • Don’t worry too much about the quality of the docs. If your system fits the needs of others then they’ll help fix the docs for you. You just need enough docs for developers to get the thing installed and running, and provide a rough overview.

        • Thanks for the encouragement, Tim. We sure will consider the option more seriously. Actually its just nice to have someone from the Perl community show some interest – and we’d be more than happy to have more community support.

  7. Hi Tim,
    I start to develope IGSuite in Perl in 1998. It’s basically a Groupware but integrated with about 24 other modules that extend its features to CRM, ERP, CMS, PIM solutions. Sorry, ther’s not enought english documentation, but you can try a live demo on demo.igsuite.org

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

  10. Pingback: Perl crm | Winnersatgamin

  12. Pingback: Customer Relationship Management CRM systems in Perl – CRM China

Comments are closed.