Not without some regret, I think it's time to move on from XRMS. I've been using it for almost seven years, and have made a small contribution to the code, but the fact that it is no longer being actively developed means that it has slipped behind in functionality. I'd like to offer my thanks to the developers, particularly Brian Peterson and Glenn Powers, for all their work and support in the past.
Now an odd question for the XRMS list (and possibly an inappropriate one, in which case I apologise): what CRM/ERP system should we consider? We're a small service-based business: we need contact management, lead tracking, quotes to sales order to invoicing, and it needs to be Open Source.
Grateful for any suggestions.
CiviCRM and equivalents.
I try to use and support XRMS, WebERP, and a bunch of other Web based applications. The main problem is the time the application developers spend inventing stuff that already exists in content management systems and frameworks. Switching to a framework replaces 30 percent of the code with community developed and tested code. Switching to a CMS as the base of your application results in 60 percent of your code disappearing from your workload.
The best choice for a CMS is Drupal or Joomla. There are several good choices for a framework and Drupal is one. Looking at XRMS developed as a Drupal module, you could use the core Drupal plus a number of excellent add on modules to provide all sorts of good features. You could, for instance, have a backup module without any additional work.
If you start now with Drupal 7, you get PostgreSQL support and a bunch of other things that overcome arguments against earlier versions of Drupal.
Instead of pouring a lot of time into adding jQuery and other bits to XRMS, work on adding XRMS as a module under Drupal or by expanding the existing CiviCRM and equivalent projects.
You would build one module each for contact management, lead tracking, quotes, sales orders, invoicing, etc, and open them up to other projects. Users of the Drupal based Storm project management modules could take the option of using your invoicing instead of Storm invoicing. You could use someone else's document management code. The resulting mix would be far more powerful than XRMS by itself.
My interest in using Drupal instead of XRMS started because on one project I needed to store attachments to information held in XRMS and could not do it at the time. Drupal already had all the functions I needed for that project. The basic Drupal contact management was not good enough for all the projects I worked on and I still used XRMS for some projects. Adding stuff to Drupal is easier than adding stuff to XRMS and more than half the time someone else develops the add on I need before I need it.
Mambo, the CMS from which Joomla was developed, turned to the Cake framework to speed up development. I looked at several frameworks and they all need a lot of manual work that is not needed with Drupal. The frameworks usually leave you with the job of ensuring your code is secure. The frameworks are often years behind in modern Web thinking.
A CMS also has the advantage of providing a really nice Web site when you open up part of your site to customer interaction.
News of XRMS's demise are probably a touch premature. It is true that there has been no stable version released in years, however, CVS has seen a number of improvements and that process is far from finished yet. We actually use the CVS version (rather than the stable release) with our clients since it has proved to be of sufficiently good quality to be used in production and allows us to tailor the system according to clients needs on the fly rather than waiting for the stable release. And some of it flows back to the Open Source project, for sure - most of what has gone into CVS over the last year is a result of that. The result - a slower release process but more stable, more thoroughly tested code going into it.
The challenge is that, AFAIK, 360team.ca is presently the only active sponsor of XRMS and not all of the developed code can be presently contributed back to the Open Source project, mainly due to financial constraints. However, we are continuing to work on XRMS with the goal of releasing the way-overdue 2.0 version as circumstances allow. On the other hand, I am not aware of an Open Source CRM that still comes quite close to what XRMS already does
Keith, I still feel that, as a CRM system, and especially as an Open Source project, XRMS covers the core CRM functionality outstandingly well. I would be curious to know what you mean by it having "slipped behind in functionality". This is the type of community feedback which helps shape our development priorities and, whenever the opportunity arises, we would be happy to contribute what we can back to the project.
As to Peter's comments, porting XRMS into Drupal, Cake or other framework or CMS is by no means a small or easy task and is probably more akin to rewriting the system from scratch. Considering the present project resources, this could take many months, if not years. The question then remains whether effort should be directed into doing that or improving and expanding what XRMS already does outstandingly well. From a marketing perspective, I believe a stable 2.0 version is still easier and closer to achieve whereby the project could regain some traction and possibly entertain such a port in the future when there are more hands at the keyboards and more dollars in the bank.
I would be glad to hear your thoughts on this topic - there quite possibly may have been developments out there we are not aware of or we may just be "XRMS-jaded" LOL But do feel free to let me know if a vision correction is in order :)
Have a great day, all!
Thank you for the thoughtful comments. The idea of building a CRM system using Joomla or Drupal, together with a combination of existing and custom modules, is not without its appeal, but I know that there is far more work involved in doing that than one first thinks.
Ivaylo is correct in that I should identify what I perceive to be missing from XRMS. For my company, the must-haves of a CRM are:
- Company/contact management (which of course XRMS has)
- Lead tracking. I want to know how many enquiries we received over a given period of time, how many we had meetings with, how many we issued proposals to, and how many became customers. I started to write some code for XRMS to measure this, but it didn't get completed.
Nice to have would be workflow ("six months after a customer's first invoice, create a todo that reminds me to call them"). I know XRMS has some workflow capabilities, but they are somewhat opaque (to me, at least). Another nice to have would be contacts stored in LDAP by default, or at least an automated way of propagating contact updates to LDAP.
But perhaps the biggest concern I have is the lack of community life and visible development: surely the kiss of death for most Open Source projects. I don't blame anyone; developers need to make money just like the rest of us, and will go where the money takes them. If their work can't be released under the GPL or similar, that's just how it is.
I've looked at (more than) quite a few CRM systems over the past month. There's lots out there, most of which I don't like for one reason or another. As an Open Source advocate, and as someone who runs a company providing Open Source support, I have a (perhaps unreasonable) dislike of products that have a "lite" or "community" edition of the software that is Open Source, and a richer commercial offering. To me, that is contrary to the spirit of Open Source, but again that's just my opinion. It rules out products such as SugarCRM. Sugar leads to Tigers, though, and we did look at vTiger. It's not ruled out: it does what we need, and it looks good as well (not vital, but hardly a handicap). But the code…I would prefer not PHP, although that's difficult to avoid; I'd prefer code that doesn't wrap to 5+ lines in a reasonable-width editor screen; but when I found that the default installation of vTiger has over 400 tables in the database, I have to question the design. Maybe it really does justify that number of tables, but somehow I doubt it. That reliable source of information, the Internet, abounds with nightmare stories of people trying to add functionality to (or fix bugs in) vTiger, only to be confounded by the code and/or database structure.
OpenCRX looked good - very good, actually - and I initially wondered how it had passed me by. All went well until I read the documentation about how to create a new user (http://www.opencrx.org/opencrx/2.6/admin/openCRX_admin.html#__RefHeading__18979_1778772329). I figure that if reading something as "simple" as how to create a new user three times still leaves me confused, then either the software is too complicated or I am too stupid to use it (maybe they are the same thing). Maybe I'll read it one more time and see if the light comes on.
So right now we're looking at OpenERP. Not ideal, to be honest, but it appears to be solidly written, active community, and it will do what we need, I think.
I haven't gone yet(!).
Thank you for your detailed response! It seems that the landscape has not changed that much since I last looked at it. Yes, I have investigated just about every CRM/ERP system that is out there (Sugar, vTiger, OpenCRX and many others) several times over the last couple of years and, as much as this may be a biased opinion, I think XRMS still has many advantages and at that time I had not even considered platform, database structure or coding standards. Of course, that also depends on how and what the system is used for but I have found that, for frequent interactions with a relatively large number of prospects and customers, XRMS outshines the rest.
Before starting out with XRMS I used Goldmine (a commercial CRM) for about ten years and I have to say that it is a very good product. However, they have now become prohibitively expensive for the small to medium-size business which is what led to the first switch to XRMS. XRMS actually comes closest to the older Goldmine versions in the intuitiveness, simplicity and functionality of its interface. There is still a very large gap between the two but, as far as the rest of OpenSource CRMs, a comparison cannot even be made between them and Goldmine. I found most of the interfaces so cluttered or so hard to bend my mind around that I simply gave up. I guess I had been spoiled but that also means the selection bar was set higher.
You are right that the reporting and workflow functionality of XRMS is either non-existent or leaves a lot to be desired. I myself had to crack my head in the wall a couple of times before I figured out how Opportunities and Cases work and, even after I figured it out, I found them to be quite poorly designed. LDAP, on the other hand is something we haven't had the need to look into at all so far but there is some LDAP support in XRMS which can be investigated if the need arose.
As to whether XRMS can still deliver what you need, I would say there is a possibility but it all depends on the urgency of what you need to see in it. I can tell you that we have a vague target for a 2.0 release between September and December of this year. The reason there is such a wide variance is because we are undecided on the balance between just releasing a stabilized, bug-free XRMS with the functionality it presently has (with some of it being poorly designed as it is) or, on the other hand, push the target date further into the future and enhance present functionality - yes, reporting and workflows are on the agenda, too. On the short end, we gain more users with all the support they will demand for a not-so-perfect product. On the long end, we gain a better product which can garner some developer attention as well. See the conundrum?
The other factor that is strongly influencing the development agenda is the need to generate revenue. I know you do not agree in the blended model of "lite/community" and "commercial" editions but the reality is, development costs a lot of money and, in the absence of a very wide user base whereby the company sponsoring the project can derive income from support and hosting fees alone, there is hardly any other way to support that cost in a purely Open Source model. This becomes more true the more complex a project becomes. So, in our defense, I would say that at present the blended model is the only way we can currently fund XRMS development. Our clients use a version of XRMS extended with plugins which provide functionality outside of what XRMS itself presently does. I would be happy to hear any other ideas you may have about monetizing the project but, for now, we are a bit short on any fresh ideas.
I don't know if any of the above sways you one way or another. While we'd hate to see a loyal XRMS user go, the reality is that you need to do what is best for you and your business. If you decide to stick around, we'd hope you can help us test and comment on the XRMS development - extra eyes and fingers count a lot! If not, I wish you the best of luck and I hope that the product you choose will deliver what you need.
Feel free to comment further on any of the above. However, thanks again for all of your feedback thus far and best of luck!