We valuated all the options. Our criteria were simple: Must run on Postgres (won't get into the PG v.s. MySQL debate here but we will only use PG for our business critical software), must be OpenSource, must have a forum that is (relatively) uncensored and must allow us it add out own customer extensions to the software.

Sugar failed on both the OpenSource and the Postgres front. As did Compiere. Adampiere failed for maturity reasons. Project looks good but not stable enough. vTiger seems excellent but again, the PG side isn't stable enough.

Centric really was the only option left once all the necessary business critical considerations were taken into account.

Once we went down the centric route, we also discovered that the ATTITUDE of the centric crowd were a big plus. Attitude counts a lot and centric as a company have a good ATTITUDE towards the OpenSource adopters. They correctly see us OpenSource diehards as friends, not enemies. We are willing to, capable of and actively do contribute very significantly to centric both in terms of ideas, feedback and code/bug fixes.

What's more, centric correctly see us as having BOUGHT INTO centric. They know that we have a stake in centric just like they do. It's their livelihood and for us, our businesses and other uses of centric rely on centric. So they know that we are passionate about it, we care and we want it to be the best.

I think that ATTITUDE counts more than anyone actually realises. Centric wins hands-down here. The only other project that comes close is Adempiere.

I just wanted to document this in public because it's not often mentioned but it is a huge factor, one of the most significant, that should be taken into account when evaluating an opensource product.

Most "OpenSource" products are actually using the good name and reputation of the OpenSource community and our projects as a cheap publicity stunt. They view us OpenSourcers as the enemy. The people who want to steal the bread from their table.

Centric understand that they are running a restaurant. Their paying clients are the only ones at their table. The bread that they serve is actually made from a recipe shared with, and improved by many other people, us, the centric OpenSource users. So rather than TAKING the bread from the table, we are creating the bread for them to sell, making it taste better, making it suit the other food on the table better, making their paying customers happy and willing to keep paying centric.

This is the trick that centric have gotten so right, and it's something that they need credit for. It's a reason to go centric, either as a paying customer or as an opensource adopter, but either way, it makes compelling reason to go centric.

Bradley, thanks for your very positive endorsement. I am the chief marketing officer at Centric, so your post definitely caught my eye.

As you point out, the attitudes of one's partners are very important. Even though we are still a small company, we definitely try to be very partner friendly and as responsive as we can be to our community and customers.

I would love to hear more about your evaluation and usage of Centric CRM. Please let me know if there is a way to contact you directly.

Thanks,
Michael

Vincent Nonnenmacher wrote:
Quite all OSS, are using some standardized features/tools set for letting other developpers using and developing on the code base. Centric sound nice, but not having a trac like approach to look and participate to the developpement process, is like a show stopper.

We are working hard on opening up our development to the community, and will begin providing complete roadmaps in the next few days. Additionally, we'll try to make the development projects more transparent.

I did not understand your comment about a "trac" like approach. Are you talking about the process that the trac project uses on their web site, or using an application like trac to expose our development process. The Centric Community portion of our web site already has most of the capabilities of Trac, and much more - wikis, forums, RSS, document management & search, project planning, and help desk. We also provide access to our Subversion repository, though that is not yet integrated with Centric CRM.

Maybe we are just not using all of it well enough?

Earlier in this forum David Richards states... "Similarly, additional flexibility to modify, remove and/or make fields "mandatory" will be in 4.0." I am new to Centric CRM and just started evaluating version 4.1 and have yet to see this additional flexibility he refers to. Am I blind or did this functionality slip a release or two... I have used Siebel, RightNow, and Sugar and am trying to see how Centric compares... Please let me know if I missed something.

Thanks,
Ray

Darn it, Ray, you're not suppose to look at statements from earlier posts. That's not fair. :) There needs to be a statute of limitations and a tool to erase all old posts from CEOs.

Seriously, that feature set has slipped a bit and did not get into 4.1. Why? The usual reasons -- other priorities and demands. Sorry. Having said that, one of the major development priorities that pushed it back was work we're doing on a portlet architecture. The excitement around this work is the high degree of customization it allows partners and customers, way beyond just changing simple configuration items.

Having said that, sorry again that we slipped there. We will be releasing the 5.0 road map in the next week or so. I can't say whether that type of configuration will be in there, but you can make the configuration changes you might need today, only not through a GUI.

- David

Nice to see that someone is supporting portlets. I'm sick and tired of other mashup approaches. Portlet spec is not a greatest spec in the world, but it IS a spec. I went through all kind of mad and bizzare things with my own team, to push them into using portlets. Some time was wasted, of course, but you know what? We managed to do everything other people said that are impossible :) Like AJAX with DRW and Dojo within portlets, interportlet communication, an AJAX proxy to serve and feed all portlets presently on a page with a single requesting point (thus limiting a network and server load, we have a VERY dynamic requirements, Call Centar), JSF backend. The only thing we didn't do yet is combination of reverse AJAX and plain old AJAX.

Great news. Keep on a good work.

Filip Šelendić
Protenus d.o.o.