CiviCRM is one of the core offerings of our company. Remaining close to the CiviCRM community is important to us, as it keeps us close to new developments in the tool, and allows us to offer our feedback for new releases.
I've always been passionate about what non-profits and advocacy groups can achieve using technology. For me, CiviCRM shows an essential example of how non-profit and technology worlds can come together to provide real change - working as community, creating value for yourself, but also for others in non-profit sector.
CiviCRM allows us to bring all benefits and capabilities of a large commercial CRM and
donor management system to medium and large non-profits at a fraction of the cost. CiviCRM also allows smaller non-profits to benefit from an integrated solution for donor management, events, bulk email, etc. substantially increasing their effectiveness as compared to managing a variety of nonintegrated software and spreadsheets. Thanks to a strong CiviCRM community, CiviCRM’s functionality continues to advance and CiviCRM’s market continues to grow rapidly.
We feel there are too many obstacles facing not-for-profits (NFPs) considering commercial CRM offerings, including many of those that are charity oriented. From licensing models which restrict the fluid expansion of an organisation's user base (why should you be punished with higher costs for being successful?), to support from commercial companies being inherently tied to one supplier; a NFP would benefit from the option to 'shop around' for those most appropriate, e.g. based on: proximity and availability on-site, cost, experience, value added services... They also often lack the capacity for charity relevant workflows, necessitating either customisations, complicated and inefficient workarounds or an en-masse call for new functionality, as individual charities do not appear to carry the weight required to influence subtle NFP-only changes to market leading software, without large expense.
On the flip side, CiviCRM is completely free and open-source, carrying with it a friendly, hard-working and enthusiastic community of developers and implementers, constantly listening to the users' needs and sculpting future releases to the requirements of NFP organisations. This is exciting!
AustLII is the leader in the free access to law movement and has a philospophical bias towards open source systems. After investigating all the other possible major alternatives it seemed logical to turn to CiviCRM. We have software developer resources, and though it is not core business, we may be able to direct some of these resources towards improving CiviCRM for the community.
rasantiago has proposed a new CiviCRM architecture with details of the ORM layer. Torenware commented on the latter and mentioned some particular scalability issues. Our own experience with the Active Record design pattern proposed by rasantiago is that it works well for small projects but doesn't scale well. We believe that CiviCRM is now facing serious scaling problems in several areas, to wit:
This is a follow up to our last post proposing a new architecture for CiviCRM. Much appreciation for everyone's patience. Following from our last post we want to go over the use of Doctrine, a PHP implementation of the Active Record design pattern made popular through Ruby on Rails. The Doctrine Project has done a great job of maintaining detailed documentation and has a lot of features that we believe everyone will find useful when working with CiviCRM objects. We have posted some of our working code for the new ORM and REST API here at git hub.We have given this code set the working name civiBASE.
Here at raSANTIAGO we are entering our third year with CiviCRM and still find ourselves struggling to make desired changes to the codebase. Too often we have expressed desired to re-architect and re-factor the CiviCRM. Recently we have completed two major projects that had us deeper in the codebase then before and realizing that we had to stop complaining.
Submitted by Dave Greenberg on February 3, 2009 - 19:23
Do you wish you could configure custom fields to store Employment History, Educational Background, Volunteer Skills or other types of information where you may need to enter multiple sets of values for a contact? Starting with CiviCRM 2.2, you can do just that.
For example, if you need to collect Employment History - you might have fields for Job Title, Start Date, End Date, and Reason for Leaving. Enabling the "multiple records" setting in that custom data group will allow you to enter that information for multiple jobs. You can also set the maximum number of records which can be recorded per contact (you might only want data for the three most recent jobs).
As the various localisations of CiviCRM get traction, the first localised versions of documentation pages begin to show up – and this brings us to the issue of how to internationalise these of the CiviCRM strings (texts) that contain links to documentation pages so that when a given string is translated to, say, German, it also refers to the German version of the documentation page (if such is present).
No, not what you think. :-) It's the time of year when new a CiviCRM version is behind the door, and it has cool new features. Code freeze is going to be introduced any day now - and we'll move on to quality assurance, alphas, betas and other equally exciting stuff.
Let me briefly introduce you to two new 2.2 features: one of them already mentioned here and there - Personal Contribution Pages (PCP), and a "last minute" addition - Soft Credits.
The CiviCRM core team is currently meeting in San Francisco. We tend to meet 2-3 times a year. These meetings help us crank out a few large projects as a group and also help improve our communication when we return to our respective home bases.
Implementing support for multiple organizations with hierarchy is one of the main themes of the phase 2 part of the CiviCRM / The Public Interest Network (PIN) project. PIN has a fairly complex structure. It is a federation of organizations which include US PIRG, Environment America and others. It is made up the National PIN organization and has a number of child organizations at the National Level. One of them is Environment America (EA).
Lately there has been lot of confusion using Name, Title/Label and Value. There is also a lot of inconsistency in code and database, hence we are planning to fix it in CiviCRM v2.x release.
Lets take an example of Participant Status, 'Registered'. In this case Name will be 'Registered', value will be an integer from 1..N (this depends on each install) and Label/title can be "Registered" or "I will come" etc. (or a localized version of the word/phrase).
Integrating CiviCRM with an email client (specifically Outlook) has been a long requested feature. Unfortunately we dont really have any internal windows expertise to make this happen (for now). For now, we've built some code for the HRD project that attaches incoming email as an activity to the contact record of emails that are in the from / to / cc / bcc fields (we create a contact record if not found)