As of this writing there are 15,851 modules listed on drupal.org with new ones being added every day. It’s getting crowded in contrib and if you want to make friends you’re going to need to do a couple of things to make sure your module’s are chatty, open to the influence of others, and willing to step down when necessary.

Not to mention we all like writing reusable code. Well written modules also lend themselves to being re-used over, and over, and over. Save yourself some time in the long run by investing in designing a good API upfront.

This session will discuss best practices for ensuring that your module isn’t going to conflict with code written by someone else. Exposing your own API via module_invoke_all() and allowing other modules to modify the way your module handles certain operations via drupal_alter() without having to modify your code whatsoever. We will also discuss some common pitfalls that can prevent other modules from being able to make use of your reusable code, and other commonalities of all of our favorite friendly modules.