A client recently encountered two problems in its CiviCRM system. As part of my operational support plan, this allows an open partnership to surface issues without the fear of hourly bills being racked up.
The first was a bug in the CiviCRM Event Organiser WordPress plugin registration defaults. I investigated the problem and contributed a fix so new events properly respect the plugin’s configured registration defaults. A small fix, but helpful nonetheless.
The second involved SearchKit updates failing when event participants had multiple roles. I reproduced and triaged the issue into the CiviCRM Development Issue Queue, and it got picked up by the Core Team.
This kind of contribution is typical in the CiviCRM ecosystem. Many CiviCRM partners regularly reproduce bugs, submit patches, maintain extensions and respond to an issue queue, and help move issues through core—at a much greater scale than I do. It is part of how the software continues to improve.
The plan provides time and priority to reproduce the problem, document it properly, and report it to the appropriate project or maintainer. When circumstances allow and fit my skill-set, I may also contribute a fix or help move the issue through the open-source development process.
Here’s the deal:
Service expectations should reflect the level of investment. Basic CiviCRM hosting keeps the system hosted, maintained, and updated. If you have simple needs and aren’t that sophisticated with your CRM use, this can work. But other situations I see, it can lead to a decay / workaround and lower usefulness of the system as time wears on.
Two approaches
Organizations paying for the minimum level of service have to be pragmatic with what they expect. In practical terms, the level of support should match the level of investment.
Organizations that invest in their system create more capacity for someone to investigate system issues so it stays “tuned up” and working optimally.
This is one of the benefits of open-source software: investing in your own system can help strengthen the shared technology that many other organizations also rely on.
And consider that if you do make use of common features and avoid custom code in-house unless it is strictly necessary, you’ll be able to take advantage of all of those community fixes that happen without you lifting a finger.