Thoughts on CiviCRM v2.0 ...
The nice thing about developing software is that the work is never done. There are so many cool things that we can do to make CiviCRM a better application. I've been having some pretty good conversations with David Strauss of Four Kitchen Studios on our IRC channel (#civicrm at irc.freenode.net). Four Kitchen Studios has been a great resource for CiviCRM and were instrumental in deploying CiviCRM within Wikipedia. In the recent past, David has initiated the de-dupe and contact merge algorithm which we hope to incorporate in CiviCRM v1.8.
Some of the various things that we hope to be part of v2.0. We will use a fair amount of the design and code from the v1.x series, but at the same time make significant changes when needed.
- Support for php5 / php6 only. This will enable us to use some of the more advanced functions specifically interface classes, iterators, PDO's etc. At this point, we'll probably also consider migrating to the Zend Framework library.
- Support for mysql5.x only. This will enable us to some the advanced features of mysql specifically views, triggers and stored procedures. For a project with a fairly complex data model like CiviCRM, I suspect this will make the code cleaner and more efficient.
- Simplify and clean up the data model and schema. In specific minimize the use of entity_table/entity_id concept and use native database foreign keys as much as possible.
- Allow users to extend/modify core CiviCRM screens, similar to what Form API has done for Drupal
- Have a comprehensive and automated unit / functional test suite
Thoughts, comments and questions are more than welcome. These are very preliminary thoughts, and we have at least one more release before starting work on 2.0