Towards an open ChMS marketplace

See previous posts in this series:
The ChMS conversation we started (but know we’ll never finish)
Choosing a ChMS – the risk calculation

Also earlier posts on related subjects:
Integrating CRM and the Web
Open source Church Management System (ChMS)

No customer lock-in
So what could ChMS vendors do to help me with my conundrum and reduce the risk that I’ll make a bad choice? First, let me suggest a non-technical answer: they need to reject the tempting strategy of achieving and maintaining customer lock-in. They need to go out of their way to make it easy for me to change in the future if I so desire. In other words, they need to set aside their interests and focus on the interests of the Kingdom (and in so doing, they’ll find that their interests are served as well). Instead of competing primarily on a feature list, they need to compete on ease of integration, openness, and customer services. If the vendor can achieve lock-in, they don’t have to be great at these things because they’ll have acceptable rates of customer retention regardless, at least in the short term. On the other hand, if the ChMS vendor rejects the lock-in strategy, my risk as the buyer goes down because I know the vendor will have to continue to earn my business long after the initial sale and implementation.

Second (and this is much more difficult), ChMS suppliers need to find their way towards an open ChMS marketplace. By “open” I mean one in which innovation can originate from many places and come together to meet the needs of a particular church at a particular time. For example, wouldn’t it be great if Granger could run Saddleback’s small groups system with Fellowship’s check-in and WEC’s content management? Wouldn’t it be awesome if Perimeter could run Shelby with Resurrection’s missions opportunity registration system? Wouldn’t it be excellent if Resurrection could run iModules’ online community tools with Perimeter’s Elder system and a web store like OS Commerce? I’m envisioning a marketplace in which there could be multiple for-profit companies contributing technology and services alongside churches, para-church organizations, and open source communities giving away software that automates their process innovations. Wouldn’t that be a major advancement for the Kingdom?

What is stopping us from doing this right now? Well that’s easy enough to answer. The systems I mentioned were built at different times on different platforms by for-profit and non-profit organizations without ever considering the possibility of interoperability. So that’s a big technical barrier. Also, the ChMS vendors don’t see an economic incentive to cooperate with their competitors, which is a big non-technical barrier. Could we overcome these barriers going forward?

To overcome the technical barriers, it seems to me we would need three things:
1. A common schema for data exchange. (The best technology for this right now is XML.)
2. An architecture for generating and handling data change events (such as a Web Services API).
3. An architecture for single sign-on.

Tony posted a comment in which he used the term “platform” to describe what we need. He also quoted me in the ChMS Google group, which attracted a number of comments exactly along the lines I’m thinking.

More in the next post ...