The answer is yes. openCRX has always been published with an OSI certifiedBSD-style license. We have nothing to hide and none of our code is proprietary.
By the way, you should not understimate the importance of your question. Numerous CRM applications claim to be Open Source when in fact they are not. Read Will The Real Open Source CRM Please Stand Up? on the OSI Blog for additional information.
It is the hope of the openCRX team that lots
of bright people are going to join the effort to make openCRX the
tool of choice for limitless relationship management.
If you can contribute or want to co-operate
or have a look at the information on our community page.
Any kind of support is appreciated.
If you want to make a donation to support the development of openCRX, you can do so through PayPal:
The core team consists of 3 people (although we should probably make this 4 due to the close co-operation with the openMDX team). Please do not jump to conclusions like "too small, no power, etc. " just because you are not familiar with MDA (Model Driven Architecture). It is quite appropriate to apply a quality-adjusted productivity factor of at least 10. Furthermore, consider the lack of overhead as we do not need to synchronize hundreds of developers.
In addition to the core team there are lots of translators (see list of available locales here) and dozens of community members providing important input to keep openCRX moving.
This project's CVS repository can be checked out through anonymous (pserver) CVS
with the following instruction set. The CVS tree is publicly accessible for anonymous read-only access, approved contributors will also be given commit access to appropriate packages. When prompted for a password for anoncvs, enter
anoncvs.
Linux / Unix / BSD
Windows
CVSROOT=:pserver;username=anoncvs;password=anoncvs:cvs.opencrx.org:/CVSROOT
export CVSROOT
cvs login # enter anoncvs when prompted for a password
cvs checkout opencrx
Which CalDAV Clients can I use to connect to openCRX?
Please note that you're preferred client might still work with openCRX, even if it is not listed below.
Mozilla's Sunbird and Mozilla's Lightning, the calendaring add-on for Mozilla's Thunderbird, are not only the best-tested cross-platform CalDAV clients, they also work flawlessly with openCRX. We tested Sunbird 0.7 and Lightning 0.7 (with Thunderbird 2.0). These CalDAV clients work very well in a setting where you're always online (i.e. connected with the openCRX server) as changes to remote calendars are submitted immediately. Neither Sunbird nor Lightning are well suited for working offline (e.g. it is not possible to enter/change information while offline so that it will get synchronized during the next online session). We have found, however, that ICS/iCalendar Access is much faster than CalDAV Access, as Sunbird/Lightning request the full calendar whenever a view is changed (e.g. moving to another week, etc.).
Mulberry kind of works - seems a bit sluggish, though.
We have not been able to get OpenConnector's CalDAV feature to work properly with Outlook and openCRX, but based on the information published on the project's website (http://openconnector.org/) you will probably have to wait for a later version or hope for Microsoft to get their act together and add CalDAV support to Outlook (apparently, Microsoft joined CalConnect on 15 August 2007 - let's hope they did not join to slow down everything...). As an alternative you might consider our Outlook ICS Adapter.
Which ICS/iCalendar Clients can I use to connect to openCRX?
Please note that you're preferred client might still work with openCRX, even if it is not listed below.
Mozilla's Sunbird and Mozilla's Lightning, the calendaring add-on for Mozilla's Thunderbird, are not only the best-tested cross-platform ICS/iCalendar clients, they also work flawlessly with openCRX. We tested Sunbird 0.7 and Lightning 0.7 (with Thunderbird 2.0). These CalDAV clients work very well in a setting where you're always online (i.e. connected with the openCRX server) as changes to remote calendars are submitted immediately. Neither Sunbird 0.7 nor Lightning 0.7 are well suited for working offline (e.g. it is not possible to enter/change information while offline so that it will get synchronized during the next online session).
The "should"-part of the question is more difficult to
answer without knowing more about your requirements and constraints.
While
the
table below may be somewhat helpful in your decision making process,
the answer to your question boils down to getting clarity on the
following 3 issues:
how much performance/scalability do you need in terms of #concurrent users, database size, etc.?
how much money are you willing to spend on DB licenses (it is just a
fact that none of the Open Source DBs can really keep up
with Oracle)
if you already use a DB that would work with openCRX why use another
DB?
A note on free DBs: due to the pressure from Open Source DBs various vendors of commercial DBs started offering free versions of their commercial products. Before you jump to any conclusions, however, it is worthwhile reading the small print of those offers. It pays off to understand the limitations/conditions/licenses in order to avoid an unwanted lock-in (example: any free offer with a limit on the size of the database is going to hurt you sooner or later as using/working with openCRX is equivalent to adding data - 4GB may sound like a lot today but once you've added 100'000 accounts and 200'000 sales orders you will probably be past that limit...). The highest performance free DBMS without a limit on the size of data we are aware of is DB2 Express-C.
openCRX v2.0
does not yet
support the
64bit versions
* Please note that we do not recommend HSQLDB or MySQL for production use. The lack of cursor-support leads to lots of table scans resulting in low performance for large data sets. MySQL v5.x might solve some of these problems. If you are a very experienced MySQL DBA you might be able to tune your instance so that it performs
Please note that the "limitations" listed
in the above table are not hard numbers, but they are based on
our experience and on the assumption that users expect decent response
times.
openCRX v2.0+ is a J2EE application and openCRX EARs can be deployed on Apache Tomcat 6 and - in principal - on any J2EE-compliant Application Server. The openCRX project officially tests and supports the following deployment scenarios:
JDK Version
Required openCRX Distribution
Apache Tomcat 6
1.5
openCRX 2.0 for JDK 1.5
JBoss 4.2.x.GA
1.5
openCRX 2.0 for JDK 1.5
The project team has come to the conclusion that it is in the projects interest to focus on the above deployment scenarios. Hence, the current policy:
New versions of openCRX are tested with Apache Tomcat 6 and JBoss as indicated in the table above.
New versions of openCRX include deployment descriptors for various application servers (including JBoss, BEA
Weblogic, IBM
WebSphere, Sun Java System Application Server, and JOnAS). However, the project team does not allocate resources to testing such deployment scenarios; if you managed to successfully deploy openCRX on any application server other than JBoss, please provides us with the respective information (e.g. updated deployment descriptor(s), name and version of the application server, deployment instructions) so that we can make it available to the community.
If you need support for a particular deployment scenario, please contact one of the openCRX Partners or CRIXP Corp.
What are the hardware requirements to run openCRX?
openCRX is the kind of enterprise-class J2EE application that will not make you happy if you install it on your old PIII-500 with 128MB of RAM. Use the following information to arrive at a rough estimate of your requirements:
Test /
Development
Single User
Small Size
#concurrent users*
1
1
up to 100
#users
1
1
up to 500
suitable type of box
- laptop
- desktop PC
- laptop
- desktop PC
- desktop PC
- server
minimum
(normal performance)
CPU
RAM
1 x 1GHz+
512MB
1 x 1GHz+
512MB
1 x 2GHz+
2GB
recommended
(high performance)
CPU
RAM
1 x 1.5GHz+
1GB
1 x 2GHz+
1GB
2 x 2GHz+
4GB
Enterprise
#concurrent users*
50 .. thousands
#users
100 .. thousands
minimum
(normal performance)
AppServer
DB Server
2 x 2GHz+, 2GB RAM
2 x 2GHz+, 4GB RAM
per about 150
concurrent
users
recommended
(high performance)
AppServer
DB Server
2 x 2GHz+, 2GB RAM
2 x 2GHz+, 6GB RAM
per about 100
concurrent
users
* concurrent users means users generating server requests concurrently - under normal working conditions 1 concurrent user is roughly equivalent to 5 to 20 typical users.
In an environment with considerable load it is advisable to consider a multi-tier deployment scenario; additionally, you might consider setting up clusters for tiers with heavy load; clustering is also used to increase availability and to introduce fault tolerance. The following chart shows a 4-tier deployment scenario with clustering, providing mission-critical services suitable for tens of thousands of concurrent users:
verify your deployment scenario - while a single server (2 x 3GHz CPU, 6GB RAM) can typically handle up to a few hundred users, you should consider a multi-tiered deployment scenario (potentially with clustering) to distribute the total system load
DB tuning - while the default distribution of openCRX includes some indexes, you need a good DBA to carefully look at the DB performance; as you learn about the load creating patterns of your users, your DBA will be able to ensure maximum performance by tuning the DB; also, Oracle and DB2 still outperform any Open Source DBMS (and most other commercial DBMSs) by factors (if you look at the execution plans you will know why...)
AppServer tuning - as with any J2EE application there is a lot to gain from tuning the application server. Regarding JBoss tuning you might want to have a look at JBossASTuningSlimming, for a example. It is also a good idea to give your Tomcat a boost with the Apache Portable Runtime (particularly useful to speed up SSL)
Java VM tuning - as with any J2EE application there is a lot to gain from tuning the Java VM (memory size settings, garbage cleaning, etc.). Depending on your platform you might also observe performance differences among different Java VMs (e.g. BEA JRockit vs. Sun Java VM)
on any multi-CPU box (real or hyperthreaded) you should verify that the Java VM and the DBMS are actually using more than 1 CPU; we have come across many installations where people spent a lot of money on high performance servers with multiple CPUs without actually putting more than 1 of them to work... (for example, on Redhat the Java VM will use multiple CPUs only if you install compat-libstdc++-3.2-1.i386.rpm)
make sure that your servlet container / application server sends compressed (zipped) pages to browsers; with JBoss, for example, add/set the Tomcat option compression="on" in the file server.xml (details on the http connector reference page of the Apache Jakarta Project) - compressed pages are smaller than uncompressed pages by a factor of 10, thereby reducing the load on your network and improving the experience of users connected to the openCRX server with "less than optimal" bandwidth specs
enable gzip compression filters and cache header filters in the applications web.xml (depending on the distribution some of the filters are commented out).
Application performance tuning is a time-consuming (and therefore expensive) task because it often times involves detailed analysis (and good understanding) of the various components involved; for example, every DBMS has different quirks and at some point you really need to deal with the DBMS your are actually using, i.e. it is not sufficient to do some generalized high-level DB tweaking. While we have a tradition of investing resources on a continuous basis to deliver a well-performing application, it is no secret that one could do even more. We appreciate any hints to enhance performance. In case you want to contribute financially, please visit our Community page.
What is the openCRX/openMDX/JDK/AppServer version compatibility?
The openCRX version determines which openMDX version to use. Depending on your preferred JDK version you select matching distributions of openCRX and openMDX for the same JDK.
openCRX Version
openMDX Version
JDK Version
v1.0.x
v1.3.6
1.3
v1.1.1
v1.4.1
1.3 or 1.4 (use matching distribtutions of openCRX and openMDX)
v1.2.0
v1.5.2
1.3 or 1.4 (use matching distribtutions of openCRX and openMDX)
v1.3.0
v1.5.3
1.3 or 1.4 (use matching distribtutions of openCRX and openMDX)
v1.4.0
v1.6.2
1.3 or 1.4 (use matching distribtutions of openCRX and openMDX)
If you get the impression that the rendering of pages is broken you might
want to upgrade your browser. If you detect problems in our HTML
code or in our Javascripts we would certainly appreciate it if
you could post your insights to the bug forum.
We identify an openCRX version with 3 numbers x, y, and z (i.e.
openCRX x.y.z). x.y.z is
the Implementation
Version, x.y is
the corresponding Specification Version.
The meaning of individual numbers is listed in the table below:
Name
Interfaces/Functions
Implementation
Database
Implications
x
Major Version
if major version number increased
interfaces will be different
(i.e. not upward compatible)
will be different
new tables and possibly
change of existing tables
Implementation:
- bugs fixed
- new functions
- user code requires refactoring
Database:
- modification of existing tables
and adding of new tables
- no data migration
y
Minor Version
if minor version number increased (but same major version
number)
interfaces have been extended and/or
new functions have been added
(but upward compatibility is guaranteed)
will be different
possibly new tables
Implementation:
- bugs fixed
- new functions
- user code upwards compatible
Database:
- script adding new columns to table and adding new tables
- no data migration
z
Patch Version
if patch version number increased (but same specification
number)
unchanged
will be different
possibly new columns
of existing tables
Implementation:
- bugs fixed
- user code upwards compatible
Database:
- script adding new columns to table
- no data migration
What follows are detailed instructions for upgrading openCRX from v1.11.0 to v2.0.0 (upgrade instructions for earlier releases can be found here):
pre-built EARs are contained in the openCRX Server Installer in the directory
<Server Installation Directory>\apache-tomcat-6\deployment-units
stop the application server
backup your database
upgrade your database as follows:
drop all (openCRX) views
execute the script upgrade-from-1.11.0-to-2.0.0.sql
execute the script migrate-from-1.11.0-to-2.0.0.sql
execute the script drop-from-1.11.0-to-2.0.0.sql
on the new database, execute the script dbcreate-views.sql
Hint: in case execution of the script is stopped and rolled back because of failing statements, you need to investigate the issue. DROP statements of non-existing tables/views can safely be deleted from the script. However, the CREATE statements must execute without errors.
on the new database, execute the script dbcreate-indexes.sql
Hint: execution of this script is optional; we just provide it as a starting point; DB tuning depends very much on the data, the usage pattern, and obviously on the DBMS you are using.
on the new database, execute the script populate-preferences.sql
either
install the openCRX 2.0 with the openCRX Server Installer (if you want to run openCRX on Tomcat)
The openCRX
Language Localization Guide explains in detail
how you can add new languages to openCRX or even
make your own openCRX language pack. From a technical point of view, adding
languages is a trivial issue; the big task is translating all
the code
tables, labels
and tool tips.
The following languages are currently available or being worked on:
locale
language
locale included
and
activated
in
core distribution
If a login page supports locale xx_YY you can request the login page in that locale xx_YY by appending the string "?locale=xx_YY" to the default login URL. Example: the URL http://demo.opencrx.org/opencrx-core-CRX/Login?locale=de_CH directly loads the German login page.