Upgrades in Drupal-land are a bear. Over the next few releases, the community should get a dependecy system in place that will improve things. We shall see.

I disagree with this If you use standard drupal and contributed modules and you don’t fork anything you can simply run the upgrade script between point releases and your set. if you use CivicSpace we have a garunteed upgrade path for users between Dupal point releases. A dependancy system is in the works that will make this process quite a bit easier. The next version of Drupal 4.7 ships with a contrib module upgrade system and an automated module install system. By 4.8 / 50 we should have most or all the pieces in place (hopefully

You are right. Our documentation is no where near where Salesforce is, nor do I think it will be anytime soon. And we are certainly not the poster child for API documentation. As I have said before, and will say again, a direct comparison between Salesforce and CiviCRM is silly… Salesforce is a much more mature product that does a bunch of things extremely well. CiviCRM is a little over a year old.

My post was not meant to be rhetoric. As always, we are happy to work with anyone to demonstrate the precise strengths and weaknesses of CiviCRM. There are plenty of both. In fact, the best place to see them all documented in vivid detail is our email list, wiki and bug tracker (www.civicrm.org).

Here’s a critical nonprofit business need for a web services API. Some of them want to use a non-PHP CMS that fits their needs better than Drupal or Mambo, or need to their CMS on a different server from their CiviCRM database. This is not currently possible without a web services API.

Absolutely. That is precisely what Salesforce has been architected to do. This is what CiviCRM has been architected to do. I’m sure this debate will die down once a few CiviCRM integrations have been done outside the LAMP stack. As always, were open.

And for Jonah-
Upgrades in Drupal-land are a bear. Over the next few releases, the community should get a dependecy system in place that will improve things. We shall see.

The neat thing about a lot of smart and passionate folks working toword a common goal is that it’s virtually inevitable that the sector is going to benefit.

Breakage. When a web service breaks, the application breaks. And that breakage is entirely out of you our the user’s control. (there are no service level agreements for a collection of web services)

Don’t conflate building components that expose themselves as webservices with building apps against thrid-party web services. For all the usual f/oss reasons it can be important to own and run your own services. Not just for sla, but for app-specific policy as well.

Complexity. Web service A updates its API and inadvertently breaks backward compatibility. If your application relies on 10 web services, how do you debug just to figure out what is going on? How do you get it fixed?

testing testing testing. And decoupled components ought to be easier to test, and potentially more reliable than complex systems. Updates to service apis is no different than the upgrade path on a single platform. Dependency resolution needs to happen in both cases. What is the upgrade experience like in the world of drupal?

Well done, and thank you! See you in Seattle…

Nobody here is talking about selecting donor databases. Nobody’s talking whiz-bang or cool. We’re talking about designing software so that it expands the options available to users and developers, rather trying to force everyone in the sector on a single software stack.

Unfortunately, in my book, CiviCRM is NOT even close to a poster child for API development. Your rhetoric is way ahead of the CiviCRM code. The biggest gap is that the CiviCRM team hasn’t yet document the web services API in any meaningful way, nor have they built out any web services API calls beyond those that CiviMail requires.

That renders it effectively impossible for anything that isn’t a PHP app on the same server to access data in CiviCRM. Except for your own CiviMail product.

If an API gets built but not documented, can it be said to exist?

When CiviCRM has API documentation that is even close the the quality of http://www.salesforce.com/developer, then it will be a poster child for API implementation.

Here’s a critical nonprofit business need for a web services API. Some of them want to use a non-PHP CMS that fits their needs better than Drupal or Mambo, or need to their CMS on a different server from their CiviCRM database. This is not currently possible without a web services API.

The techies are making the decision.
Falling in love with cool features
Buying more than you need
Confusing Highly Functional Software with Highly Trained Staff

I think that discussions like this need to be anchored in the experiences of the people we are trying to help.

Web Services APIs don’t create simplicity, they create power. Power comes at a cost. That cost is things like:

• Latency. What if your geocoding service is slow, how is the user going to know that the 5 minute import of 10 records isn’t because your software sucks.
• Breakage. When a web service breaks, the application breaks. And that breakage is entirely out of you our the user’s control. (there are no service level agreements for a collection of web services)
• Complexity. Web service A updates its API and inadvertently breaks backward compatibility. If your application relies on 10 web services, how do you debug just to figure out what is going on? How do you get it fixed?

An application like CiviCRM is actually the poster child for exactly what Jon is talking about. We make the web services vision possible with SOAP. At the same time, we don’t think nonprofits should be exposed to the risks of the latest wiz-bang stuff just because it is cool.

So we are also the poster child for avoiding wiz-bang for wiz-bang’s sake and keeping functionality close to customer needs. We’ve implemented web services for geocoding and mapping from Yahoo and Google. But a user has to make the decision to enable them, which suggests the user might understand the risks and have the technical chops to deal with them.

We expose our APIs vis SOAP, but we have yet to see someone come along with a critical nonprofit business need to use those SOAP APIs. Are we suppose to invest in things that nonprofits don’t currently need, just because it’s cool?

I think we are all headed in the right direction and I think we’ll see a great ecosystem develop around nonprofit technology (Drupal, Plone, CiviCRM, CivicSpace, ?). We just need to be careful that real-world nonprofit needs drive the development of that ecosystem.

http://www.zacker.org/web-services-are-no-silver-bullet