CiviCRM Community Forums (archive)

For comparison, here's the Salesforce API Support policy.  Notice that they treat API changes as a serious matter.  In my experience, this is necessary to build a viable developer community.

-- Walt

I do agree that this is a worthwhile goal to shoot for. however we should remember a couple of things:

1. salesforce costs money for a significant chunk of folks (http://www.salesforce.com/crm/editions-pricing.jsp)

2. civicrm is open source. Which also means that community development practices replace the $$$ part of salesforce.

and that involves all of us stepping up significantly to help close the gaps, improve our development and testing process, modify / radically alter the way we do some things etc. Developing a full fledged robust stable API takes a lot of time, hours and effort etc. its not a cheap endeavor

so what commitment are folks willing to make and sign up for? specific goals that you want to achieve and hours/week that you are willing to commit would be a good first step

lobo

In my opinion (which is based on observations made while developing contributed modules) establishing a long interval between incompatible changes is essential to getting community contributions.  Every incompatible API change mows down the existing contributed modules.  After a period of time some of them are working again, but many just die on the spot.

It costs the contributors money and effort to change their contributed module.  In the case of a module which is not widely adopted, which is incidentally likely to be true with a new idea that is not obviously valuable, the contributor might decide instead to just hack up their own copy for their particular need and not bother trying to make it more generally useful.  This means the community, as such, becomes smaller and it might eventually fall below critical mass.

Here's a practical example:  The Drupal 5 send module stored information in CiviCRM 1.9 if it was installed.  When CiviCRM 2.0 came out with an incompatible API change, send stopped working.  We had a debate about whether to try to fix it or replace it with another module that didn't try to talk to CiviCRM.  Finally we decided for various reasons to replace send.  That debate would not have been necessary without the incompatible API change.  I haven't looked at the send module for a while, I don't know if was ever upgraded.  The net result is that the contributor community is that much smaller.

In the case of the Drupal contributed modules, a nice feature is that so many different people try different ideas to solve similar problems.  We can download various modules, try them, and see which ideas work best.  This is a process that gathers momentum as it goes on.  Of course after a couple of years an incompatible API change comes along, kills the dinosaurs and samsara continues 

-- Walt

 

Correct me if I'm wrong, but doesn't the Drupal API remain stable throughout major versions? I.e. the Drupal 5.x API is stable, but they reserve the right to break it in 6.x, right?

Right

Assuming I'm right about that, that's the same as what I'm proposing for CiviCRM. Stable API throughout 2.x (once we get it cleaned up enough to freeze), and then we can break it for 3.x (but it will again be kept stable throughout the 3.x life cycle).

Does that seem like a reasonable proposal?

The more important issue is, how many months is the API specification valid?  In the case of Drupal, they have been on a long enough cycle that the six or so months that it takes for the contributed modules to catch up leaves about 18 months of real world use.

-- Walt

redspire: Cool. The biggest thing that needs to happen now is for someone to work with Aaron Crosman to reconcile his ideas for improving the REST interface with the API standardization plan. Some of the stuff in the standardization plan is designed to make the current REST interface work across the API (currently it does not), but I think Aaron's plans will relax the requirements a bit. So it would be good to see where we can do that since there's no point in forcing a particular convention on everyone for no reason.

And then in general the API improvement project needs a champion / driver who keeps the rest of us on the ball and working towards our goals. It's looking like I may not have time to do that (I have to concentrate on getting multi-org right for 2.3), but I should have some time to contribute to the project. If you want to do that, I can tell you who has already committed to doing what and help you get in touch with them.

Thanks for stepping up!